[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT          Expires: AUGUST 1997          INTERNET-DRAFT

Network Working Group                                 M. Bennett
INTERNET-DRAFT                             Stallion Technologies
                                                   December 1996

                      Telnet Remote Serial Port (RSP) Option
                      <draft-rfced-info-bennett-00.txt>

Status of This Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   This document is a submission to the Internet Engineering Task Force
   (IETF) as an Internet draft standard.

   Distribution of this memo is unlimited.

1. Command Name and Code

      RSP   XX

2. Command Meanings

      IAC WILL RSP

         Sender is willing to send RSP information in a
         subsequent sub-negotiation.

      IAC WON'T RSP

         Sender refuses to send RSP information.

      IAC DO RSP

         Sender is willing to receive RSP information in a
         subsequent sub-negotiation.

      IAC DON'T RSP

         Sender refuses to accept RSP information.


      IAC SB RSP SEND IAC SE
      IAC SB RSP SEND item1 item2 ... IAC SE

         Client requests server to transmit the current state of
         the given item(s). The code for SEND is 1.
         If no items are given, the server is requested to return all
         known items.
         (See below for valid 'item's)

      IAC SB RSP IS item1 value1 item2 value2 ... IAC SE

         Server states the current value of the given items.
         May be in response to SEND, or may be due to a change in the
         value of the items. The code for IS is 0.
         (See below for valid 'item's)

      IAC SB RSP SET item1 value1 item2 value2 IAC SE

         Client requests that the server sets the value of 'item1' to
         'value1' etc.  The code for SET is 2.
         (See below for valid 'item's)

2.2 Valid RSP items

      MSR  0

        8250-compatible modem status register
        Value is 32 bit value in network byte order, with msr in the least
        significant 8 bits.

      BAUD-RATE 1

        Baud rate
        Value is 32 bit number in network byte order, greater than 0.

      STOP-BITS 2

        Stop bits
        Value is 32 bit number in network byte order, where 0 represents 1 1/2.

      DATA-BITS 3

        Data bits in a character
        Value is 32 bit number in network byte order.

      PARITY 4

        Parity of characters
        Value is 32 bit number in network byte order with one of the
        following values.
        NONE  0
        ODD   1
        EVEN  2
        MARK  3
        SPACE 4

      DTR 5

        State of DTR
        Value is a 32 bit number in network byte order with one of the
        following values.
        OFF 0
        ON  1

      RTS 6

        State of RTS
        Value is a 32 bit number in network byte order with one of the
        following values.
        OFF 0
        ON  1

      TXBUFFER 7

        Characters in the the transmit buffer
        Value is a 32 bit number in network byte order with one of the
        following values.
        EMPTY       0
        NOT-EMPTY   non-zero

      FLOW-CONTROL 8

        Input and output flow control setting.
        Value is a 32 bit number in network byte order which represents a bit mask.
        The bitmask may contain any combination of the following values.

        RTSFLOW     1      (Input flow control - drop RTS to stop receiving)
        CTSFLOW     2      (Output flow control - stop transmitting when CTS drops)
        IXON        4      (Output flow control - start/stop sending on XON/XOFF)
        IXOFF       8      (Input flow control - send XON/XOFF to start/stop receiving)
        DCDFLOW    16      (Output flow control - stop transmitting when DCD drops)
        DTRFLOW    32      (Input flow control - drop DTR to stop receiving)
        DSRFLOW    64      (Output flow control - stop transmitting when DSR drops)

      SEND-CHANGED 32

        Specifies which items, if any, for which the server should send values
        when the value of the item changes.
        Value is a 32 bit number in network byte order which represents
        a bit mask. If a bit is 1, then the server should send values
        for that item, and it if is a 0, it should send values only upon
        request.  For example, if 0x00000001 is set as a value for
        SEND-CHANGED, then the server should send the value for MSR
        whenever that value changes.

      PURGE        33

        Purges receive and/or transmit queues.
        Value is a 32 bit number in network byte order with one of the
        following values.
        RX-QUEUE    1
        TX-QUEUE    2
        RXTX-QUEUE  3      (Purge both the RX and TX queues)

3. Default

      WON'T RSP
      DON'T RSP

         RSP information will not be exchanged.

      SEND-CHANGED 0

         Server only sends updated information as requested.

4. Motivation for the Option

   Many (if not all) terminal servers support the ability to set up a
   telnet listener on a serial port. This allows a connection to a port
   to be made via the network, however only (two way) data can be
   transferred between the client and the port.

   By using the Remote Serial Port (RSP) telnet option, the client is
   able to control non-data aspects of the port such as baud rate and
   modem signals.  This is especially important where the port is
   attached to a modem and modem signals are required to hangup the
   modem.

   This document defines a simple protocol which allows terminal servers
   (and other systems which provide access to serial ports via a network
   connection) to provide access to these features.

5. Description of the Option

   Willingness to exchange RSP information is agreed upon via
   conventional Telnet option negotiation.  WILL and DO are used only to
   obtain and grant permission for future discussion.  The actual
   exchange of status information occurs within option subcommands (IAC
   SB RSP...).

   Once the two hosts have exchanged a WILL and a DO, the sender of the
   DO RSP (the client) is free to request and set RSP information.  A
   successful DO RSP is required before SEND and SET requests can be
   used by the client and IS responses can be sent by the server. The
   negotiation indicates acceptance in one direction only. (It would
   generally not be appropriate to negotiate the RSP option in both
   directions).

   All RSP items are 1 octet in length and all RSP values are 32 bit values
   in network byte order. This allows multiple items or multiple {item, value}
   pairs to be specified in a single request or response without requiring that
   all items be understood by the recipient.

6.  Implementation Issues

   This specification allows for various items to be set or requested by
   a client. Support for all items is optional. Also it may be
   inappropriate to set or send a given item at any time.  Thus, a server
   responds to requests as follows.

   When a server receives a SET request, it should immediately make the
   change for each item in the list. If any item is not supported, not
   understood or not appropriate (doesn't make sense or the value is
   inappropriate), that item is ignored.  All items in a request are
   independent. That is, if one item fails, then the remaining items in
   the request should continue to be processed.

   Similarly, when a server receives a SEND request, it should respond
   with a IS request for each item in the SEND request which is
   understood and makes sense. Other items are ignored.

   No response is sent by the server as a result of a SET request.  It
   is the responsibility of the client to issue a SEND request if it
   wishes to determine whether a SET request has succeeded.

   SEND-CHANGED is an item like any other including the fact that
   support for it is optional. If it is supported, an IS request is sent
   by the server to the client whenever the value for an item changes
   value spontaneously (that is, other than in response to a SET
   request) for which a 1 bit is set in the SEND-CHANGED value.

   Note: No requirements are placed on the server in determining how
         soon after the change occurs that the IS request should be
         sent. This allows a server to combine multiple changes into a
         single request if multiple changes occur within a short time of
         one another. Also, a server may choose to delay sending of an
         IS request if the value of an item changes very quickly to
         avoid flooding the connection.  Every change of an item need
         not be (and should not be) sent in these circumstances.
         Rather, only the "last" change should be sent.

   Note: Only changes to the first 32 RSP items are supported by
         SEND-CHANGED.  This should be sufficient for all realistic
         implementations of remote serial ports.

7. Examples

   Note: In these examples, the C notation, 0x, is used to denote
         a hexadecimal number.

   In this example, the client gets the current values for all items
   known by the server.

      Client: IAC DO RSP

      Server: IAC WILL RSP

         (Client may now request or set RSP information at any time.
          Server is SEND-CHANGED 0)

      Client: IAC SB RSP SEND IAC SE

      Server: IAC SB RSP IS SEND-CHANGED 0 MSR 0x00 DTR ON BAUD-RATE
              9600 IAC SE

   In this example, the client turns on SEND-CHANGED and checks to see
   if it is supported by the server. The server sends change
   notifications.

      Client: IAC DO RSP

      Server: IAC WILL RSP

      Client: IAC SB RSP SET SEND-CHANGED 0x0000000F IAC SE

      Client: IAC SB RSP SEND SEND-CHANGED IAC SE

      Server: IAC SB RSP IS SEND-CHANGED 0x0000000F IAC SE

      Server: IAC SB RSP IS MSR 0x33 IAC SE

      Server: IAC SB RSP IS MSR 0x03 BAUD-RATE 38400 IAC SE


9. References:

     [1]  Postel, J., and J. Reynolds, "Telnet Protocol Specification",
          RFC 854, USC Information Sciences Institute, May 1983.

     [2]  Postel, J., and J. Reynolds, "Telnet Option Specification",
          RFC 855, USC Information Sciences Institute, May 1983.

     [3]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700,
          USC Information Sciences Institute, October 1994.


Author's Address

   Murray Bennett
   Stallion Technologies
   33 Woodstock Rd
   Toowong QLD 4066
   Australia

   Phone:  +61 7 3270 4277

   Email: murray@stallion.oz.au


Murray Bennett                    Stallion Technologies
Phone:  +61 7 3270 4277           33 Woodstock Rd
Fax:    +61 7 3270 4245           Toowong QLD 4066
Email:  murray@stallion.oz.au     Australia

INTERNET-DRAFT           EXPIRES: AUGUST 1997          INTERNET-DRAFT