Network Working Group Telnet Working Group
Request for Comments: 1184 D. Borman, Editor
Obsoletes: RFC 1116 Cray Research, Inc.
October 1990
Status of this Memo
This memo describes a Draft Standard for the Internet
community, and requests discussion and suggestions
for improvements. This RFC specifies an IAB standards
track protocol for the Internet community. Please
refer to the current edition of the "IAB Official
Protocol Standards" for the standardization state
and status of this protocol. Distribution of this
memo is unlimited.
Changes from RFC 1116:
Two new mode bits have been added, SOFT_TAB and
LIT_ECHO. These bits allow the server to give the
client some advise on how to echo tabs and non-printable
characters.
Several new special character mappings have been
added for cursor motion when visual editing is supported.
These are: Move cursor one character left/right (SLC_MCL/SLC_MCR),
move cursor one word left/right (SLC_MCWL/SLC_MCWR),
move cursor to begining/end of line (SLC_MCBOL/SLC_MCEOL),
enter insert/overstrike mode (SLC_INSRT/SLC_OVER),
erase one character/word to the right (SLC_ECR/SLC_EWR),
and erase to the beginning/end of the line (SLC_EBOL/SLC_EEOL).
Overview
Linemode Telnet is a way of doing terminal character
processing on the client side of a Telnet connection.
While in Linemode with editing enabled for the local
side, network traffic is reduced to a couple of packets
per command line, rather than a couple of packets
per character typed. This is very useful for long
delay networks, because the user has local response
time while typing the command line, and only incurs
the network delays after the command is typed. It
is also useful to reduce costs on networks that charge
on a per packet basis. Please send comments to the
telnet-ietf@cray.com mailing list.
Table of Contents
1. Command Names and Codes
LINEMODE 34
MODE 1
EDIT 1
TRAPSIG 2
MODE_ACK 4
SOFT_TAB 8
LIT_ECHO 16
FORWARDMASK 2
SLC 3
SLC_SYNCH 1
SLC_BRK 2
SLC_IP 3
SLC_AO 4
SLC_AYT 5
SLC_EOR 6
SLC_ABORT 7
SLC_EOF 8
SLC_SUSP 9
SLC_EC 10
SLC_EL 11
SLC_EW 12
SLC_RP 13
SLC_LNEXT 14
SLC_XON 15
SLC_XOFF 16
SLC_FORW1 17
SLC_FORW2 18
SLC_MCL 19
SLC_MCR 20
SLC_MCWL 21
SLC_MCWR 22
SLC_MCBOL 23
SLC_MCEOL 24
SLC_INSRT 25
SLC_OVER 26
SLC_ECR 27
SLC_EWR 28
SLC_EBOL 29
SLC_EEOL 30
SLC_DEFAULT 3
SLC_VALUE 2
SLC_CANTCHANGE 1
SLC_NOSUPPORT 0
SLC_LEVELBITS 3
SLC_ACK 128
SLC_FLUSHIN 64
SLC_FLUSHOUT 32
EOF 236
SUSP 237
ABORT 238
2. Command Meanings
2.1 The LINEMODE function
IAC WILL LINEMODE
The sender of this command REQUESTS permission to
begin sub- negotiation of the editing/signaling status.
This should only be sent by the client side of the
connection.
IAC WONT LINEMODE
The sender of this command DEMANDS that sub-negotiation
of the editing/signaling status not be allowed.
IAC DO LINEMODE
The sender of this command REQUESTS that the remote
side begin sub-negotiation of the editing/signaling
status. This should only be sent by the server side
of the connection.
IAC DONT LINEMODE
The sender of this command DEMANDS that the remote
side not begin sub-negotiation of the editing/signaling
status.
2.2 LINEMODE suboption MODE
IAC SB LINEMODE MODE mask IAC SE
The sender of this command CONFIRMS, or REQUESTS
permission for, a switch to the mode defined by "mask".
The "mask" is a bit mask of various modes that the
connection can be in. Under normal operation, the
server side of the connection will initiate mode changes,
and the client will confirm the mode changes. The
currently defined modes are:
EDIT When set, the client side of the connection should
process all input lines, performing any editing functions,
and only send completed lines to the remote side. When
unset, client side should not process any input from the
user, and the server side should take care of all
character processing that needs to be done.
TRAPSIG When set, the client side should translate appropriate
interrupts/signals to their Telnet equivalent. (These
would be IP, BRK, AYT, ABORT, EOF, and SUSP) When unset,
the client should pass interrupts/signals as their normal
ASCII values.
FLOW Logically, this belongs in the "mask". However, this
would overlap the Telnet TOGGLE-FLOW-CONTROL option, so
the Telnet TOGGLE-FLOW-CONTROL option is used instead.
When DO/WILL LINEMODE is negotiated, DO/WILL TOGGLE-
FLOW-CONTROL should also be negotiated. See RFC 1080,
"Telnet Remote Flow Control", for correct usage.
ECHO Logically, this belongs in the "mask". However, this
would overlap the Telnet ECHO option, so the Telnet ECHO
option is used instead. The client side should never
negotiate "WILL ECHO". When the server has negotiated
"WILL ECHO", the client should not echo data typed by the
user back to the user. When the server has negotiated
"WONT ECHO", the the client is responsible for echoing
data typed by the user back to the user. See RFC 857,
"Telnet ECHO OPTION" for a complete discussion on the use
of the Telnet ECHO option.
SOFT_TAB When set, the client side should expand
the Horizontal Tab (HT) code, USASCII 9, into the
appropriate number of spaces to move the printer to
the next horizontal tab stop. When unset, the client
side should allow the Horizontal Tab code to pass
through un-modified.
LIT_ECHO When set, if the client side is echoing
a non-printable character that the user has typed
to the users screen, the character should be echoed
as the literal character. If the LIT_ECHO bit is not
set, then the client side may echo the character in
any manner that it desires. (Many systems echo unprintable
characters as two character sequences, for example,
they will echo "^A" for an ASCII 1 value.)
When the client side of a connection receives a
MODE command, it MUST agree with at least the state
of the EDIT and TRAPSIG bits. If a MODE command is
received with a mode mask that is currently in use
(ignoring the MODE_ACK bit), the MODE command is ignored.
If a MODE command is received that is different from
the current mode mask, then a reply is sent with either
the new mode mask and the MODE_ACK bit set, or a subset
of the new mode mask. The only exception is that if
the server receives a MODE with either the EDIT or
TRAPSIG bits not set, it may set the EDIT and TRAPSIG
bits in the response, and if the client receives a
MODE with the EDIT or TRAPSIG bits set, it may not
clear them in the response.
When a MODE command is received with the MODE_ACK
bit set, and the mode is different that what the current
mode is, the client will ignore the new mode, and
the server will switch to the new mode. This ensures
that both sides of the connection will resolve to
the same mode. In all cases, a response is never generated
to a MODE command that has the MODE_ACK bit set.
2.3 LINEMODE suboption FORWARDMASK
IAC SB LINEMODE DO FORWARDMASK mask0 mask1 ... mask31
IAC SE
The sender of this command request that the other
side send any buffered data when any of the ASCII
characters defined by the bit mask are received. Only
the side of the connection that sent DO LINEMODE (the
server side) may negotiate this. The mask is up to
32 octets long. Each octet represents 8 ASCII character codes.
The high order bit of mask0 corresponds to an ASCII code of 0.
The low order bit of mask0 corresponds to an ASCII code of 7. The
high order bit of mask1 corresponds to an ASCII code of 8. The
low order bit of mask1 corresponds to an ASCII code of 15, and so
on. The mask list may be terminated before the end of the list, in
which case all the rest of the mask octets are assumed to be reset
(equal to zero). When the server side is in DONT TRANSMIT-BINARY
mode, then only the first 16 octets of the mask (ASCII codes 0
through 127) are used. If any individual octet of the mask is
equal to IAC, it must be sent as a double IAC.
IAC SB LINEMODE DONT FORWARDMASK IAC SE
The sender of this command requests that the other
side stop using the forward mask to determine when
to send buffered data.
IAC SB LINEMODE WILL FORWARDMASK IAC SE
This command is sent in response to a DO FORWARDMASK
command. It indicates that the forward mask will be
used to determine when to send buffered data.
IAC SB LINEMODE WONT FORWARDMASK IAC SE
This command is sent in response to a DO FORWARDMASK
command. It indicates that the forward mask will not
be used to determine when to send buffered data.
2.4 LINEMODE suboption SLC, Set Local Characters
The SLC suboption uses a list of octet triplets.
The first octet specifies the function, the second
octet specifies modifiers to the function, and the
third octet specifies the ASCII character for the
function.
IAC SB LINEMODE SLC <list of octet triplets>
IAC SE
The sender of this command REQUESTS that the list
of octet triplets be used to set the local character
to be used to send to perform the specified function.
There are four levels that a function may be set
to. SLC_NOSUPPORT is the lowest, SLC_CANTCHANGE is
the next higher level, SLC_VALUE is above that, and
SLC_DEFAULT is the highest level.
If the SLC_LEVELBITS in the second octet are equal
to SLC_DEFAULT, then this particular function should
use the system default on the other side of the connection.
If the SLC_LEVELBITS in the second octet are equal
to SLC_VALUE, then this function is supported, and
the current value is specified by the third octet.
If the SLC_LEVELBITS in the second octet are equal
to SLC_CANTCHANGE, then this is a function that is
supported, but the value for this function, specified
in the third octet, cannot be changed.
If the SLC_LEVELBITS in the second octet are equal
to SLC_NOSUPPORT, then this particular function is
not supported and should be disabled by the other
side.
If this is a response to a previous request to change
a special character, and we are agreeing to the change,
then the SLC_ACK bit must be set in the second octet.
If the SLC_FLUSHIN bit is set in the second octet,
then whenever this function is sent, a Telnet "sync"
should be sent at the same time to flush the input
stream.
If the SLC_FLUSHOUT bit is set in the second octet,
then whenever this function is sent, output data should
be flushed.
Only the client may send an octet triplet with the
first octet equal to zero. In this case, the SLC_LEVELBITS
may only be set to SLC_DEFAULT or SLC_VALUE, and the
third octet does not matter. When the server receives
0 SLC_DEFAULT 0, it should switch to its system default
special character settings, and send all those special
characters to the client. When the server receives
0 SLC_VALUE 0, it should just send its current special
character settings. Note that if the server does not
support some of the editing functions, they should
be sent as XXX SLC_DEFAULT 0, rather than as XXX SLC_NOSUPPORT
0, so that the client may choose to use its own values
for those functions, rather than have to disable those
functions even if it supports them.
If any of the octets in the list of octet triplets
is equal to IAC, it must be sent as a double IAC.
When a connection is established, it is the responsibility
of the client to either request the remote default
values for the special characters, or to send across
what all the special characters should be set to.
The function values can be put into two groups,
functions that are to be translated to their Telnet
equivalents before being sent across the Telnet connection,
and functions that are to be recognized and processed
locally.
First, we have those characters that are to be mapped
into their Telnet equivalents:
SLC_SYNCH Synch. See RFC 854,
"TELNET PROTOCOL SPECIFICATION", for a complete description.
SLC_BRK Break. See RFC 854, "TELNET PROTOCOL SPECIFICATION",
for a complete description.
SLC_IP Interrupt Process. See RFC 854, "TELNET PROTOCOL
SPECIFICATION", for a complete description.
SLC_AO Abort Output. See RFC 854, "TELNET PROTOCOL
SPECIFICATION", for a complete description.
SLC_AYT Are You There. See RFC 854, "TELNET PROTOCOL
SPECIFICATION", for a complete description.
SLC_EOR End of Record. See RFC 885, "TELNET END OF RECORD
OPTION" for a complete description.
SLC_ABORT Abort. See section 2.5 for a complete
description.
SLC_EOF End of File. See section 2.5 for a complete
description.
SLC_SUSP Suspend. See section 2.5 for a complete description.
Next, we have the locally interpreted functions.
SLC_EC Erase Character. This is the character that is typed to
erase one character from the input stream. See RFC 854,
"TELNET PROTOCOL SPECIFICATION", for a complete
description.
SLC_EL Erase Line. This is the character that is typed to
erase the entire contents of the current line of input.
See RFC 854, "TELNET PROTOCOL SPECIFICATION", for a
complete description.
SLC_EW Erase Word. This is the character that is typed to
erase one word from the input stream.
SLC_RP Reprint Line. This is the character that is typed to
cause the current line of input to be reprinted, leaving
the cursor at the end of the line.
SLC_LNEXT Literal Next. This is the character that
is typed to indicate that the next character is to
be taken literally, no character processing should
be done with it, and if it is a special character
that would normally get mapped into a Telnet option,
that mapping should not be done.
SLC_XON Start Output. This is the character that is sent to
resume output to the users terminal.
SLC_XOFF Stop Output. This is the character that is sent to stop
output to the users terminal.
SLC_FORW1 Forwarding character. This is a character
that should cause all data currently being buffered,
and this character, to be sent immediately.
SLC_FORW2 Forwarding character. This is another
character that is to be treated in the same manner
as SLC_FORW1.
SLC_MCL Move cursor one character left. When visual editing is
supported, this is the character that, when typed, will
move the cursor one character to the left in the
display.
SLC_MCR Move cursor one character right. When visual editing is
supported, this is the character that, when typed, will
move the cursor one character to the right in the
display.
SLC_MCWL Move cursor one word left. When visual editing is
supported, this is the character that, when typed, will
move the cursor one word to the left in the display.
SLC_MCWR Move cursor one word right. When visual editing is
supported, this is the character that, when typed, will
move the cursor one word to the right in the display.
SLC_MCBOL Move cursor to the begining of the line.
When visual editing is supported, this is the character
that, when typed, will move the cursor to the begining
of the line that is being edited.
SLC_MCEOL Move cursor to the end of the line. When
visual editing is supported, this is the character
that, when typed, will move the cursor to the end
of the line that is being edited.
SLC_INSRT Enter insert mode. When visual editing
is supported, after this character is typed, all normal
characters that are subsequently typed will be inserted
into the display.
SLC_OVER Enter overstrike mode. When visual editing is
supported, after this character is typed, all normal
charactersthat are subsequently typed will overwrite
any characters in the current display. If the
SLC_INSRT and SLC_OVER variables are set to the same
value, then that value is to act as a toggle between
overstrike and insert mode.
SLC_ECR Erase character to the right. When visual editing is
supported, this is the character that, when typed, will
erase one character to the right of the cursor.
SLC_EWR Erase word to the right. When visual editing is
supported, this is the character that, when typed,
will erase one word to the right of the cursor.
SLC_EBOL Erase to the begining of the line. When visual editing
is supported, this is the character that, when typed,
will erase all the characters to the left of the cursor.
SLC_EEOL Erase to the end of the line. When visual editing is
supported, this is the character that, when typed, will
erase all characters to the right of the cursor.
For SLC_EEOL, SLC_EWR, and SLC_ECR, if a system
has a cursor that is not diplayed between characters,
but is positioned over a character, that character
is assumed to be to the right of the cursor. Thus,
the SLC_ECR will erase the character that is under
the current cursor position.
2.5 New control characters
IAC ABORT
Abort. Similar to "IAC IP", but means only to abort or terminate
the process to which the NVT is connected. (The Telnet spec says
IP may "suspend, interrupt, abort or terminate" the process.) If a
system does not have two methods of interrupting a process, then
ABORT and IP should have the same effect.
IAC SUSP
Suspend the execution of the current process attached
to the NVT in such a way that another process will
take over control of the NVT, and the suspended process
can be resumed at a later time. If the receiving system
does not support this functionality, it should be
ignored.
IAC EOF
End Of File. The recipient should notify the process
connected to the NVT that an end of file has been
reached. This is intended for systems that support
the ability for the user to type in an EOF character
at the keyboard.
3. Default Specification
The default specification for this option is
WONT LINEMODE
DONT LINEMODE
meaning there will not be any subnegotiation of the mode of the
connection.
If WILL LINEMODE is negotiated, the defaults are:
IAC SB LINEMODE MODE 0 IAC SE IAC SB LINEMODE WONT
FORWARDMASK IAC SE
If DO LINEMODE is negotiated, the defaults are:
IAC SB LINEMODE MODE 0 IAC SE IAC SB LINEMODE DONT
FORWARDMASK IAC SE
Character values for SLC default to SLC_NOSUPPORT.
4. Motivation
With increasing Telnet usage, it has become apparent
that the ability to do command line processing on
the local machine and send completed lines to the
remote machine is a feature necessary in several environments.
First, in the case of a connection over long delay
equipment, it is very frustrating to the user to have
the echoing of his data take several seconds. Second,
some supercomputers, due to their nature, are not
good at handling and processing single character input.
For these machines, it is better to have the front
end computer do the character processing, and leave
the supercomputer's cycles available for doing vectorized
number crunching.
There have been attempts to make local line editing
work within the existing Telnet specs. Indeed, the
4.3 BSD tape includes a version of Telnet that attempts
to do this through recognition of the state of the
ECHO and SUPRESS-GO-AHEAD options; other implementations
do this recognition purely through the ECHO option.
There are problems with both of these methods. Using
just the ECHO provides no mechanism to have ECHO to
the user turned off, and leave local character processing
on, for example, when a user is typing a password.
The usage of the SUPRESS-GO-AHEAD comes from reading
into RFC 858, where it states:
"In many TELNET implementations it will be desirable to couple the
SUPRESS-GO-AHEAD option to the echo option so that when the echo
option is in effect, the SUPPRESS-GO-AHEAD option is in effect
simultaneously: both of these options will normally have to be in
effect simultaneously to effect what it commonly understood to be
character at a time echoing by the remote computer."
The reverse reading of this is that without the
ECHO option or the SUPPRESS-GO-AHEAD option, you are
in line at a time mode, implying local line editing.
This has the obvious problem that that is not what
the SUPPRESS-GO-AHEAD option is supposed to mean.
Other shortcomings are that the Telnet specification
is not rich enough to handle all of the special characters
that some of the current operating systems support.
For example, the ECHO/SGA implementation supports
two ways of interrupting a process, by borrowing the
BRK option for the second interrupt. Some implementations
have taken the EOR option to send an End-Of-File.
Obviously, this is using things for which they were
not intended, and the correct solution would be to
define new options.
Another problem is that some implementations of
line mode buffer up the input until the end of the
line, and then send the whole line across, editing
characters and all. No local editing of the line has
been done.
After examining several implementations, it has
become clear that the correct thing to do is to implement
new options to enhance the current Telnet specification
so that it can support local line editing in a reasonable,
reliable, and consistent manner.
There are three states that are of interest.
1) Local line editing and local signal trapping
2) Remote line editing, local signal trapping
3) Remote line editing, remote signal trapping
The case of local line editing and remote signal
trapping is not a very interesting case, because you
don't recognize the signals, and cannot send them
to the remote side for it to recognize until the line
has been completed. Also, special signals usually
will have an effect on the line editing function,
and if they are not being trapped locally the desired
action will not happen.
Local line editing means that all normal command
line character processing, like "Erase Character"
and "Erase Line", happen on the local system, and
only when "CR LF" (or some other special character)
is encountered is the edited data sent to the remote
system.
Signal trapping means, for example, that if the
user types the character associated with the IP function,
then the "IAC IP" function is sent to the remote side
instead of the character typed. Remote signal trapping
means, for example, that if the user types the character
associated with the IP function, then the "IAC IP"
function is not sent to the remote side, but rather
the actual character typed is sent to the remote side.
5. Implementation Rules
It is expected that any implementation that supports
the Telnet LINEMODE option will support all of this
specification.
5.1 User Interface
Normally, the entire user interface is left up to
the implementor. However, there is functionality that
the user should be able to specify on the client side
of the connection. During a Telnet session, the client
side should allow some mechanism for the user to give
commands to the local Telnet process. These commands
should at least allow the user to:
1) Change the mode of the connection. The user should be able to
attempt to turn EDIT, FLOW, TRAPSIG, and ECHO on and off. The
server may refuse to change the state of the EDIT and TRAPSIG
bits.
2) Import or export SLC. The user should be able to tell the
local Telnet process whether he wants to use the local or
the current or default remote definitions of the special
characters.
3) Manual sending of options. The user should be able to tell
the local Telnet process to explicitly send any of the Telnet
options (like IP, ABORT, AYT, etc).
5.2 End of line terminators.
When LINEMODE is turned on, and when in EDIT mode,
when any normal line terminator on the client side
operating system is typed, the line should be transmitted
with "CR LF" as the line terminator. When EDIT mode
is turned off, a carriage return should be sent as
"CR NUL", a line feed should be sent as LF, and any
other key that cannot be mapped into an ASCII character,
but means the line is complete (like a DOIT or ENTER
key), should be sent as "CR LF".
5.3 Output processing
Regardless of what mode has been negotiated, the
server side is responsible for doing all output processing.
Specificly, it should send "CR LF" when it wants the
"newline" function, "CR NUL" when it wants just a
carriage return, and "LF" when it wants just a linefeed.
5.4 A terminal driver in Telnet?
Conforming implementations need not do all the line
editing themselves. There is nothing wrong with letting
the system terminal driver handle the line editing,
and have it hand to the Telnet application the completed
and edited line, which is then sent to the remote
system.
5.5 Setting of Local Characters
When this RFC was being developed, the original
thought was that both sides of the connection would
use their own defaults for the special characters,
even if they were not the same on both sides of the
connection. If this scheme is used, though, the view
that the user has is that the local special characters
are being used, and the remote character settings
don't matter. It was decided that the client side
of the connection should be in control of the character
settings.
When LINEMODE is negotiated, the client must either
export the local character settings to the server,
or send a request (SLC 0 SLC_DEFAULT 0) to import
the servers special characters. The usual action would
be that a client running on a full fledged computer
would export the special characters, and a client
running where there are no local defaults (like on
some terminal servers) would import the special characters.
When an SLC command is received, the action taken
should be:
1) Ignore it if it is the same as the current settings.
2) If the SLC_LEVELBITS are the same as the current level bits,
but the value is different and the SLC_ACK bit is set, no
reply is generated. On the server side, the command is
ignored, and on the client side, a switch is made to the
new value. This is so that if a request to change the same
character is generated by both the server and the client,
they will both settle on the clients requested value.
3) If we agree with the new setting, we switch to it and reply
with the same value, but also set the SLC_ACK bit.
4) If we don't agree, we send a response with what we think the
value should be. The SLC_ACK bit is NOT set in this case.
You may only disagree with a value by sending a different
value at a lower level.
If the remote system doesn't support some of the
line editing characters, but the front end does, then
the front end may use the local definitions for those
characters when in line mode. In this case, the server
should send "SLC xxx SLC_DEFAULT 0" in response to
a "SLC 0 SLC_DEFAULT 0" request, and just ack whatever
value the client requests to set the function to.
The SLC_FORW2 character should only be used if SLC_FORW1
is already in use.
5.6 FORWARDMASK and SLC_FORW1 and SLC_FORW2
To help ease the amount of work needed to implement
the client side, two methods of setting forwarding
characters are provided. The SLC_FORW1 and SLC_FORW2
allow for the setting of two additional characters
on which to forward buffered input data. Since many
terminal drivers have the ability to set one or more
line delimiters, it is fairly easy to support these
without having to implement through the local terminal
driver, rather than putting a terminal driver into
Telnet. If the local terminal driver has functionality
that maps easily into the FORWARDMASK, then it can
also be easily supported. If the local terminal driver
does not support that, then it would require more
work to support FORWARDMASK.
Also note that the client side is required to forward
data when it sees one of SLC_FORW1, SLC_FORW2, or
FORWARDMASK characters, or when any normal line termination
or special signal is encountered. The client side
is also free to forward on other characters that it
chooses. For example, if the server side sent a FORWARDMASK
that asked for data to be forwarded on the first 20
control characters (ASCII codes 1 through 024), and
the client side cannot have its local terminal driver
forward on just the first 20 control characters, but
it can have the local terminal driver forward on any
control character (ASCII codes 1 through 039), then
the client side could validly accept the FORWARDMASK,
and forward on any control character. When in EDIT
mode, care should be taken to not forward at random
times, since once that data is forwarded, no more
editing on the forwarded part of the line can be done.
The only time (other than the normal times) that data
should be forwarded when in EDIT mode would be if
a single input line is too long to handle locally.
5.7 Valid and invalid modes and values
At no time should "DO LINEMODE" be negotiated in
both directions of the Telnet connection. The side
that is the "DO LINEMODE" is considered to be the
server side, and the side that is "WILL LINEMODE"
is the client side.
At no time should "SB LINEMODE DO/DONT FORWARDMASK",
be sent unless "DO LINEMODE" has been previously negotiated.
At no time should "SB LINEMODE WILL/WONT FORWARDMASK",
be sent unless "WILL LINEMODE" has been previously
negotiated.
If an ABORT, EOF or SUSP, is received and the system
does not support that functionality, it may just be
ignored.
5.8 Flushing input and output
When an IP, BRK or ABORT is sent, it is usually
desirable to be able to flush the input stream, and
to flush output to the user until the IP, BRK, or
ABORT is processed. The SLC_FLUSHIN and SLC_FLUSHOUT
bits are used to indicate what action should be done.
These bits are advisory only, but should be honored
if possible. The standard method for processing the
SLC_FLUSHIN is to use the Telnet "Synch" signal, and
the SLC_FLUSHOUT is processed using the TIMING-MARK
option. If both are to be sent, the IAC DM is sent
before the DO TIMING-MARK Thus, the sender would send
"IAC XXX IAC DM IAC DO TIMING-MARK", where XXX may
be IP, BRK or ABORT, or any other special character.
The IAC DM is sent as TCP urgent data with the DM
as the last (or only) data octet; this is used to
flush the input stream. The "IAC DO TIMING-MARK" is
used to tell when to stop flushing output; once it
is sent, all data is discarded until an "IAC WILL
TIMING-MARK" or an "IAC WONT TIMING-MARK" is received.
Since the SLC_FLUSHIN and SLC_FLUSHOUT bit are only
advisory, the user interface should provide a method
so that the user can override the sending (or not
sending) of the "Synch" and TIMING-MARK, but the default
action should be to send them according to the SLC_FLUSHIN
and SLC_FLUSHOUT bits.
Whenever an IAC AO is received, a Synch must be
returned. When ever a Synch is being processed, (by
the TCP connection going into Urgent mode), all data
must be discarded (but not Telnet commands!) until
an IAC DM is found, and the connection goes out of
Urgent mode. See RFC 854,
"TELNET PROTOCOL SPECIFICATION", for a complete description
of the Synch signal.
5.9 State diagram for SLC
SPC0 Initial setting for a special character
SPC1 A changed special character < SPC0
SPC-A All current special character settings
VAL SLC_VALUE level
DEF SLC_DEFAULT level
Levels: DEFAULT, VALUE, CANT_CHANGE, NOSUPPORT Flags:
ACK
Receive Response
------- --------
f,SLC_DEFAULT,x f,SLC_VALUE,v
f,SLC_CANTCHANGE,v
f,SLC_NOSUPPORT,x
f,SLC_VALUE,v f,SLC_ACK|SLC_VALUE,v
f,SLC_CANTCHANGE,w
f,SLC_NOSUPPORT,x
f,SLC_CANTCHANGE,v f,SLC_ACK|SLC_CANTCHANGE,v
f,SLC_NOSUPPORT,x
f,SLC_NOSUPPORT,x f,SLC_ACK|SLC_NOSUPPORT,x
x,SLC_ACK|x,x no response
5.10 Examples of a connection
In these examples, the symbolic names are used rather
than the actual values, to make them readable. When
two or more symbolic names are joined by a |, it means
that the actual value will be the logical "or" of
the values of the symbolic names. In the interest
of clarity, for these examples the leading IAC and
IAC SB sequences, and the trailing IAC SE sequences
have been omitted. Also, the SLC_ prefix has been
left off where ever it would normally occur.
CLIENT SERVER
DO TOGGLE-FLOW-CONTROL
DO LINEMODE
WILL TOGGLE-FLOW-CONTROL
WILL LINEMODE
[ Subnegotiation may now proceed in both directions. The client
sends of the list of special characters. ]
LINEMODE SLC SYNCH DEFAULT 0 IP
VALUE|FLUSHIN|FLUSHOUT 3 AO
VALUE 15 AYT DEFAULT 0 ABORT
VALUE|FLUSHIN|FLUSHOUT 28 EOF
VALUE 4 SUSP VALUE|FLUSHIN 26 EC
VALUE 127 EL VALUE 21 EW VALUE
23 RP VALUE 18 LNEXT VALUE 22
XON VALUE 17 XOFF VALUE 19
[ Now that linemode is enabled, the server sets the initial mode,
and acknowledges the special characters. ]
LINEMODE MODE EDIT
LINEMODE SLC SYNCH NOSUPPORT 0 IP VALUE|FLUSHIN|FLUSHOUT|ACK
3
AO NOSUPPORT 0 AYT NOSUPPORT 0 ABORT VALUE|FLUSHIN|FLUSHOUT|ACK
28 EOF VALUE|ACK 4 SUSP NOSUP- PORT 0 EC VALUE|ACK
127 EL VALUE|ACK 21 EW VALUE|ACK 23 RP VALUE|ACK 18
LNEXT VALUE|ACK 22 XON VALUE|ACK 17 XOFF VALUE|ACK
19 [ The client gets the mode and ack of the special
characters, and acks the mode and any special characters
that the server changed. ] LINEMODE MODE EDIT|MODE_ACK
LINEMODE SLC SYNCH NOSUPPORT|ACK 0 AO NOSUPPORT|ACK
0 AYT|ACK NOSUPPORT 0 SUSP NOSUPPORT|ACK 0 "Login:"
"my_account" [ Turn off
echo to the user. ] WILL ECHO DO ECHO "Password:"
"my_password" [ Turn back
on echo to the user. ] WONT ECHO DONT ECHO [,
and then runs an application that wants to use single
character mode, doing its own echoing of characters,
but keep signal trapping on. ] WILL ECHO DO ECHO LINEMODE
MODE TRAPSIG LINEMODE MODE TRAPSIG|MODE_ACK [
Application finishes ] WONT ECHO DONT ECHO LINEMODE
MODE EDIT|TRAPSIG LINEMODE MODE EDIT|TRAPSIG|MODE_ACK
[, that wants full control of everything. ] WILL ECHO
DO ECHO LINEMODE MODE 0 LINEMODE MODE 0|MODE_ACK [
Application finishes ] WONT ECHO DONT ECHO LINEMODE
MODE EDIT|TRAPSIG
LINEMODE MODE EDIT|TRAPSIG|MODE_ACK [
The user changes his erase character to ^H. ]
LINEMODE SLC EC VALUE 8 LINEMODE SLC EC VALUE|ACK
8 [ special characters. ] LINEMODE SLC SYNCH DEFAULT
0 IP VALUE|FLUSHIN|FLUSHOUT 3 AO VALUE 15 AYT DEFAULT
0 ABORT VALUE|FLUSHIN|FLUSHOUT 28 EOF VALUE 4 SUSP
VALUE|FLUSHIN 26 EC VALUE 127 EL VALUE 21 EW VALUE
23 RP VALUE 18 LNEXT VALUE 22 XON VALUE 17 XOFF VALUE
19 LINEMODE SLC SYNCH NOSUPPORT 0 AO NOSUPPORT 15
AYT NOSUPPORT 0 SUSP NOSUPPORT|FLUSHIN 26 EC VALUE|ACK
127 EW VALUE|ACK 23 RP VALUE|ACK 18 LNEXT VALUE|ACK
22 XON VALUE|ACK 17 XOFF VALUE|ACK 19 LINEMODE SLC
SYNCH NOSUPPORT|ACK 0 AO NOSUPPORT|ACK 15 AYT NOSUPPORT|ACK
0 SUSP NOSUPPORT|ACK|FLUSHIN 26 [ characters. ] LINEMODE
SLC 0 DEFAULT 0 LINEMODE SLC IP VALUE|FLUSHIN|FLUSHOUT
3 ABORT VALUE|FLUSHIN|FLUSHOUT 28 EOF VALUE 4 EC VALUE
127 EL VALUE 21 [, no response is generated. ] [ up,
that wanted to let the client side do the echoing
and buffering of characters, but did not want it to
do any line editing, and only forward the data when
got a control character. Note that we have preceded
all the the 0377s in the forward mask with an IAC.
] LINEMODE MODE 0 LINEMODE DO FORWARDMASK IAC 0377
IAC 0377 IAC 0377 IAC 0377 0 0 0 0 0 0 0 0 0 0 0 01
LINEMODE MODE 0 LINEMODE WILL FORWARDMASK [, and then
things are to be set back to what they were before.
] LINEMODE MODE EDIT|TRAPSIG LINEMODE DONT FORWARDMASK
LINEMODE MODE EDIT|TRAPSIG LINEMODE WONT FORWARDMASK
6. Other Telnet options and RFCs
The following is a list of RFCs for various Telnet
options that should be supported along with LINEMODE.
1. Postel, J. and Reynolds, J., "TELNET PROTOCOL SPECIFICATION",
RFC 854, ISI, May 1983.
2. Postel, J. and Reynolds, J., "TELNET OPTION SPECIFICATIONS",
RFC 855, ISI, May 1983.
3. Postel, J. and Reynolds, J., "TELNET BINARY TRANSMISSION",
RFC 856, ISI, May 1983.
4. Postel, J. and Reynolds, J., "TELNET ECHO OPTION", RFC 857,
ISI, May 1983.
5. Postel, J. and Reynolds, J., "TELNET SUPRESS GO AHEAD OPTION",
RFC 858, ISI, May 1983.
6. Postel, J. and Reynolds, J., "TELNET TIMING MARK OPTION",
RFC 860, ISI, May 1983.
7. VanBokkeln, J., "Telnet Terminal-Type Option", RFC 1091,
FTP Software, Inc., February 1989.
8. Waitzman, D., "Telnet Window Size Option", RFC 1073, BBN STC,
October 1988.
9. Hedrick, C., "Telnet Remote Flow Control Option", RFC 1080,
Rutgers University, November, 1988.
10. Hedrick, C., "Telnet Terminal Speed Option", RFC 1079, Rutgers
University, December, 1988.
The following is a list of RFCs that need not be
supported for LINEMODE, but which would enhance any
TELNET implementation.
11. Postel, J. and Reynolds, J., "TELNET STATUS OPTION", RFC 859,
ISI, May 1983.
12. Postel, J. and Reynolds, J., "TELNET END OF RECORD OPTION", RFC 885,
ISI, December 1983.
13. Silverman, S., "OUTPUT MARKING TELNET OPTION", RFC 933,
MITRE-Washington, January 1985.
14. Marcy, G., "Telnet X Display Location Option", RFC 1096,
Carnegie Mellon University, March 1989.
Security Consideratiions
Security issues are not discussed in this memo.
Author's Address
David A. Borman Cray Research Inc. 655F Lone Oak
Drive Eagan, MN 55123
Phone: (612) 452-6650 EMail: dab@CRAY.COM
IETF Telnet WG Mailing List: telnet-ietf@CRAY.COM
Back to the Telnet Protocol
