Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!nike!ucbcad!ucbvax!SUMEX-AIM.ARPA!MRC%PANDA
From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Telnet binary mode
Message-ID: <12233354603.6.MRC@PANDA>
Date: Sun, 24-Aug-86 09:03:52 EDT
Article-I.D.: PANDA.12233354603.6.MRC
Posted: Sun Aug 24 09:03:52 1986
Date-Received: Sun, 24-Aug-86 19:48:50 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 28
Approved: tcp-ip@sri-nic.arpa

Joe -

     A purist would argue that NVT ASCII is 7 bits unless binary mode has
been negotiated.  The Telnet specification is vague on this point, but it
does refer to the "128 possible characters in NVT ASCII" in a few places.
I believe that 8 bit transmission in non-binary mode is a bug, since it
interferes with local parity handling.

     The parity issue is important, although many implementors (myself
included, alas) have never bothered to implement parity correctly.

     I know that vanilla DEC TOPS-20 does not enforce 7-bit NVT ASCII on
input to an NVT.  It also doesn't enforce IAC doublings on output from an
NVT.  I consider both of these to be bugs, in spite of the fact that
certain individuals have written programs to exploit them.  The PANDA
versions of TOPS-20 (SIMTEL20, STL-HOST1, DREA-XX) all have these bugs
fixed, as do several other sites.

     Significantly, the TAC also enforces 7-bit ASCII in non-binary mode.

     I think that it is prudent to negotiate binary mode on any Telnet
connection in which you wish to transmit 8-bit ASCII.  The only hosts I
know of which have problems with binary mode are certain broken versions
of Unix.  As far as I can tell mainstream Unix handles binary mode
reasonably.

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