home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1000s / rfc1053.txt < prev    next >
Text File  |  1988-04-14  |  48KB  |  1,179 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            S. Levy
  8. Request for Comments: 1053                                   T. Jacobson
  9.                                           Minnesota Supercomputer Center
  10.                                                               April 1988
  11.  
  12.  
  13.                          Telnet X.3 PAD Option
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This RFC proposes a new option to Telnet for the Internet community,
  19.    and requests discussion and suggestions for improvements.
  20.    Distribution of this memo is unlimited.
  21.  
  22. 1.  Command name and code
  23.  
  24.    X.3-PAD                30
  25.  
  26. 2.  Command meanings
  27.  
  28.    IAC  DO     X.3-PAD
  29.  
  30.       The issuing telnet requests that its peer perform X.3-PAD
  31.       functions, or accepts an offer to do so.
  32.  
  33.    IAC  DON'T  X.3-PAD
  34.  
  35.       The issuing telnet demands that its peer not perform or cease
  36.       performing X.3-PAD functions.
  37.  
  38.    IAC  WILL   X.3-PAD
  39.  
  40.       The issuing telnet offers to perform X.3-PAD functions or confirms
  41.       that it will do so.
  42.  
  43.    IAC  WON'T  X.3-PAD
  44.  
  45.       The issuing telnet refuses to perform X.3-PAD functions or
  46.       indicates that it is ceasing to handle them.
  47.  
  48.    Typically a server (host) telnet will use DO and DON'T, while a
  49.    client (user) telnet will use WILL and WON'T.  For convenience, in
  50.    the rest of this RFC 'host' and 'user' telnets refer to those saying
  51.    'DO X.3-PAD' or 'WILL X.3-PAD' respectively.
  52.  
  53.    Both telnet peers may use this option without confusion, as all
  54.    messages unambiguously identify whether they come from the host
  55.  
  56.  
  57.  
  58. Levy & Jacobson                                                 [Page 1]
  59.  
  60. RFC 1053                 Telnet X.3 PAD Option                April 1988
  61.  
  62.  
  63.    ("DO") or the user ("WILL") side.
  64.  
  65.       Once DO and WILL have been exchanged, the host ("DO") telnet may
  66.       send the following messages:
  67.  
  68.    IAC SB  X.3-PAD  SET           <param1> <value1> ...  IAC SE
  69.    IAC SB  X.3-PAD  RESPONSE-SET  <param1> <value1> ...  IAC SE
  70.    IAC SB  X.3-PAD  SEND          IAC SE
  71.  
  72.       while the user ("WILL") telnet may send the following messages:
  73.  
  74.    IAC SB  X.3-PAD  IS            <param1> <value1> ...  IAC SE
  75.    IAC SB  X.3-PAD  RESPONSE-IS   <param1> <value1> ...  IAC SE
  76.  
  77.    The code for SET          is 0
  78.    The code for RESPONSE-SET is 1
  79.    The code for IS           is 2
  80.    The code for RESPONSE-IS  is 3
  81.    The code for SEND         is 4
  82.  
  83.       Messages listing parameter-value pairs may contain any number of
  84.       such pairs, including zero.  Each parameter and each value
  85.       occupies one octet, except that 255 (IAC) is doubled wherever it
  86.       appears.
  87.  
  88. 3.  Default conditions
  89.  
  90.    The initial state is DON'T X.3-PAD, WON'T X.3-PAD.  This RFC does not
  91.    specify default values for most X.3 parameters.  If the host telnet
  92.    wishes a particular initial state (as it normally will), it should
  93.    negotiate for it after exchange of DO/WILL messages.
  94.  
  95.    X.3-PAD parameter values need not be preserved except when DO/WILL
  96.    X.3-PAD is in effect.  Thus if a host enables ("DO") X.3-PAD,
  97.    negotiates about some parameters, then for some reason disables
  98.    ("DONT") and later re-enables X.3-PAD, it must renegotiate any
  99.    parameters it cares about.
  100.  
  101.    Keeping in mind that the host telnet may not recognize all the
  102.    parameters known to the user telnet, it is suggested that the user
  103.    telnet's initial parameters allow a reasonable level of service even
  104.    if they are never changed (e.g., it would be unwise to begin with all
  105.    data forwarding conditions disabled).  Extensions to X.3 should
  106.    default to states resembling normal X.3 service where possible.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Levy & Jacobson                                                 [Page 2]
  115.  
  116. RFC 1053                 Telnet X.3 PAD Option                April 1988
  117.  
  118.  
  119. 4.  Motivation for the option
  120.  
  121.    Where interactive terminals (or computers simulating them) are
  122.    attached to host computers across a network, it is often desirable to
  123.    provide them the same services as have long been provided for
  124.    terminals directly attached to those hosts.
  125.  
  126.    Many systems handle this by simply leaving all character processing
  127.    to the host running the applications.  Each character typed by the
  128.    user is sent, often in its own packet, immediately to the host.  This
  129.    gives good control over interaction, but can cause a significant load
  130.    on hosts and networks.  Long-distance packet networks tend to be
  131.    unreasonably slow or expensive or both when used in this mode.
  132.  
  133.    Suitable character processing on the client (near the user's
  134.    terminal) can greatly improve the situation.  Unfortunately for
  135.    standardization efforts, there are many possible approaches with
  136.    differing purposes.
  137.  
  138.    Some have already been proposed as Telnet options.  The Remote
  139.    Controlled Transmission and Echo option, [3], provides fine control
  140.    over local buffering and echoing.  The SUPDUP option, [4], offers a
  141.    variety of input and display functions in terminal-independent form.
  142.  
  143.    This RFC's proposal is intended to support efficient, approximate
  144.    emulation, across a Telnet connection, of a host's normal handling of
  145.    character-oriented terminals.  Ideally, a user and an application
  146.    program would not need to know whether they were linked by an RS-232
  147.    line or a TCP/IP network, except where the medium required a
  148.    distinction (e.g., when establishing a connection).
  149.  
  150.    Server implementors would wish for enough to emulate, purely locally,
  151.    everything offered by their host's operating system; on the other
  152.    hand, a standard calling on user telnets to provide all terminal
  153.    handling functions of all known operating systems will find few
  154.    implementors.  One might settle on a subset of common operations, but
  155.    which ones?
  156.  
  157.    The CCITT world has used one approach to these problems: the set of
  158.    PAD services defined by recommendation X.3.  This RFC proposes that
  159.    the Internet community adopt that solution to handle the same
  160.    problems under Telnet.  It is fairly simple, widely known and used,
  161.    extensible, and solves most of the relevant problems.
  162.  
  163.    Adopting X.3 would have another advantage.  X.25 is the dominant
  164.    worldwide standard interface between commercial packet networks and
  165.    Internet systems, as evidenced by the DDN's adoption of X.25 basic
  166.    and standard services as replacements for BBN 1822 and HDH.  Telnet
  167.  
  168.  
  169.  
  170. Levy & Jacobson                                                 [Page 3]
  171.  
  172. RFC 1053                 Telnet X.3 PAD Option                April 1988
  173.  
  174.  
  175.    and X.3 PAD traffic will have to coexist on X.25 networks; there will
  176.    be a consequential desire for effective interoperation at the virtual
  177.    terminal level.  Extending Telnet along these lines would vastly
  178.    simplify bridging the two.
  179.  
  180.    Described here is a scheme for implementing X.3 services and
  181.    negotiating their parameters across a Telnet connection.
  182.  
  183. 5.  Description of the option
  184.  
  185.    Many, though not all, X.3 services are meaningful in the context of
  186.    remote terminal processing; for some, it may be desirable to allow
  187.    local control (by the user) but not remote control (by the server
  188.    host).  Some functions may not be provided, or provided in only
  189.    limited form, by particular implementations.  In general, an
  190.    implementation should follow the Telnet norm of requesting desired
  191.    service but continuing to function somehow in case it is not
  192.    available.
  193.  
  194.    Negotiations are asymmetrical.  Since the user telnet is charged with
  195.    local character handling while engaged in the session with the remote
  196.    host, the X.3 parameters "belong" to the user side.  The host telnet
  197.    requests parameter changes with SET or RESPONSE-SET messages.  Host
  198.    requests might be on behalf of an application program, for example,
  199.    disabling local echo while a password is being entered.  The user
  200.    telnet should give its "best effort" to accommodate these requests,
  201.    but guarantees nothing except accurate status reporting.
  202.  
  203.    A user telnet may allow the local user to request parameter changes
  204.    too, though this RFC does not specify a way.
  205.  
  206.    Where requests conflict, or where a user telnet cannot satisfy a
  207.    request, the user telnet has the last word, since it does the
  208.    relevant character processing.  It may allow control from the host
  209.    only, from the user only, may seek a compromise type of processing
  210.    and so on, at the implementor's discretion.
  211.  
  212.    Host ("DO") telnets may also ask the user telnet to SEND its current
  213.    parameter values.  The user ("WILL") telnet must reply to each SEND
  214.    message with a RESPONSE-IS message listing the values of all the
  215.    parameters it knows about.  It is strongly recommended that all
  216.    parameters known to the telnet implementor be included in this list,
  217.    even if their values cannot be changed.  The intent is to give the
  218.    host telnet the most complete information possible about the style of
  219.    interaction which the user telnet is providing.
  220.  
  221.    If possible, user telnets should also inform the server host (with an
  222.    IS message) whenever local conditions (e.g., user requests) change a
  223.  
  224.  
  225.  
  226. Levy & Jacobson                                                 [Page 4]
  227.  
  228. RFC 1053                 Telnet X.3 PAD Option                April 1988
  229.  
  230.  
  231.    parameter's state.  This may not be feasible in some circumstances,
  232.    and such behavior is negotiable -- see the discussion of parameter 0.
  233.  
  234.    Note that there are no "error" messages defined in section 2.  Almost
  235.    all detectable errors (use of nonexisistent parameters or undefined
  236.    values for known parameters) are indistinguishable from valid uses of
  237.    options known to one peer but not the other.  Hosts will normally
  238.    wish to poll the user telnet's state after making a request anyway,
  239.    so error responses do not seem to be needed.
  240.  
  241.    The protocol messages listed in section 2 are to be used as follows.
  242.  
  243.    SET and RESPONSE-SET ask the user telnet to change its values for the
  244.    given X.3 parameters.  The user telnet ignores unrecognized
  245.    parameters; it sends no reply.  The host sends SET to begin a
  246.    negotiation, when some event on the host side causes a change in the
  247.    desired set of parameters.  The host sends RESPONSE-SET to continue
  248.    negotiation, when it is dissatisfied with the user telnet's choice of
  249.    parameters indicated in a RESPONSE-IS message.  Typically, the host
  250.    will test the user telnet's chosen behavior by issuing a SEND message
  251.    following the SET or RESPONSE-SET, though the user telnet should not
  252.    rely on this.
  253.  
  254.    A SEND message from the host demands that the user telnet send
  255.    RESPONSE-IS.
  256.  
  257.    IS and RESPONSE-IS inform the host telnet of the current states of
  258.    some or all of the user telnet's parameters.  The user telnet sends
  259.    IS when the user telnet changes a parameter for some local reason,
  260.    e.g., at a request from the (human) user.  An IS message may but need
  261.    not list all parameters, e.g., it might list just those which
  262.    changed.
  263.  
  264.    It sends RESPONSE-IS in answer to each SEND request from the host.
  265.    Every RESPONSE-IS should list ALL X.3-PAD parameters known to the
  266.    user telnet implementor, even those which cannot be changed.  Any
  267.    host requests (SET or RESPONSE-SET) received before a SEND message
  268.    should be processed before sending the answering RESPONSE-IS, so that
  269.    their effects are reflected in the parameter values indicated there.
  270.  
  271.    To permit synchronization (which SEND is this an answer to?), the
  272.    user telnet should count SEND messages, and send exactly one
  273.    RESPONSE-IS per SEND.
  274.  
  275.    One might think that this protocol could be implemented with only
  276.    SET, SEND and IS messages.  The seemingly redundant RESPONSE-SET and
  277.    RESPONSE-IS codes are needed to let both the user and host telnets
  278.    distinguish new peer requests from attempts to renegotiate previous
  279.  
  280.  
  281.  
  282. Levy & Jacobson                                                 [Page 5]
  283.  
  284. RFC 1053                 Telnet X.3 PAD Option                April 1988
  285.  
  286.  
  287.    actions, while preventing potential infinite negotiation loops.
  288.  
  289.    SET and IS messages are sent when the host or user telnet wishes to
  290.    inform its peer of a change in the X.3 processing mode desired by
  291.    some higher level entity.  This might happen at initialization, or on
  292.    user or application-program request.  The important thing is that
  293.    these messages are NOT sent merely in response to another X.3-PAD
  294.    message from the peer.
  295.  
  296.    RESPONSE-SET and RESPONSE-IS messages should be sent in reply to a
  297.    peer's [RESPONSE-]IS or SEND message.  They reflect negotiation at
  298.    the telnet level, rather than changes in the higher-level
  299.    environment.  A host which sends a SEND message may complain about
  300.    the status indicated in the answering RESPONSE-IS by sending
  301.    RESPONSE-SET but not SET.
  302.  
  303.    Under this scheme, a possible rule for preventing infinite
  304.    negotiations would be for the host to send at most zero, one, or some
  305.    fixed number, of RESPONSE-SET messages following receipt of one IS
  306.    message or one higher-level host-side request.  After that, the host
  307.    telnet simply accepts the user telnet's last offer as well as it can.
  308.    Note that only the host needs to worry about loop prevention, since
  309.    it does all the asking.
  310.  
  311.    A given parameter should not be listed more than once in a single
  312.    message.
  313.  
  314.    A sample negotiation might look like this.  (Here line breaks are not
  315.    meaningful; ASCII carriage returns and line feeds are indicated by
  316.    <CR> and <LF>; other characters stand for themselves.  In the IAC SB
  317.    octet values.)
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Levy & Jacobson                                                 [Page 6]
  339.  
  340. RFC 1053                 Telnet X.3 PAD Option                April 1988
  341.  
  342.  
  343.          Host:   <CR><LF>%
  344.                                           (User types "cd gibber<CR>")
  345.          User:   cd gibber<CR><LF>
  346.          Host:   Password required.<CR>LF>
  347.                                                (Host disables echoing)
  348.               IAC SB X.3-PAD SET 2 0 IAC SE
  349.                                                (Host polls for status)
  350.               IAC SB X.3-PAD SEND IAC SE
  351.          User:                        (User telnet has disabled local
  352.                                        echo.  Note that some
  353.                                        parameters (e.g., 9, 10, 11)
  354.                                        are not present, presumably
  355.                                        unimplemented, and a few
  356.                                        extension parameters
  357.                                        (129, 134) in extension
  358.                                        set 1 are also defined.)
  359.                IAC SB X.3-PAD RESPONSE-IS 1 29 2 0 3 2 4 0 5 0 7 17 8 0
  360.                                          12 0 13 3 15 1 16 8 17 21 18 0
  361.                                          128 1 129 23 134 1 IAC SE
  362.          Host:    password:
  363.                                               (User types "squeak<CR>",
  364.          User:    squeak<CR><LF>                  which is not echoed.)
  365.          Host:                                (Host re-enables echoing)
  366.                   IAC SB X.3-PAD SET 2 1 IAC SE
  367.                                               (Host polls for status)
  368.                   IAC SB X.3-PAD SEND IAC SE
  369.          User:
  370.                 IAC SB X.3-PAD RESPONSE-IS 1 29 2 1 3 2 4 0 5 0 7 17 8 0
  371.                                           12 0 13 3 15 1 16 8 17 21 18 0
  372.                                           128 1 129 23 134 1 IAC SE
  373.  
  374. 6.  Parameters
  375.  
  376.    In outline, the X.3-PAD option uses the following parameters.
  377.  
  378.       Parameter 0 indicates whether the user telnet notifies the host
  379.       about parameter changes made for local reasons.
  380.  
  381.       Parameters 1 through 22 are basically those of CCITT X.3, with
  382.       some changes in interpretation; they are listed in detail below.
  383.  
  384.       Parameters 23 through 127 are reserved for potential extensions to
  385.       CCITT's X.3 definition.
  386.  
  387.       Parameter 128 selects an "extension set", determining the meaning
  388.       of parameters 129 through 255.  One extension set is proposed in
  389.       this RFC, others may be added.  The extension mechanism is
  390.       explained under parameter 128's description.
  391.  
  392.  
  393.  
  394. Levy & Jacobson                                                 [Page 7]
  395.  
  396. RFC 1053                 Telnet X.3 PAD Option                April 1988
  397.  
  398.  
  399.       Parameters 129 through 255 are meaningful only when defined in the
  400.       extension set indicated by the current value of parameter 128.
  401.  
  402.    It should NOT be assumed that all implementations will necessarily
  403.    support all parameters defined here, or all values of those
  404.    parameters.  Supported parameter/value combinations, however, should
  405.    behave as described here.
  406.  
  407.    The following parameter is specific to this Telnet option.
  408.  
  409.    Parameter 0 -- Notify host of user-initiated parameter changes.
  410.  
  411.      Code 0 -- Host is not notified.
  412.      Code 1 -- User telnet notifies host by sending IS message.
  413.  
  414.      If the user telnet, for some local reason, changes a parameter,
  415.      should it send an IS message to the host?  This is desirable, since
  416.      the host telnet cannot be sure of knowing the user telnet's current
  417.      status otherwise.  On the other hand, some user telnets may be
  418.      unable to send notification.  Consider a user calling from an X.25
  419.      PAD through an X.25-to-telnet gateway.  The user may change local
  420.      PAD parameters freely, but since normal PADs send no message when
  421.      this happens, the gateway cannot inform the host telnet.  Moreover,
  422.      some sloppy host telnets may not wish to know about user parameter
  423.      changes.
  424.  
  425.      In normal usage, the host will ask to SET parameter 0 to its
  426.      preferred state upon initialization; the user telnet accepts the
  427.      setting if it can; then the host polls (using SEND) for the user
  428.      telnet's decision.  A disappointed host might periodically poll for
  429.      changes, or admonish the (human) user not to change parameters, or
  430.      remain silent and simply work oddly if changes are made.
  431.  
  432. The following parameters are as defined by the 1984 CCITT X.3 standard.
  433.  
  434. Numbers are in decimal.
  435.  
  436. Parameter 1 -- Character to escape to local telnet command mode.
  437.  
  438.      Code 0 -- No ASCII character performs this function (though
  439.                some special mechanism, e.g., a function key, still may).
  440.      Code 1 -- DLE (ASCII code 16).
  441.      Codes 32 through 126 -- ASCII code of the character.
  442.  
  443.      Codes 2 through 31 are not defined by X.3, but might also be taken
  444.      to refer to the corresponding ASCII control characters.  X.3 seems
  445.      to be unable to name SOH (control-A) as a command escape character.
  446.  
  447.  
  448.  
  449.  
  450. Levy & Jacobson                                                 [Page 8]
  451.  
  452. RFC 1053                 Telnet X.3 PAD Option                April 1988
  453.  
  454.  
  455. Parameter 2 -- Local echo of characters typed by the user.
  456.  
  457.      Code 0 -- No local echo.
  458.      Code 1 -- Local echo.
  459.  
  460.      Several echoing styles are possible.  Parameter 13 selects whether
  461.      a carriage return echoes as itself or as CR LF.  Parameter 20 may
  462.      suppress echoing of particular ASCII characters.  The extension
  463.      parameter 134 selects a style for echoing non-printing characters
  464.      such as ESC.
  465.  
  466. Parameter 3 -- Set of forwarding characters.
  467.  
  468.      The value is bit-encoded; each nonzero bit specifies a set of
  469.      characters.  The user telnet should accept characters from the
  470.      user's keyboard, buffering them until it receives any of the
  471.      specified characters (or until some other forwarding condition is
  472.      satisfied, see below), and then sending the buffer to the host.
  473.  
  474.      It may forward earlier if necessary, e.g., if it runs out of buffer
  475.      space.  It MUST eventually forward after receiving one of the
  476.      indicated characters.
  477.  
  478.      Code 0 -- No forwarding characters.
  479.      Code 1 -- Alphanumeric characters (a-z, A-Z, 0-9).
  480.      Code 2 -- CR.
  481.      Code 4 -- ESC, BEL, ENQ, ACK.
  482.      Code 8 -- DEL, CAN, DC2.
  483.      Code 16 -- ETX, EOT.
  484.      Code 32 -- HT, LF, VT, FF.
  485.      Code 64 -- ASCII character codes 0 through 31 not listed above.
  486.  
  487.      Note that there is no way provided here to forward on printable,
  488.      non-alphanumeric characters (punctuation marks).
  489.  
  490.      Codes may be added to select the union of the associated sets of
  491.      characters.
  492.  
  493. Parameter 4 -- Forward after idle time.
  494.  
  495.      When this parameter is nonzero, the user telnet sends its input
  496.      buffer to the host after a given period in which no characters are
  497.      typed, even if no forwarding character was received.
  498.  
  499.      Code 0 -- Infinite time limit.
  500.      Codes 1 through 255 -- Time limit in 1/20 second units.
  501.  
  502.      The value "1" may be taken to mean "forward immediately" if timed
  503.  
  504.  
  505.  
  506. Levy & Jacobson                                                 [Page 9]
  507.  
  508. RFC 1053                 Telnet X.3 PAD Option                April 1988
  509.  
  510.  
  511.      input is inconvenient to provide.  For other values, when timing is
  512.      available but the exact requested value is not, rounding to larger
  513.      time delays is suggested.  If timing is requested but none is
  514.      available, immediate forwarding on every character is much
  515.      preferred over an infinite time limit.
  516.  
  517.      Note the interaction with parameter 15, Local editing, and the
  518.      notes made under that heading.
  519.  
  520. Parameter 5 -- Flow control of user-to-host data.
  521.  
  522.      A user telnet may be overwhelmed by data typed by the user.  If
  523.      parameter 5 is 1, it may output X-OFF (DC3, ASCII code 19) to ask
  524.      the user to suspend input and X-ON (DC1, ASCII code 17) when the
  525.      user may resume typing.
  526.  
  527.      Code 0 -- X-OFF and X-ON considered normal output data.
  528.      Code 1 -- X-OFF and X-ON used to control user input.
  529.  
  530.      The extension parameters 130 and 131, if defined, specify other
  531.      codes to be used instead of ASCII DC3 and DC1.
  532.  
  533. Parameter 6, referring to messages sent from the PAD to the user,
  534.                 does not seem to be relevant in this context.
  535.  
  536. Parameter 7 -- Function of Break, Interrupt, Attention, etc.
  537.  
  538.      This parameter describes handling of some special key or other
  539.      character, implementation-defined, on the user's keyboard.  It is
  540.      bit-encoded; codes may be added to select multiple functions.
  541.      Multiple functions may be performed in any order.  Any messages
  542.      generated should be promptly sent to the host.
  543.  
  544.      Code 0 -- No action.
  545.      Code 1 -- Send interrupt packet (Telnet IAC IP).
  546.      Code 2 -- Reset (break Telnet connection).
  547.      Code 4 -- Discard input from user not yet consumed by host.
  548.      Code 8 -- Escape to local Telnet command mode.
  549.      Code 16 -- Discard output from host (see parameter 8).
  550.  
  551.      The X.25 'Interrupt', 'Reset', and 'Indication of Break' messages
  552.      are here translated to Telnet equivalents.  See section 8 for
  553.      suggestions on discarding input and output.
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Levy & Jacobson                                                [Page 10]
  563.  
  564. RFC 1053                 Telnet X.3 PAD Option                April 1988
  565.  
  566.  
  567. Parameter 8 -- Discarding output from host.
  568.  
  569.      This parameter is intended as a flag, indicating whether host
  570.      output is being ignored.
  571.  
  572.      Code 0 -- Host output is sent to user.
  573.      Code 1 -- Host output is discarded.
  574.  
  575.      This parameter is normally used in conjunction with parameter 7
  576.      when the 16's bit (Discard output on Break/Interrupt/Attention) is
  577.      set.  An implementation is suggested in section 8 of this RFC.
  578.  
  579.      Note that, if a signal from the user causes parameter 8 to be
  580.      changed and parameter 0 is set to 1, an X.3-PAD IS message should
  581.      be sent to the host.
  582.  
  583. Parameter 9 -- Padding after carriage return.
  584.  
  585.      This parameter selects insertion of ASCII NUL padding characters
  586.      after output of each carriage return.
  587.  
  588.      Codes 0 through 7 -- Insert that many padding characters.
  589.  
  590. Parameter 10 -- Line folding.
  591.  
  592.      Output lines may be folded (e.g., by insertion of carriage return
  593.      and line feed) when they exceed a specified width.
  594.  
  595.      Code 0 -- No output line folding.
  596.      Codes 1 through 255 -- Fold lines after that many characters.
  597.  
  598. Parameter 11 -- Bit rate.
  599.  
  600.      This parameter indicates the serial data rate of the user's
  601.      terminal, if any.  Though CCITT X.3 considers this parameter to be
  602.      read-only, it may be meaningful to allow the host to set as well as
  603.      read this value, thus changing the user's line speed dynamically.
  604.  
  605.      Code 0 -- 110 bps            Code 10 -- 50 bps
  606.      Code 1 -- 134.5 bps          Code 11 -- 75 bps in, 1200 out
  607.      Code 2 -- 300 bps            Code 12 -- 2400 bps
  608.      Code 3 -- 1200 bps           Code 13 -- 4800 bps
  609.      Code 4 -- 600 bps            Code 14 -- 9600 bps
  610.      Code 5 -- 75 bps             Code 15 -- 19200 bps
  611.      Code 6 -- 150 bps            Code 16 -- 48000 bps
  612.      Code 7 -- 1800 bps           Code 17 -- 56000 bps
  613.      Code 8 -- 200 bps            Code 18 -- 64000 bps
  614.      Code 9 -- 100 bps
  615.  
  616.  
  617.  
  618. Levy & Jacobson                                                [Page 11]
  619.  
  620. RFC 1053                 Telnet X.3 PAD Option                April 1988
  621.  
  622.  
  623. Parameter 12 -- Flow control of host-to-user data.
  624.  
  625.      When this parameter is 1, the user may type X-OFF (DC3, ASCII code
  626.      19) to suspend printing output, and X-ON (DC1, ASCII code 17) to
  627.      resume output.
  628.  
  629.      Code 0 -- X-OFF and X-ON are sent as data to host.
  630.      Code 1 -- X-OFF and X-ON control output.
  631.  
  632.      See also the extension parameters 130, 131 and 132.
  633.  
  634. Parameter 13 -- Line feed insertion; Telnet CR LF vs CR NUL.
  635.  
  636.      The CCITT uses this parameter to select whether a typed CR should
  637.      be sent as CR or CR-LF, whether an output CR should have a LF
  638.      printed after it, and whether an echoed CR should be echoed with an
  639.      accompanying LF.
  640.  
  641.      Here, it resolves the questions of mapping between the Telnet CR-LF
  642.      sequence and single ASCII codes (i.e., when the user presses the
  643.      carriage return key, should CR LF or CR NUL be sent to the host?
  644.      When the host sends CR LF, should the user see CR LF or merely CR?)
  645.  
  646.      The value is bit-encoded; codes may be added to select multiple
  647.      functions.
  648.  
  649.      Code 0 -- No line feed insertion
  650.                (typed CR sent as CR NUL; host CR LF printed as CR).
  651.      Code 1 -- Add line feed on output (host CR LF printed as CR LF).
  652.      Code 2 -- Add line feed on input (typed CR sent as CR LF to host).
  653.      Code 4 -- When echoing a typed CR locally, echo as CR LF.
  654.  
  655.      Note the interaction with the TRANSMIT-BINARY Telnet option [5].
  656.      If the host has said WILL TRANSMIT-BINARY, then CR has no special
  657.      meaning on output; it always stands for the single character CR
  658.      regardless of this parameter's value.  If the user telnet has said
  659.      WILL TRANSMIT-BINARY, a typed CR should likewise always be sent as
  660.      itself and not as CR LF or CR NUL.
  661.  
  662. Parameter 14 -- Output padding after line feed.
  663.  
  664.      Gives the number of ASCII NUL padding characters to be sent to the
  665.      user's terminal after each output line feed.
  666.  
  667.      Codes 0 through 7 -- Send that many padding characters.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Levy & Jacobson                                                [Page 12]
  675.  
  676. RFC 1053                 Telnet X.3 PAD Option                April 1988
  677.  
  678.  
  679. Parameter 15 -- Local editing.
  680.  
  681.      If this parameter is 1, the character delete, line delete and line
  682.      reprint functions (parameters 16, 17 and 18), if implemented,
  683.      should be enabled.  Data should be sent to the host when a
  684.      forwarding character (see parameter 3) is typed or in case the user
  685.      telnet's input buffer becomes full.
  686.  
  687.      Note the interaction with parameter 4, Forward after idle time.
  688.      User telnets need not handle the case where idle-time forwarding
  689.      and local editing are both enabled, i.e., the host should
  690.      explicitly request changing parameter 4 to 0 along with setting
  691.      parameter 15 to 1.
  692.  
  693.      Code 0 -- No input editing.  Any editing characters are considered
  694.                data.
  695.      Code 1 -- Input editing.  Editing characters edit the input buffer.
  696.  
  697. Parameter 16 -- Character-delete character.
  698.  
  699.      While local editing (parameter 15) is enabled, typing this
  700.      character erases the last character in the editing buffer, if any.
  701.      When editing is disabled, this character is not treated specially.
  702.  
  703.      Code 0 -- No character has this function.
  704.      Codes 1 through 127 -- ASCII code of character-delete character.
  705.  
  706.      See also parameter 19.
  707.  
  708. Parameter 17 -- Line-delete character.
  709.  
  710.      While local editing (parameter 15) is enabled, this character
  711.      erases the entire contents of the editing buffer.  When editing is
  712.      disabled, this character is not treated specially.
  713.  
  714.      Code 0 -- No character has this function.
  715.      Codes 1 through 127 -- ASCII code of line-delete character.
  716.  
  717.      See also parameter 19.
  718.  
  719. Parameter 18 -- Line-display character.
  720.  
  721.      While local editing (parameter 15) is enabled, typing this
  722.      character causes the current contents of the editing buffer to be
  723.      printed on the user's terminal; nothing is sent to the host.  When
  724.      editing is disabled, this character is not treated specially.
  725.  
  726.      Code 0 -- No character has this function.
  727.  
  728.  
  729.  
  730. Levy & Jacobson                                                [Page 13]
  731.  
  732. RFC 1053                 Telnet X.3 PAD Option                April 1988
  733.  
  734.  
  735.      Codes 1 through 127 -- ASCII code of line-display character.
  736.  
  737. Parameter 19 -- Editing service signals.
  738.  
  739.      This determines what is echoed to the user when local editing is
  740.      enabled and the character-delete or line-delete character is
  741.      entered.
  742.  
  743.      Code 0 -- Nothing is echoed.
  744.      Code 1 -- Editing style is suitable for printing terminals.
  745.      Code 2 -- Editing style is suitable for display terminals.
  746.      Codes 8 and 32-126 -- Echo that ASCII character for
  747.                character-delete.
  748.  
  749.      X.3 is specific on handling character- and line-deletion.  If
  750.      parameter 19 is 1, echo character-delete with a "line delete with
  751.      three X's followed by CR LF.  If 2, a character-delete echoes BS
  752.      SPACE BS, while a line delete echoes enough BS SPACE BS's to erase
  753.      the entire line.  If 8 or 32-126, character-delete echoes that
  754.      character, and line delete echoes XXX CR LF.  An extension
  755.      parameter could override these, selecting other styles if desired,
  756.      though none is proposed here.
  757.  
  758. Parameter 20 -- Echo mask.
  759.  
  760.      When local echoing, parameter 2, is enabled, each nonzero bit in
  761.      this bit-encoded parameter's value suppresses echoing of some
  762.      subset of ASCII characters.  Adding values suppresses echo for the
  763.      union of the specified subsets.
  764.  
  765.      Code 0   --  all ASCII characters are echoed.
  766.      Code 1   --  CR is not echoed.
  767.      Code 2   --  LF is not echoed.
  768.      Code 4   --  VT, HT, and FF are not echoed.
  769.      Code 8   --  BEL and BS are not echoed.
  770.      Code 16  --  ESC and ENQ are not echoed.
  771.      Code 32  --  ACK, NAK, STX, SOH, EOT, ETB and ETX are not echoed.
  772.      Code 64  --  Editing characters are not echoed.
  773.      Code 128 --  other non-printing ASCII characters, and DEL, not
  774.                   echoed.
  775.  
  776.      Nothing is echoed when parameter 2 is 0.  Some characters should
  777.      not be echoed regardless of parameter 20.  If any of parameters 5,
  778.      12, or 22 are enabled (non-zero), then the XON and XOFF characters
  779.      should not be echoed.  Nor should the escape-to-local command mode
  780.      character, parameter 1.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Levy & Jacobson                                                [Page 14]
  787.  
  788. RFC 1053                 Telnet X.3 PAD Option                April 1988
  789.  
  790.  
  791. Parameter 21 -- Parity.
  792.  
  793.      This parameter determines whether parity is checked on user input
  794.      and generated on output to the user.  Values may be added to select
  795.      both.
  796.  
  797.      Code 0 -- Parity neither generated nor checked.
  798.      Code 1 -- Even parity checked on input.
  799.      Code 2 -- Even parity generated on output.
  800.  
  801. Parameter 22 -- Page wait.
  802.  
  803.      If enabled, this parameter causes the user telnet to pause after
  804.      every N lines of output as if X-OFF had been received.  Output
  805.      resumes when X-ON is typed.
  806.  
  807.      Code 0 -- No pause.
  808.      Codes 1-255 -- Pause after output of that many line feeds.
  809.  
  810.      See also parameters 130, 131 and 132.
  811.  
  812. The following parameters are not part of CCITT X.3, but use the
  813. extension mechanism proposed for this Telnet option.
  814.  
  815. Parameter 128 -- Extension set number.
  816.  
  817.      This parameter selects one of a potentially large number of
  818.      "extension sets" -- more or less coherent collections of parameters
  819.      added to the basic X.3 family.  User telnets may support several
  820.      extension sets.  The host may determine whether a particular one is
  821.      supported by trying to set parameter 128.  The user telnet should
  822.      accept the value if it provides some or all of the parameters in
  823.      that set.
  824.  
  825.      Extension sets might be defined for a variety of purposes.  For
  826.      example, Berkeley UNIX tty emulation, VMS emulation, Telenet's
  827.      extended parameters, French national PDN parameters, and so on.
  828.  
  829.      Initial values need not be specified for extension parameters
  830.      (i.e., a host should explicitly negotiate for their values after
  831.      selecting an extension set).  However, it is recommended that
  832.      default settings give service that resembles normal CCITT X.3
  833.      behavior where possible.
  834.  
  835.      Extension sets are mutually exclusive.  Different sets may use the
  836.      same parameters (from 129 through 255) for different purposes.
  837.  
  838.      Only one extension set is in effect at a time.  That is, if a host
  839.  
  840.  
  841.  
  842. Levy & Jacobson                                                [Page 15]
  843.  
  844. RFC 1053                 Telnet X.3 PAD Option                April 1988
  845.  
  846.  
  847.      requests service X from extension set A, then switches to extension
  848.      set B and requests its service Y, it should not expect that service
  849.      X is still being provided.
  850.  
  851.      Some values of this parameter are reserved:
  852.  
  853.      Code 0 -- Null extension set.  Only (a subset of) the basic CCITT
  854.                  X.3 parameters is provided.  Every user telnet should
  855.                  accept this setting.
  856.      Code 1 -- (A subset of) the extension set 1 parameters described
  857.                  below is provided.
  858.      Code 255 -- Reserved for purely local (e.g., to a site), non-
  859.                  standard collections of extensions.
  860.  
  861.      Other extension sets may be proposed and assigned set numbers in
  862.      the range 2 through 254.
  863.  
  864.           Set number are registered with the Internet Assigned Numbers
  865.           Coordinator at USC-ISI.  Please contact:
  866.  
  867.                Joyce K. Reynolds
  868.                USC Information Sciences Institute
  869.                Suite 1001
  870.                4676 Admiralty Way
  871.                Marina del Rey, CA  90292-6695
  872.  
  873.                213-822-1511   JKReynolds@ISI.EDU
  874.  
  875. The following parameters form extension set number 1.
  876.  
  877. Parameter 129, extension set 1 -- Word-delete character.
  878.  
  879.      Typing this character while local editing is enabled causes the
  880.      last word in the editing buffer to be erased.  Several definitions
  881.      for a "word" are in common use; this RFC does not specify one.
  882.      There should be an indication to the user of what was erased.  When
  883.      editing is disabled, this character is not treated specially.
  884.  
  885.      Code 0 -- No character has this function.
  886.      Codes 1 through 127 -- ASCII code of word-delete character.
  887.  
  888. Parameter 130, extension set 1 -- Flow control OFF character.
  889.  
  890.      Parameter 131, extension set 1 -- Flow control ON character.
  891.      Typing these characters while parameter 12 is enabled cause output
  892.      to be suspended or resumed, respectively.  The user telnet may send
  893.      them to the user while parameter 5 is enabled to ask the user to
  894.      cease or resume supplying input.
  895.  
  896.  
  897.  
  898. Levy & Jacobson                                                [Page 16]
  899.  
  900. RFC 1053                 Telnet X.3 PAD Option                April 1988
  901.  
  902.  
  903.      If defined, these parameters should have default values of 19
  904.      (ASCII DC3) for parameter 130, and 17 (ASCII DC1) for parameter
  905.      131.
  906.  
  907.      Code 0 -- No character has this function.
  908.      Codes 1 through 127 -- Function performed by that ASCII code.
  909.  
  910. Parameter 132, extension set 1 -- Host-to-user flow control convention.
  911.  
  912.      Some styles of flow control accept only a particular character
  913.      (e.g., X-ON) to resume output; others resume on receipt of any
  914.      character.  This parameter selects which to use.  The default
  915.      should be zero, as this matches the X.3 convention.
  916.  
  917.      Code 0 -- Resume output only when correct character is received.
  918.      Code 1 -- Resume output when any character is received.
  919.  
  920. Parameter 133, extension set 1 -- Alternate Attention, etc., character.
  921.  
  922.      This character serves as a synonym for the Break, Attention, etc.,
  923.      key whose function is given by parameter 7.
  924.  
  925.      Code 0 -- No ASCII character has this function
  926.                (there may still be a special key or other mechanism).
  927.      Codes 1 through 127 -- ASCII code of the character.
  928.  
  929. Parameter 134, extension set 1 -- Local echo style.
  930.  
  931.      This parameter selects how non-printing characters should be
  932.      echoed, when parameter 2 is set to 1.  The default should be zero,
  933.      where all characters are simply echoed as themselves (except
  934.      possibly carriage return; see parameter 13).
  935.  
  936.      Code 0 -- All characters echo as themselves.
  937.      Code 1 -- Non-editing control characters echo as ^X for some
  938.                printable character X.
  939.  
  940.      See also parameters 2, Local echo, and 20, Echo mask, which may
  941.      suppress echo of some or all characters regardless of this
  942.      parameter.
  943.  
  944. Parameter 135, extension set 1 -- Accept following character as data.
  945.  
  946.      After typing this character, the next character entered is accepted
  947.      as data for transmission to the host even if it would normally have
  948.      a special meaning.
  949.  
  950.      The default should be zero.
  951.  
  952.  
  953.  
  954. Levy & Jacobson                                                [Page 17]
  955.  
  956. RFC 1053                 Telnet X.3 PAD Option                April 1988
  957.  
  958.  
  959.      Code 0 -- No character has this function.
  960.      Codes 1 through 127 -- ASCII code of the character.
  961.  
  962. Parameter 136, extension set 1 -- Character to toggle discarding output.
  963.  
  964.      Typing this character changes the state of parameter 8 (discarding
  965.      host-to-user output) from 0 to 1 or from 1 to 0.  Thus an
  966.      indeterminate amount of host output, received between successive
  967.      instances of this character, will be discarded.
  968.  
  969.      As usual, the host should be notified of each change if parameter 0
  970.      is set to 1.  The host might wish to send SET messages at
  971.      appropriate points (e.g., preceding command prompts) to re-enable
  972.      output.
  973.  
  974.      The default should be zero.
  975.  
  976.      Code 0 -- No character performs this function (though another
  977.      mechanism still may do so).
  978.  
  979.      Codes 1 through 127 -- Typing that character toggles parameter 8.
  980.  
  981. Parameter 137, extension set 1 -- User-to-host bits per character.
  982.  
  983. Parameter 138, extension set 1 -- Host-to-user bits per character.
  984.  
  985.      These parameters determine whether, for example, a full 8-bit input
  986.      or output data path is available, or whether the most significant
  987.      bit(s) of input or output data is stripped.  Typical values would
  988.      be 7 or 8.
  989.  
  990.      Note that an 8-bit data path does not by itself imply transparent
  991.      input/output; CR -> CR LF translation, XON/XOFF interpretation,
  992.      parity and so on must also be disabled to achieve this.
  993.  
  994. 7.  Subsets, Extensions and Conflicts
  995.  
  996.    An option as complex (and easy to extend) as this one, needs a policy
  997.    for what subsets and extensions are allowed, and recommendations for
  998.    negotiating one's way through a maze of partial implementations.  In
  999.    short, what does it mean to say DO or WILL X.3-PAD?
  1000.  
  1001.    A basic principle is that, since hardly any user telnet
  1002.    implementation will provide all possible features, a host cannot
  1003.    expect to get precisely any desired kind of service.
  1004.  
  1005.     [This may be an arguable point.  The CCITT defines a mandatory
  1006.     subset of supported values for each X.3 parameter, with further
  1007.  
  1008.  
  1009.  
  1010. Levy & Jacobson                                                [Page 18]
  1011.  
  1012. RFC 1053                 Telnet X.3 PAD Option                April 1988
  1013.  
  1014.  
  1015.     values optional.  For example, the set of forwarding characters,
  1016.     parameter 4, must accept at least the values 0 (none), 2 (carriage
  1017.     return), and 126 (any control character or DEL).  Though it would be
  1018.     possible to adopt the CCITT's set of mandatory values there, I don't
  1019.     think that would be desirable for two reasons.
  1020.  
  1021.     First, some of the features specified (e.g., timed input) may be
  1022.     hard to implement in some environments, and may well not be
  1023.     necessary for many applications.
  1024.  
  1025.     Second, this option provides for definition of entirely new
  1026.     parameters.  Unlike the X.3 case, one peer may use parameters whose
  1027.     very existence is unknown to the other.  So one cannot specify
  1028.     mandatory or default values for ALL parameters.]
  1029.  
  1030.    On the other hand, a host is at least entitled to know what kind of
  1031.    service is being provided to the ultimate user.  A user telnet's
  1032.    status report may be incomplete (not describing features its
  1033.    implementor did not know of); it may not describe the style of
  1034.    interaction the host (or user, or application) would wish for, but it
  1035.    should at least describe reality.
  1036.  
  1037.    For telnet parameters with a range of possible values, if a user
  1038.    telnet implements only one "enabled" and one "disabled" value, it
  1039.    should choose the "enabled" value when asked for a setting it cannot
  1040.    supply.  A VMS telnet, for example, might allow only DEL or nothing
  1041.    as the character-delete code.  If a host asks it to use "backspace",
  1042.    it should choose DEL rather than nothing. The host may then interpret
  1043.    this contrary behavior as indicating a preferred value.
  1044.  
  1045.    The problem of conflicting parameters, where several parameters
  1046.    control overlapping services and may conflict, is a serious one. The
  1047.    extension set scheme (see parameter 128) is intended to limit the
  1048.    problem.  Each extension set's parameters should be selfconsistent
  1049.    and consistent with the CCITT X.3 parameters, but separate extension
  1050.    sets need not be concerned with each other's parameters.
  1051.  
  1052.    Where parameters might conflict, it is important to specify priority
  1053.    as part of the parameters' description.  For example, among
  1054.    parameters 2 (Local echo), 20 (Echo mask), and extension set 1's 134
  1055.    (Local echo style), Echo mask is significant only if Local echo is
  1056.    enabled, and Local echo style applies only to characters selected for
  1057.    echoing by the first two parameters.
  1058.  
  1059.    This option's functions overlap with those of some existing Telnet
  1060.    options, for example, ECHO (which can be interpreted to affect local
  1061.    echo and possibly local line editing), NAOCRD and NAOLFD [6]
  1062.    (specifying padding after output carriage returns and line feeds),
  1063.  
  1064.  
  1065.  
  1066. Levy & Jacobson                                                [Page 19]
  1067.  
  1068. RFC 1053                 Telnet X.3 PAD Option                April 1988
  1069.  
  1070.  
  1071.    TRANSMIT-BINARY, Remote Controlled Transmission and Echo [3], and
  1072.    SUPDUP [4].
  1073.  
  1074.    Where X.3-PAD completely subsumes the function of another option, as
  1075.    for ECHO, NAOCRD and NAOLFD, it's probably best to let the X.3-PAD
  1076.    option, where acceptable to both sides, supplant them and to refuse
  1077.    the other option.
  1078.  
  1079.    The TRANSMIT-BINARY option can change (actually suppress) the
  1080.    interpretation of some bits of parameter 13 related to Telnet newline
  1081.    encoding, as mentioned under that parameter.  As such it is
  1082.    compatible with this option but must be kept in mind.
  1083.  
  1084.    RCTE would be a much more difficult case, since its service does not
  1085.    fit into this option's scheme and vice versa.  However, it probably
  1086.    is unimportant because of the scarcity of RCTE implementations.
  1087.  
  1088.    Some existing Telnet options can serve related but complementary
  1089.    functions, for example NAOHTS [7] for output tab handling, or
  1090.    TERMINAL-TYPE [8].
  1091.  
  1092. 8.  Implementation suggestions
  1093.  
  1094.      It is strongly recommended that a user telnet support at least the
  1095.      combination with parameters 2=0, 3=126, and 4=1 (no local echo,
  1096.      forward immediately or nearly so on any input character) so that a
  1097.      dissatisfied host has the option of backing off and doing its own
  1098.      character handling.
  1099.  
  1100.      The "discard output" function invoked by the Break, Interrupt,
  1101.      Attention, etc., key if the 16's bit is set in parameter 7 may be
  1102.      implemented as follows.
  1103.  
  1104.            1.  When the key is pressed, set parameter 8 to 1, begin
  1105.                discarding output, send IAC SB X.3-PAD IS  8 1  IAC SE to
  1106.                notify the host.  (It may not need to know, but the
  1107.                message should be sent for consistency.)
  1108.  
  1109.            2.  Send IAC DO TIMING-MARK.
  1110.  
  1111.            3.  Send any other messages associated with the key (e.g.,
  1112.                IAC IP).
  1113.  
  1114.            4.  Eventually, the host should send either IAC WILL
  1115.                TIMING-MARK or IAC WON'T TIMING-MARK, even if it knows
  1116.                nothing about the TIMING-MARK option.  It will probably
  1117.                appear close, in the output stream, to the point where
  1118.                the host recognized any associated messages (e.g., IP).
  1119.  
  1120.  
  1121.  
  1122. Levy & Jacobson                                                [Page 20]
  1123.  
  1124. RFC 1053                 Telnet X.3 PAD Option                April 1988
  1125.  
  1126.  
  1127.                When the TIMING-MARK arrives, reset parameter 8 to 0 and
  1128.                cease discarding output.  Send IAC SB X.3-PAD IS  8 0
  1129.                IAC SE.
  1130.  
  1131.    The Telnet SYNCH mechanism (see [2]) may be employed in concert with
  1132.    such a scheme.  A closed-loop flush, though, will be more effective
  1133.    at discarding excess output than SYNCH used alone.  Provision of some
  1134.    such mechanism for discarding unwanted output, e.g., after
  1135.    interrupting the host, is heartily recommended.
  1136.  
  1137.    Discarding input is less clear cut.  Certainly, any buffered data not
  1138.    yet sent should be discarded; one might also use SYNCH to encourage
  1139.    the host telnet to discard more.
  1140.  
  1141. 9.  References
  1142.  
  1143.      1.  Recommendation X.3, from International Telecommunications Union
  1144.          CCITT Red Book, volume VIII, fascicle VIII.2, 1984.
  1145.  
  1146.      2.  Postel, J., and J. Reynolds, "Telnet Protocol Specification",
  1147.          RFC-854, USC Information Sciences Institute, May 1983.
  1148.  
  1149.      3.  Postel, J., and D. Crocker, "Remote Controlled Transmission and
  1150.          Echoing Telnet Option", RFC-726 and NIC-39237, SRI-ARC, March
  1151.          1977.
  1152.  
  1153.      4.  Crispin, M., "SUPDUP Protocol", RFC-734 and NIC-41953, SU-AI
  1154.          October 1977; Crispin, M., "Telnet SUPDUP Option", RFC-736 and
  1155.          NIC-42213, SU-AI, October 1977; also Greenberg, B., "Telnet
  1156.          SUPDUP-OUTPUT Option", RFC-749 and NIC-45499, MIT-Multics,
  1157.          September 1978.
  1158.  
  1159.      5.  Postel, J., and J. Reynolds, "Telnet Binary Transmission
  1160.          Option", RFC-856, USC Information Sciences Institute, May 1983.
  1161.  
  1162.      6.  Crocker, D., "Telnet Output Linefeed Disposition Option", RFC-
  1163.          658 and NIC-31161, UCLA-NMC, October 1974; and "Telnet Output
  1164.          Carriage Return Disposition Option", RFC-652 and NIC-31155,
  1165.          UCLA-NMC, October 1974.
  1166.  
  1167.      7.  Crocker, D., "Telnet Output Horizontal Tab Stops Option", RFC-
  1168.          653 and NIC-31156, UCLA-NMC, October 1974.  [RFC numbers 652
  1169.          through 658 (NIC 31155 through 31161) are in a similar vein.]
  1170.  
  1171.      8.  Solomon, M., and E. Wimmers, "Telnet Terminal Type Option",
  1172.          RFC-884, University of Wisconsin - Madison, December 1983.
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Levy & Jacobson                                                [Page 21]
  1179.