Re: TELNET question

[Theodore Ts'o <[e-mail]>]

   Date: Thu, 17 Nov 94 09:38:47 MST
   From: [e-mail] (Lee Chastain)

   In the current (newline) test I assume no negotiation was done so
   that it wouldn't interfere with the testing of the default
   conditions. Given that the server/tester was wrong to send just the
   LF, wasn't the user implementation also wrong to process it as a
   newline rather than just a 'plain' LF ?

As far as the telnet protocol is concerned, yes, an implementation that
processes an LF as a "move carriage to the left hand margin and scroll
the network virtual terminal up one line" is in violation of the telnet
specification.  

Certainly if the implementation is doing even when connecting to port
23, and acting as a telnet client, then it's doing something wrong.

   The question boils down to this:  Is a TELNET user only a proper implementation
   of TELNET when the server port is 23?         ^^^^

You mean "client" where you wrote "user", right?

That's really the crux of the matter.  The RFC's document the telnet
*protocol*.  The question is when is the client obligated to follow the
telnet protocol, and when is it not so obligated?

   The consequences are as follows:

   1.  No - TELNET is TELNET regardless of the server port :
       Then any implementation which defaults to LF as a newline (such as
       unix-based hosts) is not conformant to the TELNET standard.
       (Possible interoperability problems).

   2.  Yes - TELNET is only TELNET when the server port is 23:
       Not only did the tester send the wrong character(s), but its testing
       methodology is seriously flawed; the use of the non-standard port
       means that it is not truly testing TELNET, whether it had sent the
       correct newline code or not.

Give that the IANA has specified that the port for telnet service is 23,
I would tend towards option 2.  The fair way to test things is on the
original port.

I think it is a "local matter" what the telnet client does going to
other ports.  Ideally, there should be a switch that indicates where or
not the client should be initiating the options negotiations.  How that
switch is offered ought to be presented to the user is a UI issue, and
not one that should be addressed in a protocol specification.  (And,
indeed, there is such a switch on the Berkeley reference implementation;
you simply prefix the port number that you specify with a '-'
character.)

						- Ted