Re: Wollongong telnet and new line processing

Crockett (
Sat, 25 Jul 87 11:54:45 PDT

I submitted this previously but probably performed the submission incorrectly.


I don't have a copy of RFC 854; however, I do have MIL-STD-1782 which
defines the implementation requirements for the TELNET Protocol for DDN
MILNET and other DDN subnetworks. The end of line character is a <CR>
which moves the cursor or print head to the beginning of the current

The standard became confusing when it attempted to accomodate physical
terminals that generate a <CR><LF> sequence when the ENTER or RETURN key
is struck. To permit the use of these terminals a two octet end of line
function (ELF) was defined. For terminals that could generate a <CR>
and a <LF> independently, the ELF was defined to be a <CR><NUL>. For
those that couldn't, the ELF was defined to be <CR><LF>.

Regardless of any echo options that may be in effect, the user (local)
host is responsible for transmitting only the keyboard input from the
terminal to the server (remote) host. If the RETURN key generates a
<CR><LF>, it is to be mapped to a <CR><NUL> prior to transmission over
the network. If the NVT is being operated in its default line buffered
full duplex mode with local echo, the user host echoes both ELF
variations as a <CR><LF> to the terminal display.

At the server host <CR>, <CR><NUL>, and <CR><LF> are to be treated
identically and mapped to the host's local interpretation of the
character or character sequence that is passed to the application
software when the RETURN key is struck. When the virtual circuit is
being operated in half duplex mode with the server echoing data back to
the user, it transmits either a <CR><NUL> or <CR><LF> with the ELF form
being dependent upon the server's local convention.

The original problem that raised the question of the NVT ELF was a
difference in operation when a terminal (workstation) was connected on a
local LAN segment or on a remote LAN segment requiring the use of a
gateway to make the transition between the LAN segments. The answer is
that both Woologong and the Bridge CS/1 have errors or have been
configured incorrectly.

Any host in the network that functions as a gateway is responsible for
ensuring that the data transmitted is the same as what was received.
The sequences <CR><LF> and <CR><NUL><LF> are not necessarily equivalent.
The gateway can not compress the sequence <CR><NUL><LF> to <CR><LF>.

The problem I have seen with a number of hardware and/or software
products that implement TCP/IP, TELNET, FTP, SMTP, and UDP is that the
vendor has based his product on the 4.x bsd implementation. The problem
with the vendors that have done that is that they have failed to go back
through the software and remove all the tacit assumptions that the host
system will be running a UNIX or UNIX derivative operating system. Some
vendors have even removed code to support the options that are to be
negotiated always responding with a DO or WILL when they should be
responding with a DON'T or WON'T because they know that 4.x bsd always
attempts to negotiate to the same mode of operation.

Invariably these products have problems when one attempts to use them on
a PDP11 or VAX based AN/GYQ-21(V) systems which use the IAS and VMS
operating systems, respectively.

                                Merton Campbell Crockett
                                AN/GYQ-21(V) Program
                                EATON Corporation
                                Information Management Systems Division

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:48 GMT