Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!A.ISI.EDU!PADLIPSKY
From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TELNET incompatibility questions
Message-ID: <12471722189.18.PADLIPSKY@A.ISI.EDU>
Date: 18 Feb 89 20:16:08 GMT
References: <8800001@uxg.cso.uiuc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26

The design intent of Telnet IP and AO (about which it happens I can speak
with complete confidence) was certainly that USER Telnets must have the
ability to convey the user's desire to invoke the respective functions
to Server Telnets.  (Explicit note was taken that not all Servers offer
AO, and that we weren't demanding more of them than they would offer in
their native states.  This also applied to not expecting the output to
stop immediately, since some systems would have no way of getting at
data already in the "lowest" output buffers.  For that matter, I expect
the same principle ought to apply to the issue of whether User Telnets
need to get into the act at all on stanching the flow, but let that
ride.)  Therefore, the onus in the case you cite should be on the User
Telnet to give the user a way to cause the Generic Function Codes
in question to be sent to the Server.  Nor should the corresponding
onus on ALL Servers to recognize the GFCs be overlooked, by the way--
for, at any rate, each of the Generic Functions they have specific
native versions of (i.e., let's not forget Erase, Kill, and Are You
There either).

Of course, User Telnets are traditionally deficient; that it's traditional
doesn't make it right, however:  As it says in The Book, the first time
I (and Multics) ever was approached by a User Telnet, it couldn't even
send lower-case--which Multics needed (and I wanted)--and nearly 18 years
(by now) haven't dimmed the indignation (much, anyway).

   cheers, map
-------