rfc318.txt

RFC 的详细文档！

   6)  Correctly processes the Telnet signals BREAK, SYNCH, NOP, ECHO,
       NOECHO, and Hide Your Input received from the server.

   Serving Site:

   1)  Provides a mapping between ASCII and the local character set.

   2)  Correctly processes the Telnet signals BREAK, SYNCH, NOP, NOECHO,
       and ECHO.

   3)  Implements the CR LF end-of-line convention.

   4)  Assumes the using site provides echoing.  May provide a server
       echo mode.

MINIMUM TELNET IMPLEMENTATION

   Using Site:

   1)  User must be able to enter and transmit all ASCII codes.

   2)  Ignore and delete all Telnet signals from the serving site.

   3)  Provide local echo for local user terminals.

   4)  Implements CR LF end-of-line convention.

   5)  Provide for the User Telnet signals.








Postel                                                          [Page 6]

RFC 318                     Telnet Protocol                   April 1972


   Serving Site:

   1)  Provide a mapping between ASCII and the local character set.

   2)  Ignore and Delete all Telnet signals from the using site.

   3)  Assume the using site provides echoing.

   4)  Implements the CR LF end-of-line convention.

III.  DISCUSSION OF TELNET PROTOCOL

   The use of a standard, network-wide, intermediate representation of
   terminal code between sites is intended to eliminate the need for
   using and serving sites to keep information about the characteristics
   of each other's terminals and terminal handling conventions.  This
   approach can be successful, but only if the user, the using site, and
   the serving site assume certain responsibilities.

   1.  The serving site must specify how the intermediate code will be
       mapped by it into the terminal codes that are expected at that
       site.

   2.  The user must be familiar with that mapping.

   3.  The using site must provide some means for the user to enter all
       of the intermediate codes, and as a convenience, special Telnet
       signals, as well as specify for the user how the signals from the
       serving site will be presented at the user terminal.

   Other schemes were considered but rejected.  For example, a proposal
   that the using site be responsible for translating to and from the
   code expected by the serving site was rejected since it required that
   the using site keep tables of all serving site codes and provide a
   mapping for each case.  The information would require constant
   maintenance as new hosts were added to the network.

Character Set

   Since it is not known how the current or future sites will specify
   the mapping between the network-wide standard code (7 bit ASCII in an
   8 bit field) and the codes expected from their own terminals, it
   seems necessary to permit the user to cause transmission of every one
   of the 128 ASCII codes, plus (for full user power) selected signals
   (either of a Telnet control nature, or of a special terminal nature
   such as break or attention).





Postel                                                          [Page 7]

RFC 318                     Telnet Protocol                   April 1972


   There was strong feeling about the importance of the user/system
   interface at the using site, but equally strong feeling that this
   problem is one of local implementation and should reflect the using
   site installation philosophy rather than be subject to network-wide
   standards.  Some topics of consideration in this area are:

      1.  How to represent special graphics, not available at the using
          site, at the user's terminal.

      2.  Treatment of upper/lower case problem on upper case only
          devices.

          a.  Representing lower-case output.

          b.  Providing users with shift and shiftlock signals.

      3.  Incorporating editing capability in Telnet.

      4.  Extending user options in Network mode not available to local
          users, e.g., hold output or kill print.

      5.  Permit users to specify how keyboard input is to the
          translated, e.g., let a character from the terminal cause a
          specified string to be sent by the user's Telnet.

   The proposed solution to the Telnet Protocol problem seems to provide
   a mechanism for a minimum implementation while providing a basis for
   developing richer sets or protocol for present and future use in
   terminal applications, process-process communications, and use by
   other conventions to pass data or control information.

   The understanding that ASCII be used as a network-wide code has been
   established for some time.  Its use in Telnet provided a problem with
   respect to the limitation of a maximum character set of 128.  Some
   systems provide for more than this number in their operation, and
   therefore, as serving sites, cannot map on a one-for-one basis.

   Each such serving site could probably provide a reasonably useful
   character set, including all system control signals, by mapping 128
   of its codes and just not provide a network user access to the other
   codes.  However, any character left out might later be used in a
   major application at that site as a special control signal.  This
   could result in denying network users the facility offered by that
   application.  Serving sites are, therefore, encouraged to provide a
   full mapping between the ASCII code and the code used on the serving
   system.  This may require that the server specify two character ASCII
   sequences which map to single characters in the servers character
   set.



Postel                                                          [Page 8]

RFC 318                     Telnet Protocol                   April 1972


   Notice that there are some ASCII codes which have no effect on the
   NVT printer.  These codes must be transmitted over the network when
   output by the serving process or by entered by the user.

End of Line Convention

   The representation of the end of a physical line at a terminal is
   implemented differently on different network hosts.  For example,
   some use a return (or new line) key, the terminal hardware both
   returns the carriage or printer to start of line and feeds the paper
   to the next line.  In other implementations, the user hits carriage
   return and the hardware returns carriage while the software sends the
   terminal a line feed.  The network-wide representation is carriage
   return followed by line feed.  It represents the physical formatting
   that is being attempted, and is to be interpreted and appropriately
   translated by both using site and serving site.

      EXAMPLE:  A Multics user is working, through the network, on some
      serving site host.  In the course of the session the user has
      numerous occasions to hit New Line on his Model 37 TTY.  Each time
      the Multics system is awakened by a New Line interrupt, the line
      of buffered characters is passed to Telnet where it is scanned for
      special characters.  If none is found, carriage return followed by
      line feed is inserted where New Line was entered, and the line is
      turned over the NCP for transmission.  Correspondingly, when the
      Multics Telnet finds the carriage return line feed sequence in the
      data stream coming from the serving site, the two characters are
      replaced with the appropriate New Line code which is sent to the
      terminal.

   Telnet defines the end of a line to be indicated by the ASCII
   character pair CR LR.  Several of the real devices in the world have
   only a single new line (NL) function.  Several of the computer
   systems have in some programs used the CR and LF functions to have
   semantic meaning larger than the format effect they provide.
   Further, several computer systems allow the CR and LF functions to be
   used separately (e.g., such that a line may be overprinted).  One
   problem, for those Telnet (user) programs required to map the NVT
   into a device which only has a NL function, is how is the CR LF to be
   dealt with.  One solution is to examine the character following the
   CR.  If an LF is found, then perform the NL function; if anything
   else is found then back space to the beginning of the line.  Another
   problem is the case of a computer system which locally uses period,
   ".", to cause the new line function and which uses, in some programs,
   CR and LF for semantically significant operations.  Suppose the user
   Telnet sends the sequence CR LF.  Does this mean "new line" or the
   "CR operation" followed by the "LF operation "?  A solution to this
   problem it to require that Telnet programs send a CR NOT intended to



Postel                                                          [Page 9]

RFC 318                     Telnet Protocol                   April 1972


   be part of a CR LF pair as a CR NUL pair.  Then the receiving program
   can always hold a CR and examine the next character to determine if a
   new line function is intended.  This solution is strongly
   recommended.

   One other question arises here,  "Is it permitted to send the Telnet
   signal NOP (code 130) between a CR and a LF when these are intended
   to signify new line?"  The answer is "yes, the NOP signal may occur
   anywhere in the data stream."

Echoing

   The decision to have the assumed condition for echo be that the using
   site will provide any echo necessary for its terminals was taken
   because of the difficulties faced by some installations that cannot
   turn off their echo or that have terminals that print locally as a
   result of key strokes.  Serving sites could take the position "have
   user turn echo off," but this seems an unnecessary burden on the
   user.  In addition, some serving sites may choose not to supply any
   echo service, in which case the no echo assumption will supply a
   network-wide condition, while other assumptions would give a mixed
   starting condition.

   The convention of using "ECHO," "NO ECHO" signals seems to fill both
   the requirements for dynamic echo control and for a minimum
   implementation of Telnet Protocol.  Note that when the user request
   ECHO or NO ECHO the server replies by switching to the desired mode
   (and possibly returning the signal for the new mode), or by
   continuing in the current mode and returning the signal for the
   current mode.  The server never spontaneously sends an ECHO or NO
   ECHO signal.  Except that a NOECHO may be used to cancel a HIDE YOUR
   INPUT.

Hide Your Input

   The HIDE YOUR INPUT signal presents some difficulty in that it is
   unclear how much is to be hidden.  The server site usually knows how
   long the secret is but the user Telnet in general does not.
   Furthermore, if the user site cannot suppress the local echoing,
   there is a difficult implementation problem.  One possibility is for
   the using site to overprint a full line with a mask, then have the
   user type his secret on the mask.  If the secret were longer than one
   line, the use of the mask should be repeated.

   The use of HIDE YOUR INPUT can be avoided altogether by having the
   serving site send a mask (which it knows to be just long enough) on
   which the user is to type the secret information.




Postel                                                         [Page 10]

RFC 318                     Telnet Protocol                   April 1972


      EXAMPLE:

         1.  Default assumption is user site is echoing

         2.  Server-to User:  Password Please CR LF

         3.  Server-to-User:  XXXXCRIIIIICRMMMMCR NUL

         4.  User-to-Server:  "password" CR LF

         5.  Server-to-User:  Ready CR LF

Breaks and Attentions

   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.  This signal is represented by the Telnet control
   signal BREAK.  There is a corresponding control signal for use from
   serving sites to using sites for reverse break.  Notice, however,
   that the NVT is a bi-directional character device, thus there is no
   need to "turn the line around".

   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 special interrupt fashion, to mean
   stop processing the application and give me the supervisor, or cancel
   the present job, etc.  (Other systems which inspect input on a
   character at a time basis use normal characters for this purpose,
   such as <etx>.) In these cases, because of differences in the ways