Re: TELNET question

William Chops Westfield <> Wed, 16 November 1994 03:52 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa16338; 15 Nov 94 22:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16323; 15 Nov 94 22:52 EST
Received: from by CNRI.Reston.VA.US id aa23656; 15 Nov 94 22:52 EST
Received: from ( []) by (8.6.9/8.6.9M) with SMTP id TAA05154; Tue, 15 Nov 1994 19:48:39 -0600
Received: by (5.0/CRI-5.15.b.orgabbr Sdiv) id AA21356; Tue, 15 Nov 1994 19:48:30 -0600
Received: from by (5.0/CRI-5.15.b.orgabbr Sdiv) id AA21351; Tue, 15 Nov 1994 19:48:24 -0600
Received: from ( []) by (8.6.9/8.6.9M) with ESMTP id TAA05097 for <>; Tue, 15 Nov 1994 19:48:02 -0600
Received: (billw@localhost) by (8.6.8+c/CISCO.SERVER.1.1) id RAA21539; Tue, 15 Nov 1994 17:46:59 -0800
Date: Tue, 15 Nov 94 17:46:59 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Chops Westfield <>
To: Lee Chastain <>
Subject: Re: TELNET question
In-Reply-To: Your message of Tue, 15 Nov 94 11:00:03 MST
Message-Id: <>
Content-Length: 2607

    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.