rfc139.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      Terminal

         Turn printer off, feed transparently to special device, look
         for LEAVE signal

      ------------>

         8 bit binary bytes...LEAVE signal...single DLE
         X'A0'

      <-----------

         X'88'X'88

      ------------>

      Message

       |
       |
       V
         8 bit binary data...LEAVE signal MESSAGE




O'Sullivan                                                      [Page 6]

RFC 139              Discussion of TELNET Protocol            7 May 1971


      _Terminal_

      During this sequence of exchanges - at the terminal, feed binary
      data to special device until LEAVE signal is sensed, strip off
      LEAVE signal, turn on printer and block data path to special
      device, print MESSAGE at terminal.

   There is a special control signal on some terminals that has no
   corresponding bit pattern in ASCII, but is transmitted by a special
   electrical signal.  This control signal is ATTN on a 2741 and BREAK
   on a teletype.  The ASCII DATA TYPE in TELNET will use the code X'81'
   to represent BREAK.  (There is a corresponding control signal for use
   from serving sites to using sites for reverse break, and it is
   assigned the code X'82').

   Some systems treat the break as an extra code available for use in
   conjunction with the data stream.  For example, one system uses break
   as a special editing code meaning "delete the current line to this
   point".  In these cases, the code may simply be inserted in the data
   stream with no special additional action by the user.

   Other systems use BREAK or ATTN in a special interrupt fashion, to
   mean stop processing the application and give me the supervisor, or
   cancel the present job, etc.  (Other systems use normal characters
   for this purpose, such as "Control C".)  In these cases, because of
   differences in the ways both serving and using sites operate, it is
   necessary to take a route in addition to the normal TELNET data
   stream to signal that the special control signal is imbedded in the
   data stream.

      _Examples-Problem_

      The PDP-10 normally will, when it fills its input buffer, continue
      to accept characters from a terminal examining each to see if it
      is a control character, then act on it if it is or throw it away
      if it is not.

      Since the TELNET server at the serving site is at the mercy of the
      NCP with respect to controlling the bunching, and therefor,
      arrival at the TELNET of bursts of characters, TELNET
      implementations might be expected to choke off flow to the buffers
      until they are ready to accept characters without throwing them
      away.

   Under this condition, the serving process might be outputting to the
   using terminal, the input buffers fill up, and a control C get stuck
   in the data stream that has been choked off.




O'Sullivan                                                      [Page 7]

RFC 139              Discussion of TELNET Protocol            7 May 1971


   A similar problem could occur with the Multics or some IBM system as
   a server.  The user at a using site gets into an output loop at the
   serving site and wants to break the process without having to release
   his TELNET connection.  The buffers clog the connection, transmission
   is choked off, and the control C break, or other user control signal
   gets stuck in the pipeline.

   _Example - Solution_

   The user at the using site knows he is entering a special control
   signal (break, ATTN, control C, etc.) and follows it with an X'80'.
   (The local instructions at using sites for accomplishing this may
   differ from site to site.)

      Using Site TELNET to Serving Site

         Insert X'80' in Data Stream

      Using Site TELNET to Using Site NCP

         Send an INS

      Sending Site NCP to TELNET Server

         Look out, here she come

      Serving Site TELNET

         Does its special thing until it sees X'80' then resumes
         normal handling

   Thus, depending on the server's local implementation to provide
   adequate service, a special handling of the data stream can be
   invoked whenever an INS is received in order to get the special
   character.  When it sees X'80', it recognizes it as a SYNC character
   and knowing that the special character has been passed on, strips the
   X'80' from the data stream and returns to normal mode.

   If the X'80' arrives before the INS, a counting scheme can keep the
   activity appropriate to the serving site conditions.

   This approach to handling selected special characters or signals
   relieves the using TELNET processes from having to recognize the
   special serving site characters, as well as from having to know how
   the serving site wants to handle them.  At the same time, the






O'Sullivan                                                      [Page 8]

RFC 139              Discussion of TELNET Protocol            7 May 1971


   procedure requires only a minimum level of user understanding of the
   serving site.  This seems appropriate, since the TELNET ASCII
   conventions are providing a Network Virtual Terminal, not a Network
   Virtual User.

   The ability of the user to cause the using site TELNET to send any
   combination of ASCII characters in a string, and only that
   combination, is viewed as important to the user utility of the TELNET
   ASCII conventions.  Because of this, some user sites may find it
   necessary to provide special local TELNET control signalling from the
   user to the using site.

      _Examples_

      A user on a line at a time system (Multics, System 360, GECOS,
      etc.)  is working through the Network on a serving site that
      operates a character at a time.  The application is a debugging
      aid that permits the user to type in a memory location = to which
      it will respond with n where n represents the current contents of
      that location.  The serving site process does not expect to see
      the location = followed by a carriage return line feed sequence.
      The user at the using site should be able to type in the location,
      follow it with a signal to suppress the end of a line convention,
      followed by a new line or return, and expect the location number =
      to be transmitted immediately without an end of line sequence.

      In another case, a using site has decided that it is convenient to
      accumulate four characters at a time and transmit them to the
      serving site, unless an end of line is observed, in which case the
      end of line sequence is sent preceded by whatever number of
      characters have been accumulated, (presumably three or less).  In
      the same debugging application, the address is such that the end
      does not correspond with the four character buffer demarcation.
      The user should have the ability to enter a code for "transmit
      immediately" in place of the Carriage Return in order to preserve
      neat formatting, and expect the address to be sent to the serving
      site.

      TELNET controls have been discussed and those introduced to date
      are probably sufficient for an early implementation of TELNET
      ASCII convention.  There will be a need to establish a mechanism
      for the controlled assignment (on request by Network Sites), and
      announcement of DATA TYPE and CONTROL codes.

      It should be noted that some controls are network-wide TELNET
      controls, while others are specific to the ASCII Data Type.  It
      should be further recognized that some local control messages do
      not require a corresponding network-wide code.



O'Sullivan                                                      [Page 9]

RFC 139              Discussion of TELNET Protocol            7 May 1971


      While it is recognized that even a minimum implementation of
      TELNET for a using site is expected to permit the user to send any
      selected ASCII string (and only that string) to the serving site,
      it is not necessary for a serving site to implement a full mapping
      from ASCII to local code, nor is it necessary for either the using
      or serving sites to implement all control codes.

      _Example - Using Site_

      A minimum implementation of the TELNET protocol for the using site
      would permit ignoring (and stripping) any control signals from the
      serving site since they would all either require agreement or
      acknowledgement (e.g., DATA TYPE, ECHO CONTROL, etc.) or can be
      ignored with no particularly harmful results (e.g., reverse
      break).

      _Example - Serving Site_

      A minimum implementation of the TELNET protocol for the serving
      site could provide one for one mapping for the most important 128
      serving system controls and graphic signals, and ignore all
      control signals.

   It would be helpful if a minimally implemented receiving site, when
   it recognizes an incoming control signal for which appropriate
   reaction is not available, could respond with X'87' (The following
   not implemented at this site) and follow it with the code just
   received.

   Whenever an ASCII TELNET connection is lost, it should be assumed
   that the process at the other end of the connection has been quit,
   aborted, failed, etc.  In this way, a minimum using site installation
   can fail to implement the break and break synchronization, and have
   the user rely on the using site local procedure for leaving a running
   local process and returning to the supervisor to break a connection
   to a remote serving site.

      _Example_

      User recognizes that he is caught in an output loop and wishes to
      stop his user process at the serving site.  The serving site
      requires a break, but the using site minimum implementation has
      not made it available.  Even if it had, the INS was not
      implemented and could not be used to unblock the input pipe.
      Locally, the using site convention for leaving a process and
      getting to supervisory level is to hit the attention key on the
      2741 terminal.  The user does this and is passed to the supervisor
      where he signals to release the TELNET connection.  The serving



O'Sullivan                                                     [Page 10]

RFC 139              Discussion of TELNET Protocol            7 May 1971


      site, seeing that an ASCII TELNET connection has been lost,
      assumes that the user is ended either normally or abnormally.
      Serving site cancels the user's process.  The user tries again by
      re-establishing the connection, logging in again, re-initiating
      the process, etc.

   Other conventions under TELNET may make quite different assumptions
   about lost connections, and some may go as far as dynamic
   establishing and releasing of connections.

   The proposed TELNET ASCII implementation leaves much uncovered, but
   seems to permit early simple implementation with varying levels of
   capability, along with the capacity to expand in several ways to meet
   others needs.

   There is an important open question.  Should a PROTOCOL such as
   TELNET provide the basis for extending a system to perform functions
   that go beyond the normal capacity of the local system.  For example,
   a local system may not provide functions such as Hold Output, Kill
   Print, etc., but it could extend it for network purposes through
   TELNET.  If so, to what extent should such extensions be thought of
   as Network-wide standards as opposed to purely local implementations.

Endnotes

   [1] Please drop the (s) at the end of "character" in paragraph 3,
   page 3, RFC 137, NIC #6714.

   [2] Also make note that the starting assumption in the initial
   exchange between using site and serving site will be that the using
   site will (if necessary) provide echo and the serving site will not.

   [3] Note: Please change RFC #137, NIC #6714, page 4 - Code X'85' to
   read Reserved.

   [4] Please note on page 4 of RFC 137 that the receipt of an X'88'
   should be responded with by the receiver sending a double signal,
   i.e., X'88'X'88' if the new DATA TYPE can be handled.

   [5] Cent sign

          [This RFC was put into machine readable form for entry]
           [into the online RFC archives by Lorrie Shiota, 1/02]








O'Sullivan                                                     [Page 11]