[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
INTERNET-DRAFT                                                 R. Barnes
File: draft-barnes-telnet-rsp-opt-01.txt           Stallion Technologies
Expiration: March, 1998                                       M. Bennett
Revision: 002                                      Stallion Technologies
                                                       September 4, 1997


                 Telnet Remote Serial Port (RSP) Option


Status of this Memo

   Distribution of this memo is unlimited.

   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 view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   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.




Barnes, Bennett           Expires: March, 1998                  [Page 1]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


1.  Command Name and Code

   RSP   43


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)







Barnes, Bennett           Expires: March, 1998                  [Page 2]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


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

      Bit 0  Delta Clear to Send
             Indicates the -CTS input signal has changed state since the
             last time it was read.

      Bit 1  Delta Data Set Ready
             Indicates the -DSR input signal has changed state since the
             last time it was read.

      Bit 2  Trailing Edge Ring Indicator
             Indicates the -RI input signal has changed from an active
             condition to an inactive condition.

      Bit 3  Delta Data Carrier Detect
             Indicates the -DCD input signal has changed state since the
             last time it was read.

      Bit 4  Clear to Send
             Current state of the CTS input signal.

      Bit 5  Data Set Ready
             Current state of the DSR input signal.

      Bit 6  Ring Indicator
             Current state of the RI input signal.

      Bit 7  Data Carrier Detect
             Current state of the DCD input signal.

   BAUD-RATE 1

      Baud rate Value is 32 bit number in network byte order.  The value
      0 is used to represent "unknown".

   STOP-BITS 2

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





Barnes, Bennett           Expires: March, 1998                  [Page 3]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


   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 which is the
      current number of characters in the transmit buffer, 0 implies the
      buffer is empty.

   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)



Barnes, Bennett           Expires: March, 1998                  [Page 4]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


      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)

   TXBREAK 9

      State of TX Break
      Value is a 32 bit number in network byte order with one of the
      following values.
      OFF        0       (Normal state)
      ON         1       (Transmit Break)

   RXBREAK 10

      State of RX Break
      Value is a 32 bit number in network byte order with one of the
      following values.
      OFF        0       (Normal state - not receiving break)
      ON         1       (Currently receiving Break)

   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 the value
      for that item immediately and any time it subsequently changes,
      and if it is a 0, it should send the value only upon request.  For
      example, if 0x00000001 is set as a value for SEND-CHANGED, then
      the server should send the value for MSR immediately and then
      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



Barnes, Bennett           Expires: March, 1998                  [Page 5]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


      RXTX-QUEUE  3      (Purge both the RX and TX queues)

3.  Default Specification

   WON'T RSP
   DON'T RSP

      RSP information will not be exchanged.

   SEND-CHANGED 0

      Server only sends updated information as requested.


4.  Motivation

   The Remote Serial Port telnet option allows a telnet client of a
   physical serial port to control non-data attributes of the port, such
   as baud rate, parity and output modem signal state.


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.

   Note that any occurrence of the octet IAC within an RSP item must be
   escaped.







Barnes, Bennett           Expires: March, 1998                  [Page 6]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


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




Barnes, Bennett           Expires: March, 1998                  [Page 7]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


   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


Security Considerations

   Security issues are not discussed in this document.


References

   [1]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
        1700, USC/Information Sciences Institute, October 1994.








Barnes, Bennett           Expires: March, 1998                  [Page 8]


draft-barnes-telnet-rsp-opt-01.txt                     September 4, 1997


Author's Addresses:

   Robert Barnes and Murray Bennett
   Stallion Technologies
   33 Woodstock Road
   Toowong,  QLD  4066
   Australia
   rab@stallion.oz.au











































Barnes, Bennett           Expires: March, 1998                  [Page 9]