Crockett (
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
                                        AN/GYQ-21(V) Program
                                        EATON Information Management Systems

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