Re: TELNET question

[Lee Chastain <[e-mail]>]

Bill, thanks for the input; see my comment and further question below.
> 
> Well, this makes the tester pretty broken.  A lot of client telnet
> implementations assume that the server is going to initiate
> negotiations for most features.  If the tester doesn't, it won't test
> the most commonly used paths...

I agree; the tester is VERY broken, but some of its tests are still of value 
and we are looking into having it fixed.  At the least, we will fully 
document the deficiencies.
As for option testing, when that is the purpose of the test it performs
as expected.  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 ?

> 
> A lot of unix telnets detect when the remote port is NOT the telnet
> port, and start up the connection with a lot of local handling (line
> mode, local interrupts, etc.)  I'm not sure that the initial settings
> would be the same in the abscense of telnet negotiations on the normal
> telnet port or not.
> 

Ted's comment is similar to yours:
> 
> What many telnets do is that if the remote port is NOT the telnet port,
> then they will *not* try to initiate any options negotation.  This is
> because many users use telnet as a convenient way to talk to other
> servers, such as SMTP or NNTP servers, by doing "telnet machine 25" and
> type SMTP commands at it.  Since the SMTP deamon isn't a telnet server
> at all, it would get really confused by a series of telnet options
> negotiation sequences.  (However, the client telnet will accept any
> option negotiations that the server offers.)
> 
> 

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

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.

I would like to try to reach a consensus on this through this mail list,
if possible - my current tasking is the validation of this tester for the
DoD, and the outcome could affect all of us to some degree.  If it's the
testing methodology that's at fault, be advised that the suite of tests
for SMTP and FTP are similarly affected.

You may remember my earlier question relating to obsolete options in the
new MIL-STD profile - those comments have been forwarded to the proper
contacts and the MIL-STD 2045-17506 Remote Login Profile is being revised.
The tester will be held to that standard.  Please comment on this current
problem by 30 Nov, and I will post the results on the morning of 1 Dec.

Thanks, Lee Chastain.
Open Systems Testing Laboratory, JITC.
Fort Huachuca, AZ 85613
Fax: [phone]