rfc1116.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,179 行 · 第 1/4 页

5.1 User Interface

   Normally, the entire user interface is left up to the implementor.
   However, there is functionality that the user should be able to
   specify on the client side of the connection.  During a Telnet
   session, the client side should allow some mechanism for the user to
   give commands to the local Telnet process.  These commands should at
   least allow the user to:

      1)  Change the mode of the connection.  The user should be able
          to attempt to turn EDIT, FLOW, TRAPSIG, and ECHO on and off.
          The server may refuse to change the state of the EDIT and
          TRAPSIG bits.

      2)  Import or export SLC.  The user should be able to tell the
          local Telnet process whether he wants to use the local or
          the current or default remote definitions of the special
          characters.

      3)  Manual sending of options.  The user should be able to tell
          the local Telnet process to explicitly send any of the Telnet
          options (like IP, ABORT, AYT, etc.).





Telnet Linemode Working Group                                  [Page 11]

RFC 1116                 Telnet Linemode Option              August 1989


5.2 End of line terminators

   When LINEMODE is turned on, and when in EDIT mode, when any normal
   line terminator on the client side operating system is typed, the
   line should be transmitted with "CR LF" as the line terminator.  When
   EDIT mode is turned off, a carriage return should be sent as "CR
   NUL", a line feed should be sent as LF, and any other key that cannot
   be mapped into an ASCII character, but means the line is complete
   (like a DOIT or ENTER key), should be sent as "CR LF".

5.3 Output processing

   Regardless of what mode has been negotiated, the server side is
   responsible for doing all output processing.  Specifically, it should
   send "CR LF" when it wants the "newline" function, "CR NUL" when it
   wants just a carriage return, and "LF" when it wants just a linefeed.

5.4 A terminal driver in Telnet?

   Conforming implementations need not do all the line editing
   themselves.  There is nothing wrong with letting the system terminal
   driver handle the line editing, and have it hand to the Telnet
   application the completed and edited line, which is then sent to the
   remote system.

5.5 Setting of Local Characters

   When this RFC was being developed, the original thought was that both
   sides of the connection would use their own defaults for the special
   characters, even if they were not the same on both sides of the
   connection.  If this scheme is used, though, the view that the user
   has is that the local special characters are being used, and the
   remote character settings don't matter.  It was decided that the
   client side of the connection should be in control of the character
   settings.

   When LINEMODE is negotiated, the client must either export the local
   character settings to the server, or send a request (SLC 0
   SLC_DEFAULT 0) to import the servers special characters.  The usual
   action would be that a client running on a full fledged computer
   would export the special characters, and a client running where there
   are no local defaults (like on some terminal servers) would import
   the special characters.

   When an SLC command is received, the action taken should be:

      1)  Ignore it if it is the same as the current settings.




Telnet Linemode Working Group                                  [Page 12]

RFC 1116                 Telnet Linemode Option              August 1989


      2)  If the SLC_LEVELBITS are the same as the current level bits,
          but the value is different and the SLC_ACK bit is set, no
          reply is generated.  On the server side, the command is
          ignored, and on the client side, a switch is made to the new
          value.  This is so that if a request to change the same
          character is generated by both the server and the client,
          they will both settle on the clients requested value.

      3)  If we agree with the new setting, we switch to it and reply
          with the same value, but also set the SLC_ACK bit.

      4)  If we don't agree, we send a response with what we think
          the value should be.  The SLC_ACK bit is NOT set in this
          case.  You may only disagree with a value by sending a
          different value at a lower level.

   If the remote system doesn't support some of the line editing
   characters, but the front end does, then the front end may use the
   local definitions for those characters when in line mode.  In this
   case, the server should send "SLC xxx SLC_DEFAULT 0" in response to a
   "SLC 0 SLC_DEFAULT 0" request, and just ack whatever value the client
   requests to set the function to.

   The SLC_FORW2 character should only be used if SLC_FORW1 is already
   in use.

5.6 FORWARDMASK and SLC_FORW1 and SLC_FORW2

   To help ease the amount of work needed to implement the client side,
   two methods of setting forwarding characters are provided.  The
   SLC_FORW1 and SLC_FORW2 allow for the setting of two additional
   characters on which to forward buffered input data.  Since many
   terminal drivers have the ability to set one or more line delimiters,
   it is fairly easy to support these without having to implement
   through the local terminal driver, rather than putting a terminal
   driver into Telnet.  If the local terminal driver has functionality
   that maps easily into the FORWARDMASK, then it can also be easily
   supported.  If the local terminal driver does not support that, then
   it would require more work to support FORWARDMASK.

   Also note that the client side is required to forward data when it
   sees one of SLC_FORW1, SLC_FORW2, or FORWARDMASK characters, or when
   any normal line termination or special signal is encountered.  The
   client side is also free to forward on other characters that it
   chooses.  For example, if the server side sent a FORWARDMASK that
   asked for data to be forwarded on the first 20 control characters
   (ASCII codes 1 through 024), and the client side cannot have its
   local terminal driver forward on just the first 20 control



Telnet Linemode Working Group                                  [Page 13]

RFC 1116                 Telnet Linemode Option              August 1989


   characters, but it can have the local terminal driver forward on any
   control character (ASCII codes 1 through 039), then the client side
   could validly accept the FORWARDMASK, and forward on any control
   character.  When in EDIT mode, care should be taken to not forward at
   random times, since once that data is forwarded, no more editing on
   the forwarded part of the line can be done.  The only time (other
   than the normal times) that data should be forwarded when in EDIT
   mode would be if a single input line is too long to handle locally.

5.7 Valid and invalid modes and values

   At no time should "DO LINEMODE" be negotiated in both directions of
   the Telnet connection.  The side that is the "DO LINEMODE" is
   considered to be the server side, and the side that is "WILL
   LINEMODE" is the client side.

   At no time should "SB LINEMODE DO/DONT FORWARDMASK", be sent unless
   "DO LINEMODE" has been previously negotiated.  At no time should "SB
   LINEMODE WILL/WONT FORWARDMASK", be sent unless "WILL LINEMODE" has
   been previously negotiated.

   If an ABORT, EOF or SUSP, is received and the system does not support
   that functionality, it may just be ignored.

5.8 Flushing input and output

   When an IP, BRK or ABORT is sent, it is usually desirable to be able
   to flush the input stream, and to flush output to the user until the
   IP, BRK, or ABORT is processed.  The SLC_FLUSHIN and SLC_FLUSHOUT
   bits are used to indicate what action should be done.  These bits are
   advisory only, but should be honored if possible.  The standard
   method for processing the SLC_FLUSHIN is to use the Telnet "Synch"
   signal, and the SLC_FLUSHOUT is processed using the TIMING-MARK
   option.  If both are to be sent, the IAC DM is sent before the DO
   TIMING-MARK.  Thus, the sender would send "IAC XXX IAC DM IAC DO
   TIMING-MARK", where XXX may be IP, BRK or ABORT, or any other special
   character.  The IAC DM is sent as TCP urgent data with the DM as the
   last (or only) data octet; this is used to flush the input stream.
   The "IAC DO TIMING-MARK" is used to tell when to stop flushing
   output; once it is sent, all data is discarded until an "IAC WILL
   TIMING-MARK" or an "IAC WONT TIMING-MARK" is received.

   Since the SLC_FLUSHIN and SLC_FLUSHOUT bit are only advisory, the
   user interface should provide a method so that the user can override
   the sending (or not sending) of the "Synch" and TIMING-MARK, but the
   default action should be to send them according to the SLC_FLUSHIN
   and SLC_FLUSHOUT bits.




Telnet Linemode Working Group                                  [Page 14]

RFC 1116                 Telnet Linemode Option              August 1989


   Whenever an IAC AO is received, a Synch must be returned.  Whenever a
   Synch is being processed, (by the TCP connection going into Urgent
   mode), all data must be discarded (but not Telnet commands!) until an
   IAC DM is found, and the connection goes out of Urgent mode.  See RFC
   854, "TELNET PROTOCOL SPECIFICATION", for a complete description of
   the Synch signal.













































Telnet Linemode Working Group                                  [Page 15]

RFC 1116                 Telnet Linemode Option              August 1989


5.9 State diagram for SLC

   +---------------------------------------------------------------+
   |                                IDLE                           |
   +----------------------+------+------+-------+-------+---------++
    ^      ^     ^        |      | ^    | ^     | ^     |       ^ |
    |      |     |        v      v |    | |     | |     v       | |
    |      |     |    +------+ +---+--+ | |     | | ########### | |
    |      |     |    | Get  | | Send | | |     | | #   Get   # | |
    |      |     |    | SPC0 | | SPC0 | | |     | | # 0,DEF,0 # | |
    |      |     |    +---+--+ +------+ | |     | | ########### | |
    |      |     |        |       ^     | |     | |     |       | |
    |      |     |        v       |     v |     | |     v       | |
    |      |     |       / \      | *********** | | ########### | |
    |      |     |     /     \    | *  Send   * | | # Switch  # | |
    | ********** |Yes/ Same as \  | * 0,VAL,0 * | | # to      # | |
    | * Change * +--<  current? > | *********** | | # default # | |
    | * to new *     \         /  |             v | ########### | |
    | * value  *       \     /    |     ***********     |       | |
    | **********         \ /      |     *  Send   *     v       | |
    |      ^              |No     |     * 0,DEF,0 *  #########  | |
    |      |Yes           v       |     ***********  # Send  #--+ |
    |     / \            / \      |                  # SPC-A #    |
    |   /     \        /     \    |                  #########    |
    | / Is ACK  \ Yes/  Same   \  |                     ^         |
    |< bit set?  ><-<  level as > |                     |         |
    | \         /    \ current?/  |                 ###########   |
    |   \     /        \     /    |                 #   Get   #<--+
    |     \ /            \ /    +-+---+             # 0,VAL,0 #
    |      |No            |No   | Set |             ###########
    |      +--------------+     | ACK |
    |                     v     | bit |      * - Client side only
    |                    / \    +-----+      # - Server side only
    |   +------+       /     \      ^
    |   | Send |  No /  Do we  \ Yes|
    +---| SPC1 |<---<   agree?  >---+
        +------+     \         /
                       \     /
                         \ /