mcc@ETN-WLV.EATON.COM (Crockett) (08/06/87)
(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-
ered.
"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
AN/GYQ-21(V) Program
EATON Information Management Systems
mcc@etn-wlv.EATON.COMjas@MONK.PROTEON.COM (John A. Shriver) (08/06/87)
So why can't the IAS system be generous and accept <CR><NUL> or <CR><LF> and type <CR> on the virtual teletype, and type <LF> on the virtual teletype when <LF> is received? The general interpretation in the Internet community is that <CR><LF> is what is sent as the generic end-of-line on input. (Making this change would be consonant with the robustness principle of TCP.) Of course, IAS can generate whatever it want on output, and it the user Telnet does the wrong thing with it, then shame on it. I think part of the clarity problem in the spec is that it does not adequately seperate the meanings on input and output.
mcc@ETN-WLV.EATON.COM (Crockett) (08/08/87)
Sorry for not responding earlier to your message, John. I fully intend to have a robust implementation under IAS; however, I want to be sure that I understand what TELNET is doing and what it expects. There are some IAS processes that a user could invoke during a TELNET session that utilize <CR>, <LF>, or <ESC> as line terminators. What the process will do is dependent upon which line terminator is used. I would prefer not to change any of these processes to distinguish between a local terminal and a TELNET terminal or to prohibit the use of these processes to a TELNET terminal. At the moment we have a crude brute force TELNET port which suffers due to archtectural differences between UNIX and IAS and will produce an unacceptable system load in the target application system environment. Our current TELNET port is based on one of our vendors upper layer protocol support package for his TCP/IP board level implementation for an Ethernet interface. It's attrocious! The code looks okay until you notice '/*' and '*/' surrounding rather significant portions of code. When linked to our 4.3bsd gateway machine, we found that it lies about its ability to perform some of the options. Unlike Unix, VMS, RSX-11M (11M PLUS), etc. which have device and pseudo drivers that are integrated into the operating system; IAS has independent tasks referred to as handlers to support devices and pseudo devices. The thought was to split "telnetd" into one portion that was to listen for and accept connections and to integrate the remainder of it with the pseudo terminal handler which significantly reduces the number of context switches that would be required to pass data between the Ethernet interface handler, telnetd, and pseudo terminal handler. I could go off and do whatever I please since the rest of the world won't be permitted access to the network until a "secure" gateway can be developed but it seemed nicer to plan for the future when there will be a common backbone for all the networks. Merton Campbell Crockett