rfc1053.txt

中、英文RFC文档大全打包下载完全版 .

     Codes 1 through 127 -- ASCII code of word-delete character.

Parameter 130, extension set 1 -- Flow control OFF character.

     Parameter 131, extension set 1 -- Flow control ON character.
     Typing these characters while parameter 12 is enabled cause output
     to be suspended or resumed, respectively.  The user telnet may send
     them to the user while parameter 5 is enabled to ask the user to
     cease or resume supplying input.



Levy & Jacobson                                                [Page 16]

RFC 1053                 Telnet X.3 PAD Option                April 1988


     If defined, these parameters should have default values of 19
     (ASCII DC3) for parameter 130, and 17 (ASCII DC1) for parameter
     131.

     Code 0 -- No character has this function.
     Codes 1 through 127 -- Function performed by that ASCII code.

Parameter 132, extension set 1 -- Host-to-user flow control convention.

     Some styles of flow control accept only a particular character
     (e.g., X-ON) to resume output; others resume on receipt of any
     character.  This parameter selects which to use.  The default
     should be zero, as this matches the X.3 convention.

     Code 0 -- Resume output only when correct character is received.
     Code 1 -- Resume output when any character is received.

Parameter 133, extension set 1 -- Alternate Attention, etc., character.

     This character serves as a synonym for the Break, Attention, etc.,
     key whose function is given by parameter 7.

     Code 0 -- No ASCII character has this function
               (there may still be a special key or other mechanism).
     Codes 1 through 127 -- ASCII code of the character.

Parameter 134, extension set 1 -- Local echo style.

     This parameter selects how non-printing characters should be
     echoed, when parameter 2 is set to 1.  The default should be zero,
     where all characters are simply echoed as themselves (except
     possibly carriage return; see parameter 13).

     Code 0 -- All characters echo as themselves.
     Code 1 -- Non-editing control characters echo as ^X for some
               printable character X.

     See also parameters 2, Local echo, and 20, Echo mask, which may
     suppress echo of some or all characters regardless of this
     parameter.

Parameter 135, extension set 1 -- Accept following character as data.

     After typing this character, the next character entered is accepted
     as data for transmission to the host even if it would normally have
     a special meaning.

     The default should be zero.



Levy & Jacobson                                                [Page 17]

RFC 1053                 Telnet X.3 PAD Option                April 1988


     Code 0 -- No character has this function.
     Codes 1 through 127 -- ASCII code of the character.

Parameter 136, extension set 1 -- Character to toggle discarding output.

     Typing this character changes the state of parameter 8 (discarding
     host-to-user output) from 0 to 1 or from 1 to 0.  Thus an
     indeterminate amount of host output, received between successive
     instances of this character, will be discarded.

     As usual, the host should be notified of each change if parameter 0
     is set to 1.  The host might wish to send SET messages at
     appropriate points (e.g., preceding command prompts) to re-enable
     output.

     The default should be zero.

     Code 0 -- No character performs this function (though another
     mechanism still may do so).

     Codes 1 through 127 -- Typing that character toggles parameter 8.

Parameter 137, extension set 1 -- User-to-host bits per character.

Parameter 138, extension set 1 -- Host-to-user bits per character.

     These parameters determine whether, for example, a full 8-bit input
     or output data path is available, or whether the most significant
     bit(s) of input or output data is stripped.  Typical values would
     be 7 or 8.

     Note that an 8-bit data path does not by itself imply transparent
     input/output; CR -> CR LF translation, XON/XOFF interpretation,
     parity and so on must also be disabled to achieve this.

7.  Subsets, Extensions and Conflicts

   An option as complex (and easy to extend) as this one, needs a policy
   for what subsets and extensions are allowed, and recommendations for
   negotiating one's way through a maze of partial implementations.  In
   short, what does it mean to say DO or WILL X.3-PAD?

   A basic principle is that, since hardly any user telnet
   implementation will provide all possible features, a host cannot
   expect to get precisely any desired kind of service.

    [This may be an arguable point.  The CCITT defines a mandatory
    subset of supported values for each X.3 parameter, with further



Levy & Jacobson                                                [Page 18]

RFC 1053                 Telnet X.3 PAD Option                April 1988


    values optional.  For example, the set of forwarding characters,
    parameter 4, must accept at least the values 0 (none), 2 (carriage
    return), and 126 (any control character or DEL).  Though it would be
    possible to adopt the CCITT's set of mandatory values there, I don't
    think that would be desirable for two reasons.

    First, some of the features specified (e.g., timed input) may be
    hard to implement in some environments, and may well not be
    necessary for many applications.

    Second, this option provides for definition of entirely new
    parameters.  Unlike the X.3 case, one peer may use parameters whose
    very existence is unknown to the other.  So one cannot specify
    mandatory or default values for ALL parameters.]

   On the other hand, a host is at least entitled to know what kind of
   service is being provided to the ultimate user.  A user telnet's
   status report may be incomplete (not describing features its
   implementor did not know of); it may not describe the style of
   interaction the host (or user, or application) would wish for, but it
   should at least describe reality.

   For telnet parameters with a range of possible values, if a user
   telnet implements only one "enabled" and one "disabled" value, it
   should choose the "enabled" value when asked for a setting it cannot
   supply.  A VMS telnet, for example, might allow only DEL or nothing
   as the character-delete code.  If a host asks it to use "backspace",
   it should choose DEL rather than nothing. The host may then interpret
   this contrary behavior as indicating a preferred value.

   The problem of conflicting parameters, where several parameters
   control overlapping services and may conflict, is a serious one. The
   extension set scheme (see parameter 128) is intended to limit the
   problem.  Each extension set's parameters should be selfconsistent
   and consistent with the CCITT X.3 parameters, but separate extension
   sets need not be concerned with each other's parameters.

   Where parameters might conflict, it is important to specify priority
   as part of the parameters' description.  For example, among
   parameters 2 (Local echo), 20 (Echo mask), and extension set 1's 134
   (Local echo style), Echo mask is significant only if Local echo is
   enabled, and Local echo style applies only to characters selected for
   echoing by the first two parameters.

   This option's functions overlap with those of some existing Telnet
   options, for example, ECHO (which can be interpreted to affect local
   echo and possibly local line editing), NAOCRD and NAOLFD [6]
   (specifying padding after output carriage returns and line feeds),



Levy & Jacobson                                                [Page 19]

RFC 1053                 Telnet X.3 PAD Option                April 1988


   TRANSMIT-BINARY, Remote Controlled Transmission and Echo [3], and
   SUPDUP [4].

   Where X.3-PAD completely subsumes the function of another option, as
   for ECHO, NAOCRD and NAOLFD, it's probably best to let the X.3-PAD
   option, where acceptable to both sides, supplant them and to refuse
   the other option.

   The TRANSMIT-BINARY option can change (actually suppress) the
   interpretation of some bits of parameter 13 related to Telnet newline
   encoding, as mentioned under that parameter.  As such it is
   compatible with this option but must be kept in mind.

   RCTE would be a much more difficult case, since its service does not
   fit into this option's scheme and vice versa.  However, it probably
   is unimportant because of the scarcity of RCTE implementations.

   Some existing Telnet options can serve related but complementary
   functions, for example NAOHTS [7] for output tab handling, or
   TERMINAL-TYPE [8].

8.  Implementation suggestions

     It is strongly recommended that a user telnet support at least the
     combination with parameters 2=0, 3=126, and 4=1 (no local echo,
     forward immediately or nearly so on any input character) so that a
     dissatisfied host has the option of backing off and doing its own
     character handling.

     The "discard output" function invoked by the Break, Interrupt,
     Attention, etc., key if the 16's bit is set in parameter 7 may be
     implemented as follows.

           1.  When the key is pressed, set parameter 8 to 1, begin
               discarding output, send IAC SB X.3-PAD IS  8 1  IAC SE to
               notify the host.  (It may not need to know, but the
               message should be sent for consistency.)

           2.  Send IAC DO TIMING-MARK.

           3.  Send any other messages associated with the key (e.g.,
               IAC IP).

           4.  Eventually, the host should send either IAC WILL
               TIMING-MARK or IAC WON'T TIMING-MARK, even if it knows
               nothing about the TIMING-MARK option.  It will probably
               appear close, in the output stream, to the point where
               the host recognized any associated messages (e.g., IP).



Levy & Jacobson                                                [Page 20]

RFC 1053                 Telnet X.3 PAD Option                April 1988


               When the TIMING-MARK arrives, reset parameter 8 to 0 and
               cease discarding output.  Send IAC SB X.3-PAD IS  8 0
               IAC SE.

   The Telnet SYNCH mechanism (see [2]) may be employed in concert with
   such a scheme.  A closed-loop flush, though, will be more effective
   at discarding excess output than SYNCH used alone.  Provision of some
   such mechanism for discarding unwanted output, e.g., after
   interrupting the host, is heartily recommended.

   Discarding input is less clear cut.  Certainly, any buffered data not
   yet sent should be discarded; one might also use SYNCH to encourage
   the host telnet to discard more.

9.  References

     1.  Recommendation X.3, from International Telecommunications Union
         CCITT Red Book, volume VIII, fascicle VIII.2, 1984.

     2.  Postel, J., and J. Reynolds, "Telnet Protocol Specification",
         RFC-854, USC Information Sciences Institute, May 1983.

     3.  Postel, J., and D. Crocker, "Remote Controlled Transmission and
         Echoing Telnet Option", RFC-726 and NIC-39237, SRI-ARC, March
         1977.

     4.  Crispin, M., "SUPDUP Protocol", RFC-734 and NIC-41953, SU-AI
         October 1977; Crispin, M., "Telnet SUPDUP Option", RFC-736 and
         NIC-42213, SU-AI, October 1977; also Greenberg, B., "Telnet
         SUPDUP-OUTPUT Option", RFC-749 and NIC-45499, MIT-Multics,
         September 1978.

     5.  Postel, J., and J. Reynolds, "Telnet Binary Transmission
         Option", RFC-856, USC Information Sciences Institute, May 1983.

     6.  Crocker, D., "Telnet Output Linefeed Disposition Option", RFC-
         658 and NIC-31161, UCLA-NMC, October 1974; and "Telnet Output
         Carriage Return Disposition Option", RFC-652 and NIC-31155,
         UCLA-NMC, October 1974.

     7.  Crocker, D., "Telnet Output Horizontal Tab Stops Option", RFC-
         653 and NIC-31156, UCLA-NMC, October 1974.  [RFC numbers 652
         through 658 (NIC 31155 through 31161) are in a similar vein.]

     8.  Solomon, M., and E. Wimmers, "Telnet Terminal Type Option",
         RFC-884, University of Wisconsin - Madison, December 1983.





Levy & Jacobson                                                [Page 21]