Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!sri-spam!ames!ptsfa!ihnp4!inuxc!iuvax!pur-ee!j.cc.purdue.edu!abe
From: abe@j.cc.purdue.edu (Vic Abell)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Telnet, <CR><LF>, etc.
Message-ID: <5093@j.cc.purdue.edu>
Date: Thu, 6-Aug-87 15:27:46 EDT
Article-I.D.: j.5093
Posted: Thu Aug  6 15:27:46 1987
Date-Received: Sun, 9-Aug-87 05:59:43 EDT
References: <8707311950.AA12026@opal.berkeley.edu> <555127536.0.CASNER@VENERA.ISI.EDU>
Organization: Purdue University Computing Center
Lines: 32

Among the five telnet client and server applications available to me for
for testing - 2.9BSD (4.1c/4.2 ancestry), 4.3BSD, ULTRIX 1.2, Wollongong
VMS 3.0, and WISCNET/VM (IBM) -  only one combination passes all my
operability tests: 4.3BSD.  (My tests did not including chaining - client
to server to client to server, etc., etc.) 

	2.9BSD has all the 4.2 failings and more - particularly with
	respect to local character processing and CR forwarding.

	ULTRIX 1.2 telnet doesn't process local characters at all, but
	it does echo them.  Its telnetd is reputed to have problems with
	echo mode changes.  Both are 4.2 based.

	Wollongong telnet emits unnecessary NUL characters and doesn't
	seem to send anything but <CR><NUL> for end of line.

	WISCNET works well with everyone, but has only line-at-a-time
	mode, so character oriented applications (e. g., vi) don't work.


Dave Borman and Greg Minshall should be complimented for having done well
a difficult job of practical engineering in 4.3BSD.  They managed to strike
a reasonable compromise with the leaky and overloaded telnet protocol.

It would be even better if 4.3BSD telnetd were changed to forward '\r'
instead of '\n' to the application.  That would represent another, good,
practical compromise for assisting chaining and other character-oriented
applications.


Vic Abell
Purdue University Computing Center