[gopher] Re: Gopherness

[JumpJet Mailbox <jumpjetinfo@xxxxxxxxx>]

How would we print a Gopher retreived text document on, for example, an older 
(or mini-mainframe) computer which only uses a Daisy Wheel Printer or Teletype 
Printer (which ONLY supports ASCII characters)?
--- On Mon, 8/4/08, Nuno J. Silva <nunojsilva@xxxxxxxxxx> wrote:

From: Nuno J. Silva <nunojsilva@xxxxxxxxxx>
Subject: [gopher] Re: Gopherness
To: gopher@xxxxxxxxxxxx
Date: Monday, August 4, 2008, 2:08 PM

"Jay Nemrow" <jnemrow@xxxxxxx> writes:

> On Mon, Aug 4, 2008 at 10:19 AM, Kyevan <kyevan@xxxxxxxxxxx> wrote:
>> What about older clients, though? Modern clients will probably handle
>> UTF-8 at least well enough to not explode, but older clients might
not.
>> Generally, it seems safest to stick to the subset that is ASCII when
>> reasonable, only using UTF-8 or such when it's actually needed.
... is a
>> perfectly readable replacement for U+2026, even if it's not
>> "typographically correct." On the other hand, if you're
trying to post a
>> text in, say, a mix of Arabic, and Klingon, go right ahead and use
>> UTF-8.

There are also these iso* charsets which just use 8 bit to encode the
text, not allowing a greater collection of characters, and using those
you wouldn't be able to mix charsets.

For iso*, AFAIK, some sort of character detection, or configuration
would be required on the client side (it is possible to do that getting
the document language using gopher+ - and URLs pointing to the specific
view (even if it is just one) would be required to autodetect when
browsing a non-ASCII URL). utf8 will have to be supported, for the small
(but not zero) scenarios in which two non-ASCII alphabets are mixed in
the same text, and auto-detect would fail (unless a special language
code is used for mixed-language documents, or if the client handles more
than one non-english language (if it is allowed to specify more than one
in the gopher+ attributes) as utf8).

On the other hand, even if the choice was utf8 (so the documents would
be ASCII or utf8), I'd keep iso* support, just in case (therefore my
question is 'should we use the same sort of character encoding when
publishing non-english documents? if yes, which one?' and not 'what
should a client support?').

What's the actual scenario? Is there any client which crashes due to
utf8? Which clients are not able to render it correctly? And what about
iso* charsets support?

<snip/>
> If we do a version of Gopher which is basically new (adding UTF-8 or
> MIME or whatever), I think we should ask for and get a new port
> assignment for it.  If you wanted Goph08, send the request through a
> Goph08 port number.  Gopher request continue to go through port 70.
> Just have your server listen on two ports instead of one, using the
> old idea that if you are using a different protocol (essentially), you
> should use a different port.  (Crazy idea, I know.)  I guess this gets
> back to an old point, which is that a modern version of Gopher is
> essentially a new protocol and should be treated as such.  If you guys
> want to change Gopher to "improve" it, it ceases to be Gopher.
> "Updated" nostalgia is not nostalgia at all.

Adding a new way to do the mime part would be a reason to make another
version of the gopher protocol, or a protocol under a different name,
but about utf8, it's not about gopher, it's about the way text is
rendered by the client, not requiring any change in the protocol.

-- 
Nuno J. Silva (aka njsg)
LEIC student at Instituto Superior Técnico
Lisbon, Portugal
Homepage: http://njsg.no.sapo.pt/
Gopherspace: gopher://sdf-eu.org/11/users/njsg
Registered Linux User #402207 - http://counter.li.org

-=-=-
``Now we'll have to kill you.''
 -- Linus Torvalds