Thu, 6 Aug 87 07:30:58 PDT
(yet another long message)
1) Before I am chastised severely for my interpretations of the TELNET
protocol, I would like to note that much of the work that I perform
is related to communications over networks used within the DoDIIS
community. The acceptance of the DDN network architecture to replace
AUTODIN, DSSCS/DIN, IDHSC II, etc. presents some interesting problems.
First, the DoDIIS community has a significant involvement with Digital
Equipment Corporation and, in particular, PDP11 processors and the IAS
operating system. Second, there is a desire not to invalidate a rather
significant investment in software that has been developed over the
last ten (10) years. Third, there is a migration to LAN architectures
which permit workstations (PCs) to replace directly connected terminals.
As a result, the implementation and interpretation of TELNET is rather
significant. The Digital IAS, RSX-11M (PLUS), and VMS TT drivers/handlers
trigger on <CR> as the end-of-line terminator. From the perspective
of these operating systems, an <LF> is generally regarded simply as a
vertical positioning command to the next line from the current cursor/
print head position. TELNET software provided with various DDN protocol
suite packages present particular problems when they are too blatant in
their UNIX style treatment of an end-of-line condition (\n).
2) For the DDN three (3) different TELNET specifications/standards have
been established. They are:
a. RFC 854 which governs the ARPANET,
b. MIL-STD-1782 which governs the MILNET, and
c. DoDIIS TELNET Specification which governs other subnets that
are currently separated from the ARPANET and MILNET.
RFC 854 does not have the legal stature of a standard and cannot be
specified for government procurements; therefore, MIL-STD-1782 which
is a legal standard is the document that must be conformed to when
providing TELNET to DoD or other governmental agencies. The RFC and
the MIL-STD are essentially the same except that some of the asides
and discussions contained in the RFC have been abbreviated or deleted.
The most significant departure from the RFC is the deletion of the
reference to "...a companion document, 'TELNET Option Specifications',
which should be consulted..." and the inclusion of a set of appendices
which define the options that are required in the MIL-STD.
The DoDIIS TELNET Specification has the most significant differences
primarily as a result of the Network Virtual Data Entry Terminal
(NVDET) abstraction definition. In contracts, the DoDIIS TELNET is
generally specified in addition to the MIL-STD to include the NVDET.
[The neat trick is how to determine whether the remote terminal is
an NVT or an NVDET since some of the option defaults are different.]
3) My original comments on the use <CR><NUL> and <CR><LF> were based on
my interpretation of MIL-STD-1782. From my reading of RFC 854, there
is no reason for me to change my interpretation. Both documents state
that a "...<CR><LF> must be treated as a single 'new line' character
and used whenever their combined action is intended; the sequence <CR>
<NUL> must be used where a carriage return alone is actually desired...".
The following excerpt is from the discussion of the GA option but is
equally valid when discussing the action taken when a <CR> is encount-
"The 'local' computer is no longer able to decide whether to
retain control after seeing an end-of-line signal or not; this
decision can only be made by the 'remote' computer which is
processing the data."
When the ENTER or RETURN key is struck, the local host has no idea
what the intended action is to be and therefore should transmit a
<CR><NUL> and allow the remote host to provide the interpretation.
The transmission of a <CR><LF> is presumptuous except when the
user enters a <LF> as the next character.
In the case of a 'gateway' computer, it should perform absolutely
no conversions and pass the data on as it was received. <CR><NUL>
input, <CR><NUL> output. <CR><LF> input, <CR><LF> output.
4) An interesting question is what will happen when a TELNET connection
is used to edit, read, or write an AUTODIN message. The AUTODIN ELF
is <CR><CR><LF>. (Believe it or not, there are still devices out
there that require the <CR><CR> before the <LF> to compensate for
head travel time)
Merton Campbell Crockett
EATON Information Management Systems
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:49 GMT