Re: TELNET question

[William Chops Westfield <[e-mail]>]

    The tester sets up a TELNET server on a non-standard port (2300) for a 
    TELNET USER test.  The tester and the IUT are both SUN workstations; the 
    user is operating from a SUN-CMD cmdtool window.

    I have noticed that when this implementation of TELNET connects to a
    port other than 23, option negotiation does not take place, and the
    server (being a tester) does not propose or request any options.

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...

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.


    The problem arises out of a test for the handling of newlines; if I
    understand correctly, the default newline under the conditions I've
    outlined should be the <CR LF>.  However, the server sends just the
    <LF> and the user TELNET Implementation Under Test (IUT) processes it
    as a newline character.

Once again, the tester is broken.   Yes, it should be terminating
lines with CRLF.  However, see below...

    I know that 0A <LF> is the native newline
    character for these systems, but are they allowed by the TELNET
    protocol to default to anything other than <CR LF> ?

Here we run into a fundamental question: "When is a telnet connection
sending lines?"  One can easilly argue that unix, and most other modern
computer systems, are not line oriented on their terminal or virtual
terminal, but rather character oriented, and therefore telnet should just
send a character stream between the client and server (some of those
characters will happen to be carriage returns (CR NUL) and Linefeeds (LF),
but that's just conincidental, and whether those happen to terminate a
semi-mythical "line" is random and indeterminate.

However, a server that sends terminal-oriented data with no CRs ("lines"
terminated by LF only) is clearly broken, since the chances that this will
show up on a remote terminal the same as it would on a local terminal
(which is THE GOAL) are very slim (eg here, the client and server are
exchanging data in an "internal" format, which is clearly contrary to the
spirit of a "network virtual terminal") A server that terminates "lines"
with CR NUL LF is perfectly legal, and should work fine.

BillW
cisco