INTERNET-DRAFT R. Barnes
File: draft-barnes-telnet-rsp-opt-00.txt Stallion Technologies
Expiration: January 13, 1998 M. Bennett
Revision: 001 Stallion Technologies
July 13, 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: January 13, 1998 [Page 1]
draft-barnes-telnet-rsp-opt-00.txt July 13, 1997
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)
Barnes, Bennett Expires: January 13, 1998 [Page 2]
draft-barnes-telnet-rsp-opt-00.txt July 13, 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: January 13, 1998 [Page 3]
draft-barnes-telnet-rsp-opt-00.txt July 13, 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: January 13, 1998 [Page 4]
draft-barnes-telnet-rsp-opt-00.txt July 13, 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: January 13, 1998 [Page 5]
draft-barnes-telnet-rsp-opt-00.txt July 13, 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: January 13, 1998 [Page 6]
draft-barnes-telnet-rsp-opt-00.txt July 13, 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: January 13, 1998 [Page 7]
draft-barnes-telnet-rsp-opt-00.txt July 13, 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
This document does not currently reference any other documents.
Barnes, Bennett Expires: January 13, 1998 [Page 8]
draft-barnes-telnet-rsp-opt-00.txt July 13, 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: January 13, 1998 [Page 9]