Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!MX.LCS.MIT.EDU!JBVB
From: JBVB@MX.LCS.MIT.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Telnet binary mode
Message-ID: <980439.870617.JBVB@MX.LCS.MIT.EDU>
Date: Wed, 17-Jun-87 00:06:07 EDT
Article-I.D.: MX.980439.870617.JBVB
Posted: Wed Jun 17 00:06:07 1987
Date-Received: Thu, 18-Jun-87 04:59:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 57


    All Telnet servers should have a command that a network user can issue
    that puts the network terminal in binary mode....

    All Telnet clients should have a command that a Telnet user can issue
    that puts the Telnet connection in binary mode....

I do not think this is the right approach.  In particular, given the
current state of the TN3270 world, there are a number of implementations
in the field that would automatically respond by switching to EBCDIC.
This is not sacred, but it is no more sacred than the tradition of
various clients and servers generating parity over Telnet.

What I want is RFC 854, with a clarification of the sentence:
"All remaining codes do not cause the NVT printer to take any action."

I would prefer a reading which guarantees that all 8-bit codes can be
transmitted over a Telnet connection without any negotiation (with
appropriate IAC stuffing and removal), but does not guarantee that
the receiver (client or server) will do anything in particular with
them.  As I see it, this allows a simple TT_TYPE negotiation (or manual
terminal-type control) to open up 8-bit extended functionality on a
case-by-case basis.  I feel this is appropriate, since there isn't any
universal interpretation of the codes above 128.

In most of the operating environments I know, a character can have 8
bits.  Here, implementing my recommendation is trivial.  The host software
has some mechanism for determining what sort of device to generate output
for, and if the user doesn't want to care what kind of terminal he is
using (or emulating), he should be using supdup anyway.  Automatically,
or manually, the terminal type is agreed upon, and if that implies 8-bit
I/O, so be it.  IAC stuffing continues, but no masking occurs, and the
8th bit is never set unintentionally.

In cases where the OS treats the sign bit as out-of-band data, masking is
required by default.  I don't know the history of the "rubout performance
problem", but I can see that a special call is needed for programs that
want only the masking disabled, without the other side effects of 'raw'.

Requiring 'binary' be negotiated before 8-bit data can be passed over the
connection smacks of the 'telnet-randomly-lose' option:  This uses 'binary'
to indicate "I am a conforming implementation, and I won't send you any
parity or the like".   This ought to be dealt with by fixing the offenders,
and leaving the user something like a "4BSD/RFC-959 switch" in an FTP
client, so he can request masking during the transition period.

The one widely-implemented use of 'binary' as of this date is as an
indication that "we are in EBCDIC now".  I submit that there is a
worthwhile distinction between "NVT ascii with possible extensions",
and "something completely different" (16-bit chars?), and that this
distinction ought to be preserved, whether by my proposal, or at least by
using 'option a' to differentiate between "NVT" and "extended NVT", and
'option b' for larger distinctions (TN3270).

jbvb
James B. VanBokkelen
FTP Software Inc..