Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!ETN-WLV.EATON.COM!mcc From: mcc@ETN-WLV.EATON.COM (Crockett) Newsgroups: comp.protocols.tcp-ip Subject: TELNET ELF Message-ID: <8708061430.AA19988@etn-wlv.eaton.com> Date: Thu, 6-Aug-87 10:30:58 EDT Article-I.D.: etn-wlv.8708061430.AA19988 Posted: Thu Aug 6 10:30:58 1987 Date-Received: Sat, 8-Aug-87 10:48:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 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 as the end-of-line terminator. From the perspective of these operating systems, an 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 and 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 "... must be treated as a single 'new line' character and used whenever their combined action is intended; the sequence 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 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 and allow the remote host to provide the interpretation. The transmission of a is presumptuous except when the user enters a 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. input, output. input, 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 . (Believe it or not, there are still devices out there that require the before the to compensate for head travel time) Merton Campbell Crockett AN/GYQ-21(V) Program EATON Information Management Systems mcc@etn-wlv.EATON.COM