RFC relevance of connection

As per Relevance of the word connection, we have this rfc below:

Network Working Group J.
Request for Comments: 854 J.

Obsoletes: NIC 18639 May 1983

TELNET PROTOCOL

This RFC specifies a standard for the ARPA Internet community. Hosts
the ARPA Internet are expected to adopt and implement this standard

The purpose of the TELNET Protocol is to provide a fairly general
bi-directional, eight-bit byte oriented communications facility.
primary goal is to allow a standard method of interfacing
devices and terminal-oriented processes to each other. It
envisioned that the protocol may also be used for terminal-
communication ("linking") and process-process
(distributed computation).

GENERAL

A TELNET connection is a Transmission Control Protocol (TCP
connection used to transmit data with interspersed TELNET
information

The TELNET Protocol is built upon three main ideas: first,
concept of a "Network Virtual Terminal"; second, the principle
negotiated options; and third, a symmetric view of terminals
processes

1. When a TELNET connection is first established, each end
assumed to originate and terminate at a "Network Virtual Terminal",
or NVT. An NVT is an imaginary device which provides a standard
network-wide, intermediate representation of a canonical terminal
This eliminates the need for "server" and "user" hosts to
information about the characteristics of each other's terminals
terminal handling conventions. All hosts, both user and server,
their local device characteristics and conventions so as to appear
be dealing with an NVT over the network, and each can assume
similar mapping by the other party. The NVT is intended to strike
balance between being overly restricted (not providing hosts a
enough vocabulary for mapping into their local character sets),
being overly inclusive (penalizing users with modest terminals).

NOTE: The "user" host is the host to which the physical
is normally attached, and the "server" host is the host which
normally providing some service. As an alternate point of view

Postel & Reynolds [Page 1]

RFC 854 May 1983

applicable even in terminal-to-terminal or process-to-
communications, the "user" host is the host which initiated
communication

2. The principle of negotiated options takes cognizance of the
that many hosts will wish to provide additional services over
above those available within an NVT, and many users will
sophisticated terminals and would like to have elegant, rather
minimal, services. Independent of, but structured within the
Protocol are various "options" that will be sanctioned and may
used with the "DO, DON'T, WILL, WON'T" structure (discussed below)
allow a user and server to agree to use a more elaborate (or
just different) set of conventions for their TELNET connection.
options could include changing the character set, the echo mode, etc

The basic strategy for setting up the use of options is to
either party (or both) initiate a request that some option
effect. The other party may then either accept or reject
request. If the request is accepted the option immediately
effect; if it is rejected the associated aspect of the
remains as specified for an NVT. Clearly, a party may always
a request to enable, and must never refuse a request to disable
option since all parties must be prepared to support the NVT

The syntax of option negotiation has been set up so that if
parties request an option simultaneously, each will see the other'
request as the positive acknowledgment of its own

3. The symmetry of the negotiation syntax can potentially lead
nonterminating acknowledgment loops -- each party seeing the
commands not as acknowledgments but as new requests which must
acknowledged. To prevent such loops, the following rules prevail

a. Parties may only request a change in option status; i.e.,
party may not send out a "request" merely to announce what mode
is in

b. If a party receives what appears to be a request to enter
mode it is already in, the request should not be acknowledged
This non-response is essential to prevent endless loops in
negotiation. It is required that a response be sent to
for a change of mode -- even if the mode is not changed

c. Whenever one party sends an option command to a second party
whether as a request or an acknowledgment, and use of the
will have any effect on the processing of the data being sent
the first party to the second, then the command must be
in the data stream at the point where it is desired that it

Postel & Reynolds [Page 2]

RFC 854 May 1983

effect. (It should be noted that some time will elapse
the transmission of a request and the receipt of
acknowledgment, which may be negative. Thus, a host may wish
buffer data, after requesting an option, until it learns
the request is accepted or rejected, in order to hide
"uncertainty period" from the user.)

Option requests are likely to flurry back and forth when a
connection is first established, as each party attempts to get
best possible service from the other party. Beyond that, however
options can be used to dynamically modify the characteristics of
connection to suit changing local conditions. For example, the NVT
as will be explained later, uses a transmission discipline
suited to the many "line at a time" applications such as BASIC,
poorly suited to the many "character at a time" applications such
NLS. A server might elect to devote the extra processor
required for a "character at a time" discipline when it was
for the local process and would negotiate an appropriate option
However, rather than then being permanently burdened with the
processing overhead, it could switch (i.e., negotiate) back to
when the detailed control was no longer necessary

It is possible for requests initiated by processes to stimulate
nonterminating request loop if the process responds to a rejection
merely re-requesting the option. To prevent such loops
occurring, rejected requests should not be repeated until
changes. Operationally, this can mean the process is running
different program, or the user has given another command, or
makes sense in the context of the given process and the given option
A good rule of thumb is that a re-request should only occur as
result of subsequent information from the other end of the
or when demanded by local human intervention

Option designers should not feel constrained by the somewhat
syntax available for option negotiation. The intent of the
syntax is to make it easy to have options -- since it
correspondingly easy to profess ignorance about them. If
particular option requires a richer negotiation structure
possible within "DO, DON'T, WILL, WON'T", the proper tack is to
"DO, DON'T, WILL, WON'T" to establish that both parties
the option, and once this is accomplished a more exotic syntax can
used freely. For example, a party might send a request to
(establish) line length. If it is accepted, then a different
can be used for actually negotiating the line length -- such
"sub-negotiation" might include fields for minimum allowable,
allowable and desired line lengths. The important concept is

Postel & Reynolds [Page 3]

RFC 854 May 1983

such expanded negotiations should never begin until some
(standard) negotiation has established that both parties are
of parsing the expanded syntax

In summary, WILL XXX is sent, by either party, to indicate
party's desire (offer) to begin performing option XXX, DO XXX
DON'T XXX being its positive and negative acknowledgments; similarly
DO XXX is sent to indicate a desire (request) that the other
(i.e., the recipient of the DO) begin performing option XXX, WILL
and WON'T XXX being the positive and negative acknowledgments.
the NVT is what is left when no options are enabled, the DON'T
WON'T responses are guaranteed to leave the connection in a
which both ends can handle. Thus, all hosts may implement
TELNET processes to be totally unaware of options that are
supported, simply returning a rejection to (i.e., refusing)
option request that cannot be understood

As much as possible, the TELNET protocol has been made server-
symmetrical so that it easily and naturally covers the user-
(linking) and server-server (cooperating processes) cases. It
hoped, but not absolutely required, that options will further
intent. In any case, it is explicitly acknowledged that symmetry
an operating principle rather than an ironclad rule

A companion document, "TELNET Option Specifications," should
consulted for information about the procedure for establishing
options

THE NETWORK VIRTUAL

The Network Virtual Terminal (NVT) is a bi-directional
device. The NVT has a printer and a keyboard. The printer
to incoming data and the keyboard produces outgoing data which
sent over the TELNET connection and, if "echoes" are desired, to
NVT's printer as well. "Echoes" will not be expected to traverse
network (although options exist to enable a "remote" echoing mode
operation, no host is required to implement this option). The
set is seven-bit USASCII in an eight-bit field, except as
herein. Any code conversion and timing considerations are
problems and do not affect the NVT

TRANSMISSION OF

Although a TELNET connection through the network is
full duplex, the NVT is to be viewed as a half-duplex
operating in a line-buffered mode. That is, unless and

Postel & Reynolds [Page 4]

RFC 854 May 1983

options are negotiated to the contrary, the following
conditions pertain to the transmission of data over the
connection

1) Insofar as the availability of local buffer space permits
data should be accumulated in the host where it is
until a complete line of data is ready for transmission,
until some locally-defined explicit signal to transmit occurs
This signal could be generated either by a process or by
human user

The motivation for this rule is the high cost, to some hosts
of processing network input interrupts, coupled with
default NVT specification that "echoes" do not traverse
network. Thus, it is reasonable to buffer some amount of
at its source. Many systems take some processing action at
end of each input line (even line printers or card
frequently tend to work this way), so the transmission
be triggered at the end of a line. On the other hand, a
or process may sometimes find it necessary or desirable
provide data which does not terminate at the end of a line
therefore implementers are cautioned to provide methods
locally signaling that all buffered data should be
immediately

2) When a process has completed sending data to an NVT
and has no queued input from the NVT keyboard for
processing (i.e., when a process at one end of a
connection cannot proceed without input from the other end),
the process must transmit the TELNET Go Ahead (GA) command

This rule is not intended to require that the TELNET GA
be sent from a terminal at the end of each line, since
hosts do not normally require a special signal (in addition
end-of-line or other locally-defined characters) in order
commence processing. Rather, the TELNET GA is designed to
a user's local host operate a physically half duplex
which has a "lockable" keyboard such as the IBM 2741.
description of this type of terminal may help to explain
proper use of the GA command

The terminal-computer connection is always under control
either the user or the computer. Neither can
seize control from the other; rather the controlling end
relinguish its control explicitly. At the terminal end,
hardware is constructed so as to relinquish control each
that a "line" is terminated (i.e., when the "New Line" key
typed by the user). When this occurs, the attached (local

Postel & Reynolds [Page 5]

RFC 854 May 1983

computer processes the input data, decides if output should
generated, and if not returns control to the terminal.
output should be generated, control is retained by the
until all output has been transmitted

The difficulties of using this type of terminal through
network should be obvious. The "local" computer is no
able to decide whether to retain control after seeing
end-of-line signal or not; this decision can only be made
the "remote" computer which is processing the data. Therefore
the TELNET GA command provides a mechanism whereby the "remote
(server) computer can signal the "local" (user) computer
it is time to pass control to the user of the terminal.
should be transmitted at those times, and only at those times
when the user should be given control of the terminal.
that premature transmission of the GA command may result in
blocking of output, since the user is likely to assume that
transmitting system has paused, and therefore he will fail
turn the line around manually

The foregoing, of course, does not apply to the user-to-
direction of communication. In this direction, GAs may be sent
any time, but need not ever be sent. Also, if the
connection is being used for process-to-process communication,
need not be sent in either direction. Finally,
terminal-to-terminal communication, GAs may be required
neither, one, or both directions. If a host plans to
terminal-to-terminal communication it is suggested that the
provide the user with a means of manually signaling that it
time for a GA to be sent over the TELNET connection; this
however, is not a requirement on the implementer of a
process

Note that the symmetry of the TELNET model requires that there
an NVT at each end of the TELNET connection, at
conceptually

STANDARD REPRESENTATION OF CONTROL

As stated in the Introduction to this document, the primary
of the TELNET protocol is the provision of a standard
of terminal devices and terminal-oriented processes through
network. Early experiences with this type of interconnection
shown that certain functions are implemented by most servers,
that the methods of invoking these functions differ widely. For
human user who interacts with several server systems,
differences are highly frustrating. TELNET, therefore, defines
standard representation for five of these functions, as

Postel & Reynolds [Page 6]

RFC 854 May 1983

below. These standard representations have standard, but
required, meanings (with the exception that the Interrupt
(IP) function may be required by other protocols which
TELNET); that is, a system which does not provide the function
local users need not provide it to network users and may treat
standard representation for the function as a No-operation.
the other hand, a system which does provide the function to
local user is obliged to provide the same function to a
user who transmits the standard representation for the function

Interrupt Process (IP

Many systems provide a function which suspends, interrupts
aborts, or terminates the operation of a user process.
function is frequently used when a user believes his process
in an unending loop, or when an unwanted process has
inadvertently activated. IP is the standard representation
invoking this function. It should be noted by
that IP may be required by other protocols which use TELNET
and therefore should be implemented if these other
are to be supported

Abort Output (AO

Many systems provide a function which allows a process,
is generating output, to run to completion (or to reach
same stopping point it would reach if running to completion
but without sending the output to the user's terminal
Further, this function typically clears any output
produced but not yet actually printed (or displayed) on
user's terminal. AO is the standard representation
invoking this function. For example, some subsystem
normally accept a user's command, send a long text string
the user's terminal in response, and finally signal
to accept the next command by sending a "prompt"
(preceded by ) to the user's terminal. If the AO
received during the transmission of the text string,
reasonable implementation would be to suppress the remainder
the text string, but transmit the prompt character and
preceding . (This is possibly in distinction to
action which might be taken if an IP were received; the
might cause suppression of the text string and an exit from
subsystem.)

It should be noted, by server systems which provide
function, that there may be buffers external to the system (

Postel & Reynolds [Page 7]

RFC 854 May 1983

the network and the user's local host) which should be cleared
the appropriate way to do this is to transmit the "Synch
signal (described below) to the user system

Are You There (AYT

Many systems provide a function which provides the user
some visible (e.g., printable) evidence that the system
still up and running. This function may be invoked by the
when the system is unexpectedly "silent" for a long time
because of the unanticipated (by the user) length of
computation, an unusually heavy system load, etc. AYT is
standard representation for invoking this function

Erase Character (EC

Many systems provide a function which deletes the
preceding undeleted character or "print position"* from
stream of data being supplied by the user. This function
typically used to edit keyboard input when typing mistakes
made. EC is the standard representation for invoking
function

*NOTE: A "print position" may contain several
which are the result of overstrikes, or of sequences such
BS ...

Erase Line (EL

Many systems provide a function which deletes all the data
the current "line" of input. This function is typically
to edit keyboard input. EL is the standard representation
invoking this function

THE TELNET "SYNCH"

Most time-sharing systems provide mechanisms which allow
terminal user to regain control of a "runaway" process; the IP
AO functions described above are examples of these mechanisms
Such systems, when used locally, have access to all of the
supplied by the user, whether these are normal characters
special "out of band" signals such as those supplied by
teletype "BREAK" key or the IBM 2741 "ATTN" key. This is
necessarily true when terminals are connected to the
through the network; the network's flow control mechanisms
cause such a signal to be buffered elsewhere, for example in
user's host

Postel & Reynolds [Page 8]

RFC 854 May 1983

To counter this problem, the TELNET "Synch" mechanism
introduced. A Synch signal consists of a TCP Urgent notification
coupled with the TELNET command DATA MARK. The
notification, which is not subject to the flow control
to the TELNET connection, is used to invoke special handling
the data stream by the process which receives it. In this mode
the data stream is immediately scanned for "interesting"
as defined below, discarding intervening data. The TELNET
DATA MARK (DM) is the synchronizing mark in the data stream
indicates that any special signal has already occurred and
recipient can return to normal processing of the data stream

The Synch is sent via the TCP send operation with the
flag set and the DM as the last (or only) data octet

When several Synchs are sent in rapid succession, the
notifications may be merged. It is not possible to count
since the number received will be less than or equal the
sent. When in normal mode, a DM is a no operation; when in
mode, it signals the end of the urgent processing

If TCP indicates the end of Urgent data before the DM is found
TELNET should continue the special handling of the data
until the DM is found

If TCP indicates more Urgent data after the DM is found, it
only be because of a subsequent Synch. TELNET should
the special handling of the data stream until another DM
found

"Interesting" signals are defined to be: the TELNET
representations of IP, AO, and AYT (but not EC or EL); the
analogs of these standard representations (if any); all
TELNET commands; other site-defined signals which can be acted
without delaying the scan of the data stream

Since one effect of the SYNCH mechanism is the discarding
essentially all characters (except TELNET commands) between
sender of the Synch and its recipient, this mechanism is
as the standard way to clear the data path when that is desired
For example, if a user at a terminal causes an AO to
transmitted, the server which receives the AO (if it provides
function at all) should return a Synch to the user

Finally, just as the TCP Urgent notification is needed at
TELNET level as an out-of-band signal, so other protocols
make use of TELNET may require a TELNET command which can
viewed as an out-of-band signal at a different level

Postel & Reynolds [Page 9]

RFC 854 May 1983

By convention the sequence [IP, Synch] is to be used as such
signal. For example, suppose that some other protocol, which
TELNET, defines the character string STOP analogously to
TELNET command AO. Imagine that a user of this protocol wishes
server to process the STOP string, but the connection is
because the server is processing other commands. The user
instruct his system to

1. Send the TELNET IP character

2. Send the TELNET SYNC sequence, that is

Send the Data Mark (DM) as the only
in a TCP urgent mode send operation

3. Send the character string STOP;

4. Send the other protocol's analog of the TELNET DM, if any

The user (or process acting on his behalf) must transmit
TELNET SYNCH sequence of step 2 above to ensure that the TELNET
gets through to the server's TELNET interpreter

The Urgent should wake up the TELNET process; the IP
wake up the next higher level process

THE NVT PRINTER AND

The NVT printer has an unspecified carriage width and page
and can produce representations of all 95 USASCII graphics (
32 through 126). Of the 33 USASCII control codes (0 through 31
and 127), and the 128 uncovered codes (128 through 255),
following have specified meaning to the NVT printer

NAME CODE

NULL (NUL) 0 No
Line Feed (LF) 10 Moves the printer to
next print line, keeping
same horizontal position
Carriage Return (CR) 13 Moves the printer to the
margin of the current line

Postel & Reynolds [Page 10]

RFC 854 May 1983

In addition, the following codes shall have defined, but
required, effects on the NVT printer. Neither end of a
connection may assume that the other party will take, or
have taken, any particular action upon receipt or
of these

BELL (BEL) 7 Produces an audible
visible signal (which
NOT move the print head).
Back Space (BS) 8 Moves the print head
character position
the left margin
Horizontal Tab (HT) 9 Moves the printer to
next horizontal tab stop
It remains unspecified
either party determines
establishes where such
stops are located
Vertical Tab (VT) 11 Moves the printer to
next vertical tab stop.
remains unspecified
either party determines
establishes where such
stops are located
Form Feed (FF) 12 Moves the printer to the
of the next page,
the same horizontal position

All remaining codes do not cause the NVT printer to take
action

The sequence "CR LF", as defined, will cause the NVT to
positioned at the left margin of the next print line (as would
for example, the sequence "LF CR"). However, many systems
terminals do not treat CR and LF independently, and will have
go to some effort to simulate their effect. (For example,
terminals do not have a CR independent of the LF, but on
terminals it may be possible to simulate a CR by backspacing.)
Therefore, the sequence "CR LF" must be treated as a single "
line" character and used whenever their combined action
intended; the sequence "CR NUL" must be used where a
return alone is actually desired; and the CR character must
avoided in other contexts. This rule gives assurance to
which must decide whether to perform a "new line" function or
multiple-backspace that the TELNET stream contains a
following a CR that will allow a rational decision

Note that "CR LF" or "CR NUL" is required in both

Postel & Reynolds [Page 11]

RFC 854 May 1983

(in the default ASCII mode), to preserve the symmetry of
NVT model. Even though it may be known in some
(e.g., with remote echo and suppress go ahead options
effect) that characters are not being sent to an
printer, nonetheless, for the sake of consistency, the
requires that a NUL be inserted following a CR not followed
a LF in the data stream. The converse of this is that a
received in the data stream after a CR (in the absence
options negotiations which explicitly specify otherwise)
be stripped out prior to applying the NVT to local
set mapping

The NVT keyboard has keys, or key combinations, or key sequences
for generating all 128 USASCII codes. Note that although
have no effect on the NVT printer, the NVT keyboard is capable
generating them

In addition to these codes, the NVT keyboard shall be capable
generating the following additional codes which, except as noted
have defined, but not reguired, meanings. The actual
assignments for these "characters" are in the TELNET
section, because they are viewed as being, in some sense,
and should be available even when the data stream is
as being some other character set

This key allows the user to clear his data path to the
party. The activation of this key causes a DM (see
section) to be sent in the data stream and a TCP
notification is associated with it. The pair DM-Urgent is
have required meaning as defined previously

Break (BRK

This code is provided because it is a signal outside
USASCII set which is currently given local meaning within
systems. It is intended to indicate that the Break Key or
Attention Key was hit. Note, however, that this is intended
provide a 129th code for systems which require it, not as
synonym for the IP standard representation

Interrupt Process (IP

Suspend, interrupt, abort or terminate the process to which
NVT is connected. Also, part of the out-of-band signal
other protocols which use TELNET

Postel & Reynolds [Page 12]

RFC 854 May 1983

Abort Output (AO

Allow the current process to (appear to) run to completion,
do not send its output to the user. Also, send a Synch to
user

Are You There (AYT

Send back to the NVT some visible (i.e., printable)
that the AYT was received

Erase Character (EC

The recipient should delete the last preceding
character or "print position" from the data stream

Erase Line (EL

The recipient should delete characters from the data
back to, but not including, the last "CR LF" sequence sent
the TELNET connection

The spirit of these "extra" keys, and also the printer
effectors, is that they should represent a natural extension
the mapping that already must be done from "NVT" into "local".
Just as the NVT data byte 68 (104 octal) should be mapped
whatever the local code for "uppercase D" is, so the EC
should be mapped into whatever the local "Erase Character
function is. Further, just as the mapping for 124 (174 octal)
somewhat arbitrary in an environment that has no "vertical bar
character, the EL character may have a somewhat arbitrary
(or none at all) if there is no local "Erase Line" facility
Similarly for format effectors: if the terminal actually
have a "Vertical Tab", then the mapping for VT is obvious,
only when the terminal does not have a vertical tab should
effect of VT be unpredictable

TELNET COMMAND

All TELNET commands consist of at least a two byte sequence:
"Interpret as Command" (IAC) escape character followed by the
for the command. The commands dealing with option negotiation
three byte sequences, the third byte being the code for the
referenced. This format was chosen so that as more comprehensive
of the "data space" is made -- by negotiations from the basic NVT,
course -- collisions of data bytes with reserved command values
be minimized, all such collisions requiring the inconvenience,

Postel & Reynolds [Page 13]

RFC 854 May 1983

inefficiency, of "escaping" the data bytes into the stream. With
current set-up, only the IAC need be doubled to be sent as data,
the other 255 codes may be passed transparently

The following are the defined TELNET commands. Note that these
and code sequences have the indicated meaning only when
preceded by an IAC

NAME CODE

SE 240 End of subnegotiation parameters
NOP 241 No operation
Data Mark 242 The data stream portion of a Synch
This should always be
by a TCP Urgent notification
Break 243 NVT character BRK
Interrupt Process 244 The function IP
Abort output 245 The function AO
Are You There 246 The function AYT
Erase character 247 The function EC
Erase Line 248 The function EL
Go ahead 249 The GA signal
SB 250 Indicates that what follows
subnegotiation of the
option
WILL (option code) 251 Indicates the desire to
performing, or confirmation
you are now performing,
indicated option
WON'T (option code) 252 Indicates the refusal to perform
or continue performing,
indicated option
DO (option code) 253 Indicates the request that
other party perform,
confirmation that you are
the other party to perform,
indicated option
DON'T (option code) 254 Indicates the demand that
other party stop performing
or confirmation that you are
longer expecting the other
to perform, the indicated option
IAC 255 Data Byte 255.

Postel & Reynolds [Page 14]

RFC 854 May 1983

CONNECTION

The TELNET TCP connection is established between the user's port
and the server's port L. The server listens on its well known port
for such connections. Since a TCP connection is full duplex
identified by the pair of ports, the server can engage in
simultaneous connections involving its port L and different
ports U

Port

When used for remote user access to service hosts (i.e.,
terminal access) this protocol is assigned server port 23
(27 octal). That is L=23.

Postel & Reynolds [Page 15]

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