home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-bennett-00.txt < prev    next >
Text File  |  1997-08-20  |  12KB  |  338 lines
  1.  
  2. INTERNET-DRAFT          Expires: AUGUST 1997          INTERNET-DRAFT
  3.  
  4. Network Working Group                                 M. Bennett
  5. INTERNET-DRAFT                             Stallion Technologies
  6.                                                    December 1996
  7.  
  8.                       Telnet Remote Serial Port (RSP) Option
  9.                       <draft-rfced-info-bennett-00.txt>
  10.  
  11. Status of This Memo
  12.    
  13.    This document is an Internet-Draft.  Internet-Drafts are working
  14.    documents of the Internet Engineering task Force (IETF), its areas,
  15.    and its working groups.  Note that other groups may also distribute
  16.    working documents as Internet-Drafts.
  17.  
  18.    Internet-Drafts are draft documents valid for a maximum of six
  19.    months and may be updated, replaced, or obsoleted by other
  20.    documents at any time.  It is inappropriate to use Internet-Drafts
  21.    as reference material or to cite them other than as "work in
  22.    progress".
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  26.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  28.    ftp.isi.edu (US West Coast).
  29.  
  30.  
  31. Abstract
  32.    
  33.    This document is a submission to the Internet Engineering Task Force
  34.    (IETF) as an Internet draft standard.
  35.  
  36.    Distribution of this memo is unlimited.
  37.  
  38. 1. Command Name and Code
  39.  
  40.       RSP   XX
  41.  
  42. 2. Command Meanings
  43.  
  44.       IAC WILL RSP
  45.  
  46.          Sender is willing to send RSP information in a
  47.          subsequent sub-negotiation.
  48.  
  49.       IAC WON'T RSP
  50.  
  51.          Sender refuses to send RSP information.
  52.  
  53.       IAC DO RSP
  54.  
  55.          Sender is willing to receive RSP information in a
  56.          subsequent sub-negotiation.
  57.  
  58.       IAC DON'T RSP
  59.  
  60.          Sender refuses to accept RSP information.
  61.  
  62.  
  63.       IAC SB RSP SEND IAC SE
  64.       IAC SB RSP SEND item1 item2 ... IAC SE
  65.  
  66.          Client requests server to transmit the current state of
  67.          the given item(s). The code for SEND is 1.
  68.          If no items are given, the server is requested to return all
  69.          known items.
  70.          (See below for valid 'item's)
  71.  
  72.       IAC SB RSP IS item1 value1 item2 value2 ... IAC SE
  73.  
  74.          Server states the current value of the given items.
  75.          May be in response to SEND, or may be due to a change in the
  76.          value of the items. The code for IS is 0.
  77.          (See below for valid 'item's)
  78.  
  79.       IAC SB RSP SET item1 value1 item2 value2 IAC SE
  80.  
  81.          Client requests that the server sets the value of 'item1' to
  82.          'value1' etc.  The code for SET is 2.
  83.          (See below for valid 'item's)
  84.  
  85. 2.2 Valid RSP items
  86.  
  87.       MSR  0
  88.  
  89.         8250-compatible modem status register
  90.         Value is 32 bit value in network byte order, with msr in the least
  91.         significant 8 bits.
  92.  
  93.       BAUD-RATE 1
  94.  
  95.         Baud rate
  96.         Value is 32 bit number in network byte order, greater than 0.
  97.  
  98.       STOP-BITS 2
  99.  
  100.         Stop bits
  101.         Value is 32 bit number in network byte order, where 0 represents 1 1/2.
  102.  
  103.       DATA-BITS 3
  104.  
  105.         Data bits in a character
  106.         Value is 32 bit number in network byte order.
  107.  
  108.       PARITY 4
  109.  
  110.         Parity of characters
  111.         Value is 32 bit number in network byte order with one of the
  112.         following values.
  113.         NONE  0
  114.         ODD   1
  115.         EVEN  2
  116.         MARK  3
  117.         SPACE 4
  118.  
  119.       DTR 5
  120.  
  121.         State of DTR
  122.         Value is a 32 bit number in network byte order with one of the
  123.         following values.
  124.         OFF 0
  125.         ON  1
  126.  
  127.       RTS 6
  128.  
  129.         State of RTS
  130.         Value is a 32 bit number in network byte order with one of the
  131.         following values.
  132.         OFF 0
  133.         ON  1
  134.  
  135.       TXBUFFER 7
  136.  
  137.         Characters in the the transmit buffer
  138.         Value is a 32 bit number in network byte order with one of the
  139.         following values.
  140.         EMPTY       0
  141.         NOT-EMPTY   non-zero
  142.  
  143.       FLOW-CONTROL 8
  144.  
  145.         Input and output flow control setting.
  146.         Value is a 32 bit number in network byte order which represents a bit mask.
  147.         The bitmask may contain any combination of the following values.
  148.  
  149.         RTSFLOW     1      (Input flow control - drop RTS to stop receiving)
  150.         CTSFLOW     2      (Output flow control - stop transmitting when CTS drops)
  151.         IXON        4      (Output flow control - start/stop sending on XON/XOFF)
  152.         IXOFF       8      (Input flow control - send XON/XOFF to start/stop receiving)
  153.         DCDFLOW    16      (Output flow control - stop transmitting when DCD drops)
  154.         DTRFLOW    32      (Input flow control - drop DTR to stop receiving)
  155.         DSRFLOW    64      (Output flow control - stop transmitting when DSR drops)
  156.  
  157.       SEND-CHANGED 32
  158.  
  159.         Specifies which items, if any, for which the server should send values
  160.         when the value of the item changes.
  161.         Value is a 32 bit number in network byte order which represents
  162.         a bit mask. If a bit is 1, then the server should send values
  163.         for that item, and it if is a 0, it should send values only upon
  164.         request.  For example, if 0x00000001 is set as a value for
  165.         SEND-CHANGED, then the server should send the value for MSR
  166.         whenever that value changes.
  167.  
  168.       PURGE        33
  169.  
  170.         Purges receive and/or transmit queues.
  171.         Value is a 32 bit number in network byte order with one of the
  172.         following values.
  173.         RX-QUEUE    1
  174.         TX-QUEUE    2
  175.         RXTX-QUEUE  3      (Purge both the RX and TX queues)
  176.  
  177. 3. Default
  178.  
  179.       WON'T RSP
  180.       DON'T RSP
  181.  
  182.          RSP information will not be exchanged.
  183.  
  184.       SEND-CHANGED 0
  185.  
  186.          Server only sends updated information as requested.
  187.  
  188. 4. Motivation for the Option
  189.  
  190.    Many (if not all) terminal servers support the ability to set up a
  191.    telnet listener on a serial port. This allows a connection to a port
  192.    to be made via the network, however only (two way) data can be
  193.    transferred between the client and the port.
  194.  
  195.    By using the Remote Serial Port (RSP) telnet option, the client is
  196.    able to control non-data aspects of the port such as baud rate and
  197.    modem signals.  This is especially important where the port is
  198.    attached to a modem and modem signals are required to hangup the
  199.    modem.
  200.  
  201.    This document defines a simple protocol which allows terminal servers
  202.    (and other systems which provide access to serial ports via a network
  203.    connection) to provide access to these features.
  204.  
  205. 5. Description of the Option
  206.  
  207.    Willingness to exchange RSP information is agreed upon via
  208.    conventional Telnet option negotiation.  WILL and DO are used only to
  209.    obtain and grant permission for future discussion.  The actual
  210.    exchange of status information occurs within option subcommands (IAC
  211.    SB RSP...).
  212.  
  213.    Once the two hosts have exchanged a WILL and a DO, the sender of the
  214.    DO RSP (the client) is free to request and set RSP information.  A
  215.    successful DO RSP is required before SEND and SET requests can be
  216.    used by the client and IS responses can be sent by the server. The
  217.    negotiation indicates acceptance in one direction only. (It would
  218.    generally not be appropriate to negotiate the RSP option in both
  219.    directions).
  220.  
  221.    All RSP items are 1 octet in length and all RSP values are 32 bit values
  222.    in network byte order. This allows multiple items or multiple {item, value}
  223.    pairs to be specified in a single request or response without requiring that
  224.    all items be understood by the recipient.
  225.  
  226. 6.  Implementation Issues
  227.  
  228.    This specification allows for various items to be set or requested by
  229.    a client. Support for all items is optional. Also it may be
  230.    inappropriate to set or send a given item at any time.  Thus, a server
  231.    responds to requests as follows.
  232.  
  233.    When a server receives a SET request, it should immediately make the
  234.    change for each item in the list. If any item is not supported, not
  235.    understood or not appropriate (doesn't make sense or the value is
  236.    inappropriate), that item is ignored.  All items in a request are
  237.    independent. That is, if one item fails, then the remaining items in
  238.    the request should continue to be processed.
  239.  
  240.    Similarly, when a server receives a SEND request, it should respond
  241.    with a IS request for each item in the SEND request which is
  242.    understood and makes sense. Other items are ignored.
  243.  
  244.    No response is sent by the server as a result of a SET request.  It
  245.    is the responsibility of the client to issue a SEND request if it
  246.    wishes to determine whether a SET request has succeeded.
  247.  
  248.    SEND-CHANGED is an item like any other including the fact that
  249.    support for it is optional. If it is supported, an IS request is sent
  250.    by the server to the client whenever the value for an item changes
  251.    value spontaneously (that is, other than in response to a SET
  252.    request) for which a 1 bit is set in the SEND-CHANGED value.
  253.  
  254.    Note: No requirements are placed on the server in determining how
  255.          soon after the change occurs that the IS request should be
  256.          sent. This allows a server to combine multiple changes into a
  257.          single request if multiple changes occur within a short time of
  258.          one another. Also, a server may choose to delay sending of an
  259.          IS request if the value of an item changes very quickly to
  260.          avoid flooding the connection.  Every change of an item need
  261.          not be (and should not be) sent in these circumstances.
  262.          Rather, only the "last" change should be sent.
  263.  
  264.    Note: Only changes to the first 32 RSP items are supported by
  265.          SEND-CHANGED.  This should be sufficient for all realistic
  266.          implementations of remote serial ports.
  267.  
  268. 7. Examples
  269.  
  270.    Note: In these examples, the C notation, 0x, is used to denote
  271.          a hexadecimal number.
  272.  
  273.    In this example, the client gets the current values for all items
  274.    known by the server.
  275.  
  276.       Client: IAC DO RSP
  277.  
  278.       Server: IAC WILL RSP
  279.  
  280.          (Client may now request or set RSP information at any time.
  281.           Server is SEND-CHANGED 0)
  282.  
  283.       Client: IAC SB RSP SEND IAC SE
  284.  
  285.       Server: IAC SB RSP IS SEND-CHANGED 0 MSR 0x00 DTR ON BAUD-RATE
  286.               9600 IAC SE
  287.  
  288.    In this example, the client turns on SEND-CHANGED and checks to see
  289.    if it is supported by the server. The server sends change
  290.    notifications.
  291.  
  292.       Client: IAC DO RSP
  293.  
  294.       Server: IAC WILL RSP
  295.  
  296.       Client: IAC SB RSP SET SEND-CHANGED 0x0000000F IAC SE
  297.  
  298.       Client: IAC SB RSP SEND SEND-CHANGED IAC SE
  299.  
  300.       Server: IAC SB RSP IS SEND-CHANGED 0x0000000F IAC SE
  301.  
  302.       Server: IAC SB RSP IS MSR 0x33 IAC SE
  303.  
  304.       Server: IAC SB RSP IS MSR 0x03 BAUD-RATE 38400 IAC SE
  305.  
  306.  
  307. 9. References:
  308.  
  309.      [1]  Postel, J., and J. Reynolds, "Telnet Protocol Specification",
  310.           RFC 854, USC Information Sciences Institute, May 1983.
  311.  
  312.      [2]  Postel, J., and J. Reynolds, "Telnet Option Specification",
  313.           RFC 855, USC Information Sciences Institute, May 1983.
  314.  
  315.      [3]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700,
  316.           USC Information Sciences Institute, October 1994.
  317.  
  318.  
  319. Author's Address
  320.  
  321.    Murray Bennett
  322.    Stallion Technologies
  323.    33 Woodstock Rd
  324.    Toowong QLD 4066
  325.    Australia
  326.  
  327.    Phone:  +61 7 3270 4277
  328.  
  329.    Email: murray@stallion.oz.au
  330.  
  331.  
  332. Murray Bennett                    Stallion Technologies
  333. Phone:  +61 7 3270 4277           33 Woodstock Rd
  334. Fax:    +61 7 3270 4245           Toowong QLD 4066
  335. Email:  murray@stallion.oz.au     Australia
  336.  
  337. INTERNET-DRAFT           EXPIRES: AUGUST 1997          INTERNET-DRAFT
  338.