rfc1184.txt

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

   The reverse reading of this is that without the ECHO option or the
   SUPPRESS-GO-AHEAD option, you are in line at a time mode, implying
   local line editing.  This has the obvious problem that that is not
   what the SUPPRESS-GO-AHEAD option is supposed to mean.

   Other shortcomings are that the Telnet specification is not rich
   enough to handle all of the special characters that some of the
   current operating systems support.  For example, the ECHO/SGA
   implementation supports two ways of interrupting a process, by
   borrowing the BRK option for the second interrupt.  Some
   implementations have taken the EOR option to send an End-Of-File.
   Obviously, this is using things for which they were not intended, and
   the correct solution would be to define new options.

   Another problem is that some implementations of line mode buffer up
   the input until the end of the line, and then send the whole line
   across, editing characters and all.  No local editing of the line has
   been done.

   After examining several implementations, it has become clear that the
   correct thing to do is to implement new options to enhance the
   current Telnet specification so that it can support local line
   editing in a reasonable, reliable, and consistent manner.



Telnet Working Group                                           [Page 12]

RFC 1184                 Telnet Linemode Option             October 1990


   There are three states that are of interest.

      1) Local line editing and local signal trapping

      2) Remote line editing, local signal trapping

      3) Remote line editing, remote signal trapping

   The case of local line editing and remote signal trapping is not a
   very interesting case, because you don't recognize the signals, and
   cannot send them to the remote side for it to recognize until the
   line has been completed.  Also, special signals usually will have an
   effect on the line editing function, and if they are not being
   trapped locally the desired action will not happen.

   Local line editing means that all normal command line character
   processing, like "Erase Character" and "Erase Line", happen on the
   local system, and only when "CR LF" (or some other special character)
   is encountered is the edited data sent to the remote system.

   Signal trapping means, for example, that if the user types the
   character associated with the IP function, then the "IAC IP" function
   is sent to the remote side instead of the character typed.  Remote
   signal trapping means, for example, that if the user types the
   character associated with the IP function, then the "IAC IP" function
   is not sent to the remote side, but rather the actual character typed
   is sent to the remote side.

5.  Implementation Rules

   It is expected that any implementation that supports the Telnet
   LINEMODE option will support all of this specification.

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



Telnet Working Group                                           [Page 13]

RFC 1184                 Telnet Linemode Option             October 1990


          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).

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.  Specificly, 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



Telnet Working Group                                           [Page 14]

RFC 1184                 Telnet Linemode Option             October 1990


   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.

      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.




Telnet Working Group                                           [Page 15]

RFC 1184                 Telnet Linemode Option             October 1990


   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
   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



Telnet Working Group                                           [Page 16]

RFC 1184                 Telnet Linemode Option             October 1990


   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.

   Whenever an IAC AO is received, a Synch must be returned.  When ever
   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 Working Group                                           [Page 17]

RFC 1184                 Telnet Linemode Option             October 1990


5.9 State diagram for SLC

   +---------------------------------------------------------------+
   |                                IDLE                           |
   +----------------------+------+------+-------+-------+---------++
    ^      ^     ^        |      | ^    | ^     | ^     |       ^ |
    |      |     |        v      v |    | |     | |     v       | |
    |      |     |    +------+ +---+--+ | |     | | ########### | |
    |      |     |    | Get  | | Send | | |     | | #   Get   # | |
    |      |     |    | SPC0 | | SPC0 | | |     | | # 0,DEF,0 # | |
    |      |     |    +---+--+ +------+ | |     | | ########### | |