> Frank da Cruz wrote:
> > When RFC2066 first appeared we wrote a detailed commentary on it which
> > was ignored, as most comments on RFCs are.
> > I can elaborate if anybody is interested.
> Please do.
I was afraid somebody would say that. And now I remember that each time
this comes up and I search for the document I wrote, I can't find it --
which is a shame, because it was pretty good :-) However, to summarize
(a) Telnet sessions are seen through a terminal emulator that STILL
must use ISO 2022 for character-set designation and invocation;
(b) Terminal emulators require character sets to have certain
structures, e.g. ISO 4873, which does not seem to concern the
writers of RFC2066, who allow any "charsets" registered in IANA.
(c) When you allow any bizarre character set to be registered, the two
Telnet partners have an ever-diminishing chance of recognizing
each other's character sets;
(d) The Telnet server has absolutely no idea of what character set is
being viewed at any particular moment, so how can this scheme
possibly work to begin with?
Just imagine an everyday scenario. I am using a real VT220 to connect to a
Linux system, and Telnetting from there to VMS, where I am running an
application that uses ISO 2022 to switch character sets on my terminal
between Latin-1 (DEC Multinational) and DEC Special (line and box drawing).
How can the telnet client and server possibly know what is going on and be
of any assistance whatsoever? It can't. However, it definitely can get in
the way if it tries.
Now suppose I'm not using an actual VT220, but (say) a Windows-based VT220
emulator. Now I want to transfer a file from Windows, through Linux, to VMS.
Do I want Telnet translating characters for me? I certainly do not! This
would totally block file transfers by wrecking the packets. This applies
equally to Kermit, Zmodem, Ymodem, Xmodem, and any other error-checked file
I sincerely hope that RFC2066 has not been implemented anywhere.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:58 EDT