[comp.protocols.tcp-ip] <CR><LF> Processing

mcc@ETN-WLV.EATON.COM (Crockett) (07/24/87)

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

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	mcc@etn-wlv.eaton.com
	AN/GYQ-21(V) Program