Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ucbcad!ucbvax!UCBVAX.BERKELEY.EDU!karels%okeeffe
From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Telnet, <CR><LF>, etc.
Message-ID: <8708120323.AA29496@okeeffe.Berkeley.EDU>
Date: Tue, 11-Aug-87 23:23:48 EDT
Article-I.D.: okeeffe.8708120323.AA29496
Posted: Tue Aug 11 23:23:48 1987
Date-Received: Fri, 14-Aug-87 00:39:21 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 36

Hey, folks, this discussion on telnet has gone much too far, and far astray.
Let me summarize the actual problem, which is quite minor, its effect
and the proposed modification to mitigate its effect.

First, let me remind people that a real problem exists ONLY in the following
circumstance: when a user connects by telnet from a host of a certain type
(including Bridge terminal servers) to a 4.3BSD host, and THEN runs a program
such as telnet that runs in character mode that distinguishes between <CR>
and <LF>.  This includes trying to telnet (or tip) from the 4.3BSD host
to some other host that distinguishes between <CR> and <LF>.  The problem
occurs if the originating host sends <CR><LF> when it receives a return
from the terminal, and has no option to send <CR><NUL> instead.  With such
a combination of hosts and operations, an interoperability problem exists.
In all other situations, things work correctly.  All of the implementations
involved are following the specification.

There is a simple, straightforward patch to the 4.3BSD telnet server
that mitigates this problem.  While I agree with Greg Minshall's
excellent summary of the 4.3BSD telnet implementation and rationale,
we have both agreed that changing the telnet server in a pragmatic way
will avoid this problem.  An "official" Berkeley bug fix for 4.3 telnetd
will be sent to the tcp-ip list soon and to the Usenet news group set up
for official Berkeley fixes (comp.bugs.4bsd.ucb-fixes).  

I think that the lessons learned are that

(1) protocol specifications that allow options for behavior may allow
correct implementations that fail to interoperate (no big news here),
and

(2) the Telnet specification has some problems, especially in the area
of character at a time mode versus line at a time mode (see Greg's
excellent discussion), and it may need to specify different behavior
in the server-to-client and client-to-server directions.

		Mike