As per Relevance of the word available, we have this rfc below:
Network Working Group G.
Request for Comments: 2217 Cisco Systems, Inc
Category: Experimental October 1997
Telnet Com Port Control
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This memo proposes a protocol to allow greater use of modems
to a network for outbound dialing purposes
Table of
1. Negotiation of the Com
Control Option Protocol .................. 5
2. Com Port Configuration Commands .................. 6
Baud
Data Bit
Stop Bit
3. Special Com Port Control Commands ................. 8
XON/XOFF Flow
HARDWARE Flow
BREAK
DTR
RTS
4. Notification of Com Port and .................. 12
Modem Line
5. Flow Control .................. 13
6. Security Considerations .................. 13
7. Author's Address .................. 14
8. Reference Section .................. 14
The Telnet protocol defines an interactive, character-
communications session. It was originally designed to establish
session between a client and a remote login service running on a
[5].
Clark Experimental [Page 1]
RFC 2217 Telnet Com Port Control Option October 1997
Many new business functions require a person to connect to
services to retrieve or deposit information. By in large,
remote services are accessed via an async dial up connection.
new class of functions include
- dial up connections to the
- connecting to bulletin
- connecting to internal and external
- sending and receiving faxes
The general nature of this new class of function requires
interactive, character-oriented communications session via an
modem. This is typically known as outbound modem dialing
To help defer the cost of installing and maintaining additional
lines which may be used very little per person, many
manufacturers have added the ability to establish a Telnet
directly to the outbound ports on many of the most popular
servers and routers, here after referred to as access servers
However, the current Telnet protocol definitions are not
to fully support this new use. There are three new areas
functionality which need to be added to the Telnet protocol
successfully support the needs of outbound modem dialing. These are
- The ability for the client to send com port
information to the access server which is connected to
outbound modem. This is needed to ensure the data
transmitted and received by the modem is formatted
at the byte level
- The ability for the access server to inform the client of
modem line or signal changes such as RLSD changes (
detect). This information is vital, since many client
packages use this information to determine if a session with
remote service has been established. RLSD changes are
used for signaling in Class I faxing [6].
- The ability to manage flow control between the client
the access server which does not interfere with the
control mechanisms used by the session between the client
the remote service. Unfortunately RFC 1372 "Telnet
Flow Control Option" [2] can not be used for this
because it relies on sending XON/XOFF style characters
maybe transmitted or received as a normal course of
client / remote service session
Clark Experimental [Page 2]
RFC 2217 Telnet Com Port Control Option October 1997
Though this discussion has focused on outbound modem dialing as
primary use of this protocol, the protocol can also be used for
serial device attached to an access server. Such devices could be
- serial
-
- monitoring devices such as pipe line monitors or
- general office equipment such as photo-copiers and
Definition of
Access Server - Any network device which accepts Telnet
and passes the data received to a com port,
passes data received from the com port to the
via the Telnet session
Baud Rate - For the purposes of this document, baud rate
mean the communications of data in bits per second
Client - Any network device which initiates a Telnet
to an access server
Outbound - Transmission of data from the modem attached to
access server to a remote service
Inbound - Transmission of data from the remote service to
modem attached to the access server
Remove Service - Any service which accepts dial-up connections
including fax machines
Clark Experimental [Page 3]
RFC 2217 Telnet Com Port Control Option October 1997
=====================
| |
| CLIENT |\
| | \ < ---- Local Area /
===================== \ Enterprise
\
\
=============================
| Telnet Interface |
| | |
| | |
| ACCESS SERVER | |
| | |
| | |
| Com Port Interface |
=============================
|
|
==================
| |
| MODEM |
| |
==================
|
Access to Remote Service |
most commonly Public Switched ----->|
Network |
|
|
======================
Could be Internet Service | |
Provider, Bulletin Board | |
or FAX machine | REMOTE SERVICE |
| |
| |
======================
Command Names and Codes
COM-PORT-OPTION 44
Clark Experimental [Page 4]
RFC 2217 Telnet Com Port Control Option October 1997
Client to Access Server Access Server to
SIGNATURE text
SET-BAUDRATE 1 101
SET-DATASIZE 2 102
SET-PARITY 3 103
SET-STOPSIZE 4 104
SET-CONTROL 5 105
NOTIFY-LINESTATE 6 106
NOTIFY-MODEMSTATE 7 107
FLOWCONTROL-SUSPEND 8 108
FLOWCONTROL-RESUME 9 109
SET-LINESTATE-MASK 10 110
SET-MODEMSTATE-MASK 11 111
PURGE-DATA 12 112
Discussion: As initially proposed, com port
commands are only sent from the client to the
server. There is no current vision that the
server would initiate the use of a com port
command, only the notify commands. However, to allow
access server initiated com port configurations
command values have been established
1. Negotiation of the Com Port Control Option
The negotiation of the com port control option protocol uses
standard Telnet negotiation protocol mechanism
IAC WILL COM-PORT-
The sender of this command is willing to send com
control option commands
IAC WONT COM-PORT-
The sender of this command refuses to send com
control option commands
IAC DO COM-PORT-
The sender of this command is willing to accept com
control option commands
IAC DONT COM-PORT-
The sender of this command refuses to accept com port
options commands
Typically a client will use WILL and WONT, while an access
will use DO and DONT
Clark Experimental [Page 5]
RFC 2217 Telnet Com Port Control Option October 1997
2. Com Port Configuration
Once DO and WILL have been negotiated, the client may send any of
following commands. The client can send these commands at any
and multiple times throughout the Telnet session. Each
transmitted from the client to the access server must be
once the command has been processed by the access server.
confirmation informs the client of the value set at the access
after the processing of the command. This acknowledgment is not
to acknowledge the receipt of the command, which is handled at
TCP protocol layer. Its purpose is to inform the client of the
in use, which may be different than the value requested in
client's command. For example, the client may request a baud
higher than the access service can provide. If an acknowledgment
not received by the client within a reasonable time (such as
the delay acknowledgment timer), the client may wish to resend
command or terminate the session
Though the commands may be sent from the client to the access
in any sequence, there are sequences which may result in
configurations for the com port (for example: EVEN parity is
valid if the data size is set to less than 8 bits). Thus it
recommended that commands be issued in the following sequence
1. SET-
2. SET-
3. SET-
4. SET-
IAC SB COM-PORT-OPTION SIGNATURE IAC
This command may be sent by either the client or the
server to exchange signature information. If the command
sent without it is a request from the sender to
the signature text of the receiver. The text may be
combination of any characters. There is no structure to
field. It may contain manufacturer information,
number information, or any other information desired. If
IAC character appears in the text it must be translated
IAC-IAC to avoid conflict with the IAC which
the command
IAC SB COM-PORT-OPTION SET-BAUD IAC
This command is sent by the client to the access server to
the baud rate of the com port. The value is four octets (4 bytes).
The value is represented in network standard format. The
is the baud rate being requested. A special case is the value 0.
If the value is zero the client is requesting the current
rate of the com port on the access server
Clark Experimental [Page 6]
RFC 2217 Telnet Com Port Control Option October 1997
Discussion: Though baud rates used today form a very sparse space
and the initial version of the option used an
based baud rate table, after much discussion with
number of groups it has been determined that
actual baud rate should be used. There are two
reasons. 1) It limits the number of updates to
option as faster baud rates come into use
2) It provides the greatest amount of
in the selection of the baud rates
IAC SB COM-PORT-OPTION SET-DATASIZE IAC
This command is sent by the client to the access server to
the data bit size. The command can also be sent to query
current data bit size. The value is one octet (byte). The
is an index into the following value table
Value Data Bit
0 Request Current Data Bit
1 Available for Future
2 Available for Future
3 Available for Future
4 Available for Future
5 5
6 6
7 7
8 8
9-127 Available for Future
Discussion: There are only eight possible values for the data
size, only four have ever been used historically
only two are commonly used today. The use of
command-value format is recommended to
consistency with other commands. It also reduces
number of commands defined in the protocol,
allows for future expansion
IAC SB COM-PORT-OPTION SET-PARITY IAC
This command is sent by the client to the access server to
the parity. The command can also be sent to query the
parity. The value is one octet (byte). The value is an index
the following value table
Value Parity [1]
0 Request Current Data
1
2
3
4
Clark Experimental [Page 7]
RFC 2217 Telnet Com Port Control Option October 1997
5
6-127 Available for Future
Discussion: There are only five possible values for
commonly used today. The use of the command-
format is recommended to preserve consistency
other commands
IAC SB COM-PORT-OPTION SET-STOPSIZE IAC
This command is sent by the client to the access server to
the number of stop bits. The command can also be sent to
the current stop bit size. The value is one octet (byte).
value is an index into the following value table
Value Stop Bit
0 Request Current Data
1 1
2 2
3 1.5
4-127 Available for Future
Discussion: Stop bit 1.5 is supported by most com port
only if data size is set to 5 bits. It is
commonly used
3. Special Com Port Control
The client can send this command to the access server at any
and multiple times throughout the Telnet session. Each
transmitted from the client to the access server is
with a confirmation of the command and the actual value set.
client should expect a response within a reasonable time (such
twice the delay acknowledgment timer). The client may wish
resend any command which is not acknowledged or terminate
session
IAC SB COM-PORT-OPTION SET-CONTROL IAC
This command is sent by the client to the access server to
special com port options. The command can also be sent to
the current option value. The value is one octet (byte).
value is an index into the following value table
Value Control
0 Request Com Port Flow Control
(outbound/both
1 Use No Flow Control (outbound/both
2 Use XON/XOFF Flow Control (outbound/both
3 Use HARDWARE Flow Control (outbound/both
Clark Experimental [Page 8]
RFC 2217 Telnet Com Port Control Option October 1997
4 Request BREAK
5 Set BREAK State
6 Set BREAK State
7 Request DTR Signal
8 Set DTR Signal State
9 Set DTR Signal State
10 Request RTS Signal
11 Set RTS Signal State
12 Set RTS Signal State
13 Request Com Port Flow Control Setting (inbound
14 Use No Flow Control (inbound
15 Use XON/XOFF Flow Control (inbound
16 Use HARDWARE Flow Control (inbound
17 Use DCD Flow Control (outbound/both
18 Use DTR Flow Control (inbound
19 Use DSR Flow Control (outbound/both
20-127 Available for Future
Discussion: Flow control options were divided into inbound
outbound to take full advantage of
programming interfaces and access
capabilities
Discussion: The outbound values should set flow control for
outbound and inbound. If inbound is to be, or
be, set separately it should be done after
setting of the outbound value
Discussion: If the access server is not able to set inbound
control differently from the outbound flow control
it should ignore the inbound flow control
and set the flow control option based on the
flow control commands only
IAC SB COM-PORT-OPTION SET-LINESTATE-MASK IAC
This command is sent by the client to the access server to set
bit mask for the sending of the NOTIFY-LINESTATE option (
section 4). When the LINESTATE changes on the access server,
access server will "AND" the new LINESTATE with the LINESTATE
MASK. If the result is not zero, the access server will send
result of the "AND" as the value in a NOTIFY-LINESTATE com
option. If more than one bit satisfies the LINESTATE-MASK,
one NOTIFY-LINESTATE, with all the satisfying bits, will be
to the client. The SET-LINESTATE-MASK may be any combination
bits as listed below. These are the same bit values used in
NOTIFY-LINESTATE option. The SET-LINESTATE-MASK values are
on the most popular UART (com port control chip) in use [1].
Clark Experimental [Page 9]
RFC 2217 Telnet Com Port Control Option October 1997
Bit Position Value
7 128 Time-out
6 64 Transfer Shift Register
5 32 Transfer Holding Register
4 16 Break-detect
3 8 Framing
2 4 Parity
1 2 Overrun
0 1 Data
Discussion: The SET-LINESTATE-MASK value of 0 will prevent
access server from sending NOTIFY-LINESTATE
to the client
Discussion: The SET-LINESTATE-MASK value of 255 will allow
access server to send a NOTIFY-LINESTATE option
the client each time the LINESTATE changes on
access server
Discussion: The initial LINESTATE-MASK at the access server is 0.
Discussion: The client does not have to send a
SET-LINESTATE-MASK after receiving a NOTIFY
LINESTATE. The LINESTATE-MASK on the access
is retained until set by the client or reset at
start of a new Telnet session
IAC SB COM-PORT-OPTION SET-MODEMSTATE-MASK IAC
This command is sent by the client to the access server to set
bit mask for the sending of the NOTIFY-MODEMSTATE option (
section 4). When the MODEMSTATE changes on the access server
the access server will "AND" the new MODEMSTATE with
MODEMSTATE-MASK. If the result is not zero, the access
will send the result of the "AND" as the value in a NOTIFY
MODEMSTATE com port option. If more than one bit satisfies
MODEMSTATE-MASK, only one NOTIFY-MODEMSTATE, with all
satisfying bits, will be sent to the client. The SET
MODEMSTATE-MASK may be any combination of bits as listed below
These are the same bit values used in the NOTIFY-
option. The SET-MODEMSTATE-MASK values are based on the
popular UART (com port control chip) in use [1].
Clark Experimental [Page 10]
RFC 2217 Telnet Com Port Control Option October 1997
Bit Position Value
7 128 Receive Line Signal
(also known as Carrier Detect
6 64 Ring
5 32 Data-Set-Ready Signal
4 16 Clear-To-Send Signal
3 8 Delta Receive Line Signal
2 4 Trailing-edge Ring
1 2 Delta Data-Set-
0 1 Delta Clear-To-
Discussion: The SET-MODEMSTATE-MASK value of 0 will prevent
access server from sending NOTIFY-MODEMSTATE
to the client
Discussion: The SET-MODEMSTATE-MASK value of 255 will allow
access server to send a NOTIFY-MODEMSTATE option
the client each time the MODEMSTATE changes on
access server
Discussion: The initial MODEMSTATE-MASK at the access
is 255.
Discussion: The client does not have to send a
SET-MODEMSTATE-MASK after receiving a NOTIFY
MODEMSTATE. The MODEMSTATE-MASK on the access
is retained until set by the client or reset at
start of a new Telnet session
IAC SB COM-PORT-OPTION PURGE-DATA IAC
This command is sent by the client to the access server
instruct the access server to immediately clear all data from
buffer or buffers referenced by the value. The value is
octet (byte). The value is an index into the following
table
Value Purge Data
0 Available for Future
1 Purge access server receive data
2 Purge access server transmit data
3 Purge both the access server receive
buffer and the access server transmit
4-127 Available for Future
Clark Experimental [Page 11]
RFC 2217 Telnet Com Port Control Option October 1997
4. Notification of Com port and Modem Line
The access server can send these commands to the client any
and multiple times throughout the Telnet session. The
server should send the appropriate command to the client as
as the com port or modem line changes occurs. The client
not issue a response to these commands
IAC SB COM-PORT-OPTION NOTIFY-LINESTATE IAC
The value is one octet (byte). The value is a bit
composition made up from the value table below. Multiple
values may be set in a single transmission. The values are
on the most popular UART (com port control chip) in use [1].
Bit Position Value
7 128 Time-out
6 64 Transfer Shift Register
5 32 Transfer Holding Register
4 16 Break-detect
3 8 Framing
2 4 Parity
1 2 Overrun
0 1 Data
Discussion: The LINESTATE is the line state of the UART
the access server
IAC SB COM-PORT-OPTION NOTIFY-MODEMSTATE IAC
The value is one octet (byte). The value is a bit
composition made up from the value table below. Multiple
values may be set in a single transmission. The values are
on the most popular UART (com port control chip) in use [1].
Bit Position Value
7 128 Receive Line Signal
(also known as Carrier Detect
6 64 Ring
5 32 Data-Set-Ready Signal
4 16 Clear-To-Send Signal
3 8 Delta Receive Line Signal
2 4 Trailing-edge Ring
1 2 Delta Data-Set-
0 1 Delta Clear-To-
Clark Experimental [Page 12]
RFC 2217 Telnet Com Port Control Option October 1997
5. Flow
The client and/or access server can send these commands any time
multiple times throughout the Telnet session
IAC SB COM-PORT-OPTION FLOWCONTROL-SUSPEND IAC
The sender of this command is requesting that the
suspend transmission of both data and commands until
FLOWCONTROL-RESUME is transmitted by the sender
IAC SB COM-PORT-OPTION FLOWCONTROL-RESUME IAC
The sender of this command is requesting that the receiver
transmission of both data and commands
Discussion: Established Telnet sessions are initially in
resume state between the client and the access
and the access server and the client. There is
need to send the resume command during
initialization
Discussion: Multiple concurrent suspend commands may be sent
Secondary suspend commands can be ignored
Transmission will resume with the sending of a
resume command
Discussion: The flow control option is designed to handle
to access server flow control for the Telnet session
This option has been added in deference to RFC 1372:
Telnet Remote Flow Control Option [2]. RFC 1372
a simple character XON/XOFF technology to
flow control. This can lead to two problems. First
the flow control characters may be valid data values
Second, the flow control characters may be used
end to end flow control (client application to
dial up service).
6. Security
There are two security issues to discuss; authentication
resetting resources
Authentication can follow either the Kerberos authentication
established in RFC 1411 [3] or the SPX authentication
established in RFC 1412 [4].
Once the Telnet session between the client and the access server
been terminated, the access server should ensure the connection
the remote service is disconnected and the com port geometry (
Clark Experimental [Page 13]
RFC 2217 Telnet Com Port Control Option October 1997
rate, data size, stop bits, parity, and flow control) is reset to
factory or administrator defined configuration. This ensures the
port is in a known state and ready to receive the next
session. This will make operations more predicable and
problems which might occur from starting a new session with
com port configurations
7. Author's
Glen Clark, Software
Cisco Systems, Inc
170 West Tasman
San Jose, CA 96134
EMail: glenc@cisco.
WEB: www.cisco.
8. Reference
[1] Joe Campbell. C Programmer's Guide to Serial Communications
Second Edition. Indianapolis: SAMS Publishing, 1993. 213-224.
[2] Hedrick, C., and D. Borman, "Telnet Remote Flow Control Option",
RFC 1372, Cray Research, Inc., October 1992.
[3] Borman, D., "Telnet Authentication: Kerberos Version 4",
RFC 1411, Cray Research, Inc., January 1993.
[4] Alagappan, K., "Telnet Authentication: SPX",
RFC 1412, Digital Equipment Corporation, January 1993.
[5] D. E. Comer and David Stevens. Internetworking with TCP/IP
Volume III. Prentice Hall, 1993.
[6] Andrew Margolis. The FAX Modem Sourcebook. John Wiley & Sons
1995.
Clark Experimental [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
