Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!PANDA.COM!MRC
From: MRC@PANDA.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Telnet binary mode
Message-ID: <12311138276.8.MRC@PANDA>
Date: Wed, 17-Jun-87 02:22:21 EDT
Article-I.D.: PANDA.12311138276.8.MRC
Posted: Wed Jun 17 02:22:21 1987
Date-Received: Thu, 18-Jun-87 05:11:15 EDT
References: <980439.870617.JBVB@MX.LCS.MIT.EDU>
Sender: uucp@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 48

James -

     Your message leave me quite confused, and I am the author of several
different Telnet client and server programs as well as part of the Telnet
protocol (Logout and Supdup).

     I would assume that any user who issues a command to put the
connection into binary mode would know what the impact of that command will
be, and I would be quite irritated at a Telnet implementation that didn't
leave the choice up to me.  Perhaps in the IBM world Telnet binary mode is
used for EBCDIC, but binary mode sure as hell is used for a helluva lot of
other things than that!

     Telnet is a 7-bit protocol.  Binary is the only general means of
transmitting 8-bit data.  There are other means of transmitting specific
8-bit data (e.g. Supdup).  Binary should not be interpreted as having any
other semantics (e.g. Unix "raw" mode, TOPS-20 terminal binary mode,
EBCDIC).

     It is absolutely not trivial to implement your "recommendation"; there
are a whole slew of issues involved in 8-bit transmission, particularly
with regards to terminals which expect or use parity as opposed to
terminals which do not (or have user control of the 8th bit as in an "EDIT"
or "META" key).

     I for one will firmly resist any attempt to change the semantics of
the Telnet protocol.  EBCDIC is NOT, repeat, NOT the only user of Telnet
binary mode.  If EBCDIC is really getting extensive usage, then it should
be set up as its own option.  Binary mode should be used for EBCDIC only
between consenting hosts!!  I never heard of the TN3270 developers claiming
the right to take over existing protocol!

     There is an ISO recommendation for large character sets; it involves
14-bit characters limited to the characters between 21h and 3Eh (that is,
the printing ASCII characters).  All control characters and delete are
always interpreted as a single bit.  I'm most familiar with their usage in
Japanese kanji terminals; in those, an escape code is used to shift between
ASCII and 14-bits.  This could be a Telnet protocol option, but all
terminals use the same escape code so there doesn't seem to be much of a
point to doing so.

     You refer to the "Telnet Randomly-Lose Option", but do you know what
it was?  I know because I wrote it; it was an April Fool's Joke ten years
ago having to do with user control over system crashes.  It has nothing to
do with your discussion that I can tell.

-- Mark --
-------