Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!ucbvax!PANDA.COM!MRC
From: MRC@PANDA.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Telnet binary mode
Message-ID: <12311417899.8.MRC@PANDA>
Date: Thu, 18-Jun-87 03:58:22 EDT
Article-I.D.: PANDA.12311417899.8.MRC
Posted: Thu Jun 18 03:58:22 1987
Date-Received: Sat, 20-Jun-87 00:52:56 EDT
References: <216009.870618.JBVB@AI.AI.MIT.EDU>
Sender: fair@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 70

James -

     There are several uses of Telnet binary mode, all of which
predate TN3270.  Here are some I can think of off the top of my
head, at half past midnight after a long long work day:
1) many terminals have an EDIT key which allows applying the high
   order bit to a character, and several display editors, most
   notably various implementations of EMACS, use this facility to
   have commands (e.g. CTRL/F means move forward character, but
   EDIT/F means move forward word) way up there.  At least two
   display editors, TVEDIT and E, are severely crippled without
   this facility.
2) some terminals have an 8-bit character set, most notably DEC
   VT220's, and there are a helluva lot of people who use the
   characters up there!
3) from time to time, many users want to transmit 8-bit data as
   part of a download or upload sequence, e.g. using the Kermit
   or Modem protocols running the Kermit/Modem server on a remote
   host.
4) from time to time, users want to run other 8-bit protocols
   such as UUCP over a Telnet link (don't laugh, in a US/Japan
   link I am quite familiar with two Unix systems mail to each
   other through a DEC-20, and two DEC-20's mail to each other
   through a Unix, for various ugly technical reasons I won't go
   into here).
5) from time to time, users want to experiment with enhanced
   protocols at a level above Telnet, and use Telnet as a base to
   support these protocols.  TN3270 probably had its start in
   this fashion.

     However!!  There are many terminals which generate (or
require) parity when dealing with a host.  A user who wants to
send 8-bit data over a Telnet link generally knows what he's
doing and can give a command (whether it's CTRL/^ T, TRANSPARENT,
@ B I S, or whatever is unimportant).  A user who has problems
with parity on his terminal generally doesn't know WHAT the hell
is going on!

     I don't know what you are talking about when you say "a
number of clients and servers which take it upon themselves to
generate parity to send over the network."  Parity is NOT sent
over the network.  That is what the whole point of requiring
7-bit ASCII in non-binary mode is all about!  If you put your
Telnet connection into binary mode, you're essentially saying
that you are NOT using parity on that direction(s) of the
connection, and that the high order bit is a meaningful data bit.

     Telnet binary mode has nothing whatsoever to do with any
host OS software concept of "binary."  Implementation that have
such a binding without the consent of the user are in error.
Telnet binary mode only impacts the transmission of 8-bit data.

     Let me also re-emphasize that you can do everything you want
in Telnet WITHOUT making incompatible changes to the existing
protocol or implementations.  All you have to do is define a new
option.  For example, you can add a TN3270 option.  Nothing in
the protocol says that binary mode is the *only* way to transmit
8-bit data.  Already there are two options, Supdup and Supdup
Output, which cause 8-bit I/O independently of binary mode.
Think of binary mode as "untyped 8-bit I/O" as opposed to
whatever other options you define as being "typed 8-bit I/O."
This also has the advantage of making damn sure both sides agree
to the interpretation of the I/O mode you are proposing.

     I suspect this conversation is boring a lot of people, so I
suggest it be taken off-line from TCP-IP unless people want to
hear it.

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