Downloaded from http://www.everyspec.

com

MIL-S7D t 782

10 MAY 1984

MILITARYSTANDARD

TELNET PROTOCOL

.,
~m
, .
o“
●

47. .4*
?3.
I
..+=-’&!??
: ‘/

I /
NO DELIVERABLE OATA

I REQUIRED BY THIS DOCUMENT

IPscm’tcms
 Downloaded from http://www.everyspec.com

..
.. ... .

MI L-SID-1782
10 my 1984

DEPARTMENT OF OEFENSE
WASHINGTON, D. C. 20301

TELNET Protocol

hiIL-STO-l 782

Ihls Mil { tary Stindard fs approved for use by al 1 Oepa;tments and

A&cies of the Department of Defense.

2. 8eneficial ccasnents (recowwdations, addl tfons, deletions ) and any

pertinent data which may be of use in improving this document should be
addressed to: Defense Camuunications Agency, AlTN: J1 10, 1860 Wiehle AYenue,
Reston, Virginia 22090, by using the self-addressed Standardization Document
Improvement Proposal (DO Form 1426 ) appearing at the end of this document, or
by 1etter.

- 3. 8ecause of the rapid development in this standardization area, an

alternative method of communication is offered. Fotward responses usin9 the
kiILNET to OCA-IAS Q OCA-D4S. Cooperation of the user is importint to make
this protocol meet Oepartme nt of Defense needs.

ii
 Downloaded from http://www.everyspec.com

FtIL-SID-178Z
.. 10 my 1984

PoREubxD

Thi6 document specifies the TELNF.Tprotocol and a number of approved options. .

It provides a etandard method of interfacing terminal devices and terminal-
orienced proceaaea to ench other. It ia enviaiomed that the protocol may also
be used for terminal-teminal cennaunicetion (-lioking-) and process-procees
cemmunfcatfon (distributed computation).

i.

I
I iii
 Downloaded from http://www.everyspec.com

..
MIL~STO-1 782
10 my 1984

CONTENTS

Paragraph 1. SCUPE--------- ----- ----- ---

1.1 Purpose- - - - - - - ----- ----- ---
Organization ‘- - - - ----- ----- ---
;:: Application- - - - - ----- ----- ---

2. REFERENCED 00CU4ENTS - ----- ----- ---

2.1 Issues of documents- ----- ----- ---
2.2 Other publications - ------ ------ -

3. DEFINITIONS- - - - - - ----- ----- ---

4. GENERAL REQUIREMENTS - ----- ----- ---

4.1 Introduction - - - - ----- ----- ---
General considerations - - - - - - - - - - - -
::;.1 Network virtual terminal (NVT) - - - - - - - -
4.2.2 Principle of negotiated options- - - - - - - -
4.2.3 Synznetry of the negotiation syntax - - - - - -

I 4.2.4
4.2.5
Use of options
Synopsis -------------
The network virtual
---------

terminal
-------
------
- - - - - - - - -
:::.1 Transmission of data - - - - - - - - - - - - -
I 4.3.1.1 Accumulation of data ------ -------
4.3.1.2 TELNET W Phead (GA) comnand - - - - - - - - -
4.3.2 Transmission cautton - - - - - - - - - - - - -
4.4 Standard representat {on of control functions -
4.4.1 Interrupt process (1P) - - - - - - - - - - - -
4.4.2 Abort output (AO)---------- -----
4.4.3 Areyouthere (ACT) --------- -----
4.4.4 Erase character (EC) - - - - - - - - - - - - -
4.4.5 Erase line (EL) ------------ ----
4.5 The TELNET Synch signal- - - - - - - - - - - -
4.5.1 Sending several Wnchs - - - - - - - - - - - -
4.5.2 Interesting signals- - - - - - - - - - - - - -
4.5.3 we effect of the Synch mechanism- - - - - - -
4.5.4 TELNET comnand requirement - - - - - - - - - -
4.6 The NVT printer and keyboard - - - - - - - - -
4.6.1 NVT printer codes -------- -------
4.6.1.1 Example of code use-------- ------
4.6.1.2 ASCII code generation- - - - - - - - - - - - -
4.6.1.3 OAditional codes ------- --------
4.6.1 .3.1 Synch ---------------- -----
4.6.1 .3.2 8reak(8RK)------------- -----
4.6.1 .3.3 / Interrupt process (1P) -- --- - --- ---
4.6.1 .3.4 4bort output (AO)---------- -----
4.6.1 .3.5 Areyouthere (ACT) --------- -----
4.6.1 .3.6 Erase character (EC) -- - - - - - - - - - - -
4.6.1 .3.7 Erase line (EL) ----------- -----
4.6.1 .3.8 Intent of additional codes - - - - - - - - - -
..
iv
 Downloaded from http://www.everyspec.com

III L-31 U-l/UL

10 may 1984

CONTENTS - Continued

Paragraph 4.7 TELNET comnand structure -- ----- ---- 13

4.7.1 TELNET comnands defined- .- ----- ---- 13
4.8 Connection establishment .- ----- ----
Port assignment- - - - - -- ----- ---- ;:
I 4.8.1

APPENDICES

Appendix A. TELNET BINPRY TRANSf41SS10N -- ----- ---- 15

Ccannand name and code- - .- ----- ----
2.
20.1
Cbmnand meanings - - - - - - -----
IAC MILL TRANSMIT - BINPRY - -----
----
----
!;
15
20.2 IAC UON’T TRANSMIT - BINARY- ----- ---- 15
20.3 IAC 00 TRANSMIT - BINARY - - ----- ----
20.4 IAC 00N’T TRANSMIT - BINARY- ----- ---- ;;
30. Wfault ----------- ----- ----
40. Wivation for the oPtion- - ----- ---- ;:
50. Description of the option- - ----- ---- 16
60. Implementation suggestions - ----- ---- 16
70. Binary transmission mode - - ----- ---- 17
70.1 Binary transmission from a terminal- - - - - - 17
70.2 Binary transmission to a Process - - - - - - - 17
70.3 Binary transmission from a Process - - - - - - 17
70.4 Binary transmission to a terminal- - - - - - - 17
Appendix B. TELNETEC~ OPTION-----V-- ‘------~j
10. Consnand name and code ------- ------
20. Gmrnandmeaging s-------- -------l B
20.1 IACUILL ECKI ----------- ------lB
26.2 IACUON’T ECHO ---------- ------lB
20.3 IACOOECM3------------- -----18
20.4 IACOON’T ECHO ---------- ------~8
30. Default ------------- -------18
40. Wtivation for the option- - - - - - - - - - - lB
Description of the option- - - - - - - - - - - 19
%: Implementation of the oPtion - - - - - - - - - 20
60.1 A sample implementation of the option- - - - - 20
Appendix c. TELNET SUPPRESS 133 AHEAfJ OPTION- - - - - - - -- 22
Ccmsnand name and code ------ -------22
::: Ccmnandmeanings --------- ------22
20.1 IAC HILL SUPPRESS-TO-AHEAQ - - - - - - - - - - 22
20.2 lAC WON’T SUPPRESS-GO-AHEAO- - - - -- - - - - 22
20.3 IAC 00 SUPPRESS-60-AHW - - - - - - - - - - - 22
20.4 IAC 00N’T SUPPRESS-60 -AHEAO- - - - - - - - - - 22
30. Default -------------- ------22
40. ~tivation for the option- - - - - - - - - - - 22
50. Description of the option- - - - - - - - - - - 22
60. hnpl,ementation considerations- - - - - - - - - 23
v
 Downloaded from http://www.everyspec.com

MI L-STO-1 782
10 t%ly 1984

CONTENTS - Contfnued

~
Appendix o. TELNETSTATLIS OPTION ------- -------24
10. Command name and code ------ -------24
Cmnand meanings - ----- ----- ---- 24
% 1 IAC MILL STATUS - ----- ----- ---- 24
20.2 IAC MON’ T STATUS - ----- ----- ---- 24
20.3 IAC 00 STATUS- - - . ---- ----- ---- 24
20.4 IAC OON’ T STATUS - ----- ----- .- 24
20.5 IAC S8 STATUS SENO iA; SE-----------24
20.6 IAC S8 STATUS IS... IAC SE-----------24
30. Default -------------- ------24
40. Motivation for the octfon- - - - - - - - - - - 24
Oescrlption of the option- - - - - - - - - - - 24
Appendix ?“ TELNET TIMING MARK OPTION- - - - - - - -- - - - 25
10. Command name and code- ;----- ------25
20. Command meanings -------- ------- 25
20.1 IACHILL TIMING-MPRK-------- ----- 25
20.2 IAC WON’T TIMING-MARK- - - - - - - - - - - - - 25
20.3 IACOO TIMING-MARK --------- ----- 25
20.4 IACOON’T TIMING-W.RK------- ----- 25
Default ------------- ------ 25
::: Motivation for the option - - - - - - - - - - 25
Examples of option application- - - - - - - - 25
%: CX?scription of the option - - - - - - - - - -
70. Three typical applications- - - - - - - - - -- :?
70.1 Round-trip delay --------- ------ 27
70.2 Resynchronization - - - - - - - - - - - - - - 27
70.3 Oual resynchronization- - - - - - - - - - - - 27
Appendix F. TELNET EXTENDEO OPTIONS - LIST OPTION - - - - - 28
10. Command name and code ------ ------ 28
20. Consnand meanings -------- ------- 28
20.1 IACWILL EXOPL----------- ----- 28
20.2 lACHON’T EXOPL ----------- ----- 28
20.3 IACOOEXOPL ------------ ----- 28
20.4 IACOON’T EXOPL --------- ------ 28
20.5 IAC S8 EXOPL subccasnandl - - - - - - - - - - 28
30. Default -------------- ..--- 28
I 40. !!otivation for the option - - - - - - - - - - 28
I 50. Description of the option - - - - - - - - - - 28

vi
 Downloaded from http://www.everyspec.com

I
141
L-STO-1782
.. 10 May 1984

i
FIGORSS

Figure 1 Five reaaoneble modes of operation for

echoing on a connection pair - - - - - - - - - 19
2 Synchronization of proceeees- - - - - - - - - - 26

vii
 Downloaded from http://www.everyspec.com

MI L-STD-1782
10 May 1984

1. SCOPE

l.1 Purpose. This standard establ fshes criteria for the TELNET Protocol
tiich supports the standard method of Interfacing terminal devices and
terminal -oriented processes to each other.

This standard introduces the TELNET Protocols role,

de;;;es%#%&; provided to users, and specifies the mechanisms needed to
support those services. This standard also includes an appendix of options
which can be implemented in the . TELNET Protocol and a glossary of terms and
abbreviations.

1.3 Apy;i~tion. This TELNET Protocol is approved for use in al 1 000

packet sw c ng networks which connect or have the potential for uti 1 i zing
connectivity across network and subnetwork boundaries and which require a
virtual terminal service. The term network as used herein includes Local Area
Networks.
 Downloaded from http://www.everyspec.com

MI L-STO-1782
10 May 1984
..
. .. ..
2. REFERENCED DOCWiENTS

2.1 Issues of documents. The fol lowing documents of the issue in effect on
date of i nvitation for ds or reauest for. prooosal. form a part of th~s
standard to the extent specified herein.

STANDPRDS
FEDERAL
FED-STO-1O37 . Glossary of Telecommunications Terms

141L1TARY
MIL-STD-1778 Transnd sslon Control Protocol

2.2 Other publications. The following documents form a part of .thts

standard to t he extent spectfted herein. U’tless othetwi se indicated, the
issue in effect on date of invitation for bids or request for proposal shal 1
aPPIY. (The Provisions of thts ParagraPh are under consideration. )

2
 Downloaded from http://www.everyspec.com

MIL-STD-1782
10 May 1984

1...-.
.:.. 3. DEFINITIONS

3.1 Ckflnltion of terms. The definition of terms used in this standard

shall comply with ~037. Terms and definitions unique to MIL-STO-1782
are contained herein. - (;e provisions of this paragraph are under
consideration. )

3.2 Definitions of acronym used in this standard. ne following acronyms

used in this tary tandard are defined as follows: .

a. M- Abort Output Cotnnand

b. AYT - Are You There Consnand
c. Bs - Back Space
d. CR- Carriage Return
e. 00N - Oef ense Data Network
f.oN - Oata Mark
g. ~D - Deparbnent of Oefense
h. 00011s - 000 Intel 1Igence Inf omuition System
Erase Character Ckannand
:: :: : Erase Line Cctnnand
k. FF - FormI Feed
Go-Ahead Ccasnand
;::: Nori iontal Tab
n. IAC - Interpret As Cunnand
0. IBM - International 8usiness Machines, Inc.
P. Ip - Interrupt Process Cansnand
Q. LF - Line Feed
r. NVT - Network Virtual Terminal
s. TCP - Transmission Control Protocol
t. TELNET - Teleconsnunications Network
u.vT - Vertical Tab
V. ASCII - Anerican Standard tide for Information Interchange

3
 Downloaded from http://www.everyspec.com

MIL-STD-1782
10 May 1984

4. GENERAL REQUIREMENTS

4.1 Introduction. The purpose of the TELNET Protocol is to provide a

fairly general, bidirectional, eight-bit byte oriented conznunications
facility. Its primary goal is to allow a standard method of interfacing
terminal devices and terminal -oriented processes to each other. It is
envisioned that the protocol may also be used for terminal-terminal
cornnuni -cation (’1 inking”) and process-Process comnunicatfon (distributed
computation). The Appendt ces to this volume contain OOD approved and
supported TELWT opttons. It is reconznended, but not mandatory, that these
opt ions be impl e-merited as useful adjuncts to the TELNET protocol. If
implemented, they are required to be Implemented as published herein.

4.2 6eneral considerations. A TELNET connection is a Transmission Control

Protoco~) connect ion used to transmit data with interspersed TELNET
control information. The TELNET Protocol is built upon three main ideas:
f Irst, the concept of a Network Virtual Terminal; second, the principle of
negotiated options; and third, a symnetrlc view of terminals and processes.
1
I 4.2.1 Network Virtual Terminal (NVT~. tihen a TELNET Connection fs fiMt
established , each end 1s assumed to orl g{nate and terminate at a Network
Virtual Terminal (NVT). PJS 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 keep information
about the character st ics of each other’s terminals and terminal handling
conventions. Al 1 hosts, both user and server, map their local device
characteristics and conventions so as to appear to be dealing wf th an NVT over
the network, and each can assume a simi 1ar mapping by the other party. The
NVT is intended to strfke a balance between being overly restricted (not
providing hosts a rich enough vocabulary for mapping f nto their local
character sets ), and being overly inclusive (penal i zing users with modest
terminals). The ‘user” host is the host to which the physical terminal is
normal ly attached, and the “server- host is the host which is normally
providing some service. As an alternate pofnt of view, applicable even in
terminal -to-terminal or process-to-process comnunicat Ions, the “user” host is
I the host which fnitiated the conwwnication;

4.2.2 Prtnclple of negotiated options. The principle of negotiated options

takes cognizance of he fact hat many hosts will wish to provide additional
services over and above those avai 1able WI thin an NVT, and many users wi 11
have sophisticated termfnals and would 1fke to have elegant, rather than
minl+nal, services. Independent of, but structured w~thin the TELNET Protocol
are various ‘opt Ions ● that wf 11 be sanctioned and may be used with the ’00,
00N’.T, UILL, UON’ T“ structure (discussed below) to allow a user and server to
agree to use a more elaborate (or perhaps just different) set of conventions
for their TELNET connection. Such options could include changing the
character set, the echo mode, etc. The basic strategy for setting up the use
of options is to have either party (or both) Initiate a request that some
option take effect. The other party may then either accept or reject the
request. If the request is accepted the option immediately takes ef feet; if
it is rejected the associated aspect of the connection remains as specified
for an NVT. Clearly, a party may always refuse a request to enable, and must
never refuse

4
 Downloaded from http://www.everyspec.com

fiIL-SID-17S2
10 my 198L

a request to disable soue option since all pnrtiea mat be prepared to support
the WT. The eyntax of option negotiation hae been set up eo chat if both
parriee request an option .vimultaneoualy,each will see the other’s requeet
as the positive acknowledgment of its own.

4.2.3 Symmetry of the ne~otiation aywtax. 2’heeymmetKY of the negotiation

sywtax can potentially lead to nonterminetimg acknowledgment looPs — each
party seeing the incomlog commends not as ncknwledgments but aa new requests
which nust be acknowledged. To prevent such lonpa, the following rulee
prevail:

I e. Parties may only requeet a chaage in option atatua; 1.e. , a party

may not send out a ‘requeet” merely to amounce what mode it is
in.

b. If a party receives what appeare to be a request to enter some

tide it is already in, the request should not be acknowledged.
This nnn-reaponae ia eesentiel to prevent emfleaa 100pa in the
ne~otiation. It la required that a reepnnee be sent to requeete
for a change of mode - ‘evenif the mode ie not changed.

c. Whenever one party aenda an option ctrmnandto a second parqf,

whether aa a request or an acknowledgment, awl uae of the option
will have any effect on the proceealag of the data being sent
frcm the first party to the accord, then the canmard must be
iaaerred in the data stream at the pnint where it ia deeired
that it take effect. Snme time will elapae between the Crana-
miaaion of a requeet and the receipc of an acknowledgment,
vhich may be negative. Thus, a Imst may wish to buffer data,
after requesting an option, until it learae whether the requeet
la accepted or rejected, in order to hide the ‘uncertainty
period- from the user.

4.2.4 Use of options. Option requeata are Zikely to flurry back and
forth when a TSLNET connection ia firat estab21ahed, aa each party attempte
co get the beat poaaible servica frem the other party. Beyord that, hnwever,
optioae can be used to dynamically umdify the characteriatice of the comec-
cion to suit chawging local condition. For example, the NW, as till be
expLeined later, uses a tranemiaaion discipline well suited to the many
‘lina at a time- applicatioaa such aa BASIC, but poorly aulted to the many
“characterat e time- applicetlone such ae NLS. A server tnfghtelect to
devete the extra proceaaor everhead required for a “character at a tiaw-
discip2ine when it was suitable for the local proceaa aad wnuld negotiate
an.apprwpriete option. Rwever.,,rather than then being permanently burdened
with the extra proceaaing overhead, it could twitch (i.e., negotiate) beck
to NVT when the detailed control waa no longer neceaaary. It ia poaaib2e for
requeata initiated by proceaaee to atlmulate a nonterudnetiag requeac loop
if the proceaa reapomla to a rejection by merely re-requesting the wption.
To prevent such 100ps from occurfl”g, rejected requaeta ahnuld nnt be repeated
until sonx?tMng changea. Operationally, this can mean the proceaa is running
a different program, or the user haa given another ccrmmcnd,or whatever
makea aenee in the context of the given proceaa and the given eption. A

5.
i
 Downloaded from http://www.everyspec.com

HIL-STD-1782
10 Nay 1984
.. ......
goed rule ef thumb is that a re-request etmuld only occur ee a reeult ef .-
subeaquent infornmtion from the other ewl ef the connection or when demanded
by local human intervention. Option &elgnera atmuld not feel cenetrained by
the somevhat limlted syatax availabk for option negotiation. The intent of
the 8*1. eynt8x ie te make it eeey to hnve eptinna — since it is cOrre-
spnadingly eaey to profess l~orance about them. If so- particular eption
requiree a richer negotiation structure than possible within ‘DO, DONIT,
WILL, WON’T-. the proper tack ia to uae TO. DON’T, WILL, WN’T- to eetablieh
that both partiee uederetaml the eptlon, and once tMs is acccmpLlebed a
uure exotic syntax can be used freely. For example, a party might send a
request te el”ter(establish) line length. If it is accepted, then a different
symtax an he used for actually negotiating the line length — such a ‘aub-
negotiation- might inclu& fie.ldefor minimum allovebla, nmximum all~ble
and desired line lengths. The important cnncept is that euch expaoded nego_
tiatinma shmld never Lx@n until mme prior (standard) negotiation hea
established that both partiee are capable of paraing,the expanded syntax.

6.2.5 SynePaia. In tttumm9ry, WILL XXX ia cent, by either perry, to indicate

that party’e deeire (offer) te begin perforndng option XXX, DO XXX and rnN’T
XXX being ita positive awl negative acknewledguante; dmilarly, DO XX8 is
sent to indicate a desire (request) that the other party (i.e., the racipient
of the DO) begin performing eption XXX, WILL XXX and WON’T XXX being the
peaitive and ne~tlve ackeowledg~nta. Since the NVT ia *“C is left when
no optione are enabled, the DON’T and WON’T reapnmees are gunrenteed to
&am? the connection in a st.etewhich both ends can handle. Thus, all hneta
my implement their TFJ.NETproceaaea to te totally mmware of optione that
are not aupperted, simply returnieg a rejeccion to (i.e., refuaiag) any
eption request that anner be understood. AB much aa possible, the TSLNET
protncol has been ma& eerveruaer eymaetricel en that it easily amd naturally
cevera the user-uear (linking) ad sewer-server (cooperating procesaea)
cases. It 1s hoped, but not absolutely required, that options will further
this intent. In any case, it is explicitly acknowledged that eymuetry la an
operating principle rather than an ironclad rule. Standard TSLNST optioee
referencedin thie docum?nt are contained in Appendices A-F.

4.3 The Netverk Virtual Terminal. The Network Virtual Termtnal (NVT) iB
a bl-directionalcharacter &vice. The NVT hae a printer aad a keybnard.
The printer ?espenda to incemleg data and the kaybnard producee outgoing
data which is sent ever the =NE7 confection ad, if ‘ecboea- are deairef,
to the NVT’s printer as well. %cMee” will not be expected to craverae the
network (altfmugh nptione exist te enable a ‘remote- echoiag UUde of operw
tion, no heat is required te implamsnt tMa nption). The code aat i.eeever
Mc OSASCII in an eight-bit field, except ae mdified herein. Aay cede
conversion and timing coaeideratione are local probleme and do not effect
the NvT.

4.3.1 Traeamisaion of data. Altlmugh a ~NST comection through the

network ie intrinaicelly full duplex, the NVT ia to be viewed e. a balf+uplex
device eperating in a Ltn=bufferfrf mode. That is, unlasa and until optione
are negotiated tn the contrary, the following default conditione perteln to
the tranemisaionof data over the TSLNET comection:
 Downloaded from http://www.everyspec.com

flIL-STO-1782
10 hy 1984
.

4.3.1.1 Accumulation of data. Insofar ee the availability of local buffer

space permits, data should be accumulated in the host where it is generated
until a cemplete line of data ie reedy for transmission, or until some locelly-
defined emlitit si~al to transmit occurs. This signal could be generated
either by a process or by a humeriuser. The mtivation for this rule la the
high met, to some heats, of processing network Input interrupts, ccupled
with the default NVT spetifimtion thet ‘echeea- do not traverae the ne~ork.
,,. . Thus, it ,ia reasonable to buffer aonteameunt of data at ite source. Neoy
system take some processing ection at the end of each input line (even Mae
printers or cerd pundtes frcqueatly tend to work this way), ao the transmis-
sion should be.triggered at the end of a line.. On the other hand, a user or
process MY eomati=s find it necessary or desirable to provide data which
does not terminate at the ead of a line; therefore implementers are castioaed
to provide metl?x!e of locally signcling that all buffered deta skuld be
transmitted immediately.

4.3.1.2 TELNBT Go Ahead (GA) c-rid. When a process has completed semd-
ing dete to an NVT printer end has no queued input from the NVf keybard for
further proceaaing (i. e., when a process at one eod of a TKLNET coomection
csnnot preceed without input from the other emd). the Proc=s must tranesdt
the TELNRT GM Ahead (M) canmend. This rule ie not intended to require tbet
the TYJ.MH W cwmxand be sent from e terminal at the end of each line, since
server bests do not normally require a epecial signel (in eddition to emd-of-
line or other loce.lly+efined charectere) in order to cnmmence proceet+ing.
Rather, the TELN2T OA la designed to help a user’s locel host operate a
physically half duplex terminal which has a ‘lockable- keyboard such aa the
IBN 2741. A deacripcion of tMs type of terminal may help to explain the
proper uae of the M cemmand. The terminal-temputer connection la always
under control of either the user or the computer. Neither can unilaterally
seize control from the other: rather the controlling end must relinquish Itc
control explicitly. At the terminel end, the hardware is constructed eo ae
tn relinquish control each time that e ‘line” ie terminated (i.e., when the
‘Nw Line- key is typed by the user). When this occurs, the attached (local)
cmuter Proceeses the inwt data, decides if output should be generated,
and if not returns control to the terminal. If output almuld be generated,
control la retained by the cemputer until all output has been transmitted.
I The difficultiesof usisg this type of terminel thrsugh the netwo~ almuld
be obvieus. The ‘local- cemputer la no longer able to decide whether to
I retain control efter seeing an end-of-line signal or not; this decision can
only”be me& by the “remote- computer WiIIchis processing the data. There-
fore, the T2LN8T GA canamrd previdea a mechanism whereby the ‘remote- (server)
cemputer ten signal the ‘10C81- (user) computer that it is tirs?to paea
control to the ueer of the termisel. It elrmId be transmitted st tbece
ti~a, and enly et these tinwa, when the user aheuld be given control of the
terminal. Note thet premature transmiaaion of the GA cemmsui may reeslt in
the blocking of output, since the user is likely to cesume that the transmit-
ting system has pa$sed, and therefore he will fail to turn the line around
msnsally.

7
 Downloaded from http://www.everyspec.com

tlIL-STO-17g2
10 May 1984
..

h.3.2 Tranemiesion caution. The foregoing, of course, doee net apply to

the user-to_aerver direction of .xmmunlcation. In tNe direction, G& may’
be sent at any time, but need nor ever be sent. Also, if the TKLNST comec-
tion is being used for proceas+o~rocees ccwaaueicetion,W need not be
sent in either direction. Pina21y, for terminal-to-terminalcammication,
Me may be rewired in neittir, one, or both direction. If a hoot Plava to
auppert terminal-to-temiti cnmnunlcation it is suggested that the lmst
provide the user with a meeee of manually signaling that it is tb for a GA
t0 be sent ever the TRLNST connection; this, h~ever. is not a requirement
on the implementer of a TSIJJBTproceee. . me symmetry of the TEIXRT ntwid
requires an SW. at eaeh eml of the 2KIJJBTconnection, at leeet conceptually.

4.4 Standard representation of centrol functions. As etated in ~ragraph

4.1, the pri=ry geel of the TELNST protocol ie the prevision of a standard
interfacing of termtnel devicee and terminal~riented processee through the
network. Early experiences with thie type of Interconnectionhave slmwn
that certain functione are iuplcnented by moat servers, but that the methode
of invokiu these functione differ widely. Por a human user whe Interacts
with several server syeteae, these dff ferencee are higNy frustreting.
TIRSET, therefore, definee a standard representation for five of theee fune
tions, as described below. These standard repreeentationehave atan&rd,
but ❑ot required, =aninga (with the exception that the Interrupt Procees
(IF) function may be required by other protocols which use TSLN2T); that is,
a eYSt- *ich does nOt provide the function to local usere need noc praide
it to network usere and may treat the atenderd representation for the func-
tion as a No-operation. On the other hard, a eyotem which dees provide the
function to a local user is obliged to provi& the name function to a natvork
user who tranemita the .atamietdrepresentation for the function.

4.4.1 Interrupt prncesa (1P). Many eyetema provide a function which

auspands, intermpte, eborte, or terminates the operation of a ueer protean.
This function la frequently used when a user believes his process is in an
unanding loep, or when an unvanted process has been inadvertentlyactivated.
1P is the standard representation for invoking this function. It should be
noted by icplementerw that 1P may be required by other protocole which uae
TSIJ?ST,and therefore should be implemented if these other protocols are to
be supported.

b.4.2 Abert output (AO). Many .qsteme provide a function which allewe a
rmocees. which is Reneratinx outuut. to run to comletion (or to reach the
eau? stopping poin~ it woul~ re&h if running to c&pletion) but withut
aending the output to the user’e terminal. Further, this function typically
cleare any output already produced but not yet actually printed (or displayed)
on;the user‘n terminal. AO ie the etandard representation for invoking this
function. Por example, some eubaystem might normally accept a uear’a c-rid,
send a long text string to the user ‘a terminal in reapenee, and finally sig-
nal readiness to ac,ceptthe next cemmand by sanding a ‘prompt- character
(preceded by <CRXLP>) to the user’s terminal. If the AO were received
durinx the tranemiesion of the text string, a reasonable implementation
weuld be to suppreee the remainder of the text string, but tnrnemit the
prempt character and the preceding <CRXLP>. (This ie possibly in distinc-
tion to the action which might be taken if an 1P were received; the 1P might

s
 Downloaded from http://www.everyspec.com

flIL-SID-17S2
10 my 1984

cause suppraealm of the text etring and an exit from the subsystem. ) It
slmuld be noted, by server eyetema which provide tMs fumction, that there
MY be buffere external to the system (in the uetvork and the meer’s local
host) which sbnuld be cleared; the appropriate way to do tMs is to tranemit
the “Symch- eigaal (described below) to the ueer system.

6.4.3 Are you there (ATT). tiny eyetems previde a fmnction which prnvidee
...
. the uear with same visible (e.g., printable) e~@nce thet the sYQtem ie etfll
Up and running. ~ia function may be invoked by the ueer when the eystem ie
une~ctadly ‘silent- for a long tinm, bacauee of the unanticipated (by the
user) length of a computation, aIIunueually ~aVY eystem lo~. etc. ATT ie
the stan&rd representation for invokiog thie function.

4.6.6 fkeee character (EC). Xaey”ayetema prwide a function wMch deletea

the ieet preceding undeleted character or ‘print peeition- from the stream
of data being eupplied by the user. A ‘print position- may contain eevarml
character which ere a raeult of”overetrikes, or of saquoncee such ee <cbarl>
ss <cher2>... Thie function 1s typically ueed to edit keyboard input when
~i~ ~stakes are made. EC 1S the etandard repreeentetlon for irIvOkiag
thie function.

4.4. S Erase line (EL). Many eyetema prmvide a fumction which deletes all
the data in the current ‘line- of input. 2%1s function is typically ueed
to ~it keyboard input. EL is the standard representation for inVokiUg thie
function.

I 4.5 The TELNET ‘Synch- eignal. Most tiam-eharing SYSteme prnvide mecha-
niema vhich allow a terminal user to regain control of a ‘runavay” procaaa;
the IP aad AO fuectione deecribad above ate examplea of these me~aniame.
I
Such aysteme, hen used locally, have acceae to OH of the aigeela auppl.ied
by the user, whether these are normal character or apacial ‘out of bamd-
aignala such cc thoee auppiied by the teletype ‘-- key or the IM 2741
1 ‘ATTN- key. Thie la not necesaarlly true when terminda are connected to
the system through the network; the networkla flow control mchaniame WY
cauee such a eignal to be bufferad elaawhere, fourexample in the user’e
1 hoat. To counter tNs problem, the TELSET “Synch- mechaniam ie introduced.
A Synch signal conaieta of a ~P Urgent notification, coupled with the TSLNET
c-rid DATA HARK. The Urgent notification, which la not subject to the
flew control pertaining to the TELNST connection, ie ueed to invoke apacLa2
handling of the data stream by the proceae vhich receives it. In this medei
the data stream la immediately ecenned for “intereatimg- aignela aa defined
I bekv, diecardinK intervening data. The TELSET caamand DATA MEIC (t@i)la
the eynchronizinx mark in the data stream vhich indicates that any apaciel
aimi haa already occurred and the recipient can return to mormal proceeding
I of the data stream. The Synch la sent via the TCP send operation with the
Urgent flau aet and the DM aa the bat (or only) date octet.
/

,..

9
 Downloaded from http://www.everyspec.com

M[L-STO-1782
10. May 1984

4.5.1. Sending several Synchs. Uhen several Synchs are sent in rapid
succession, the Llrgent noti fications may be merged. It is not possible to
count Ltrgents since the number received wi 11 be less than or equal the number
sent. Mhen in normal mode, a 0t4 is a no operation; when in urgent mode, it
signals the end of the urgent processing. If ,TCP indicates the end of Urgent
data before the EM is found, TELNET should continue the special handling of
the data stream unti 1 the CM is found. If TCP indicates more Urgent data
after the ~ is found, i t c.in only be because of a subsequent Synch. TELNET
should continue the special handling of the jata stream unti 1 another U4 is
found. ,. ~
4.5.2 Interesting siqnals. “Interesting= signals are defined to be: the
TELNET standa rd representations of 1P, AO, and AYT (but not EC or EL); the
local analogs of these standard representations (if any); al 1 other TEMET
consnands; other sitedef ined signals which can be acted on without delaying
the scan of the data stream.
I
4.5.3 One effect of the Synch mechanism. Since one effect of the Synch
mechanism Is the i scardlng of essen tl al ly al 1 characters (except TELNH
consnands) between the sender of the Synch and its recipient, this mechanism is
specified 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 be transmitted, the
server which receives the AO (if it provides that function at al 1 ) should
return a Synch to the user.

4.5.4 TELNET comnand requirenmt. Just as the TCP Urgent notification is

needed at the ELNET level as an out-of-band signal, so other protocols which
make use of TELNET may require a TELNET coasnand tiich can be viewed as an
out-of-band signal at a different level. 8y convention the sequence [1P,
Synch] is to be used as such a signal. Far example, suppose that same other
protocol, which uses TELNET, defines the character string STOP analogously to
the TELNET comnand AO. Imagine that a user of this protocol wishes a server
to process the STOP string, but the connection is blocked because the server
is processing other comnands. The user should instruct his system to:

a. Send the TELNET 1P character;

b. Send the TELNET Synch sequence, that is: Send the Oata Mark (ON)
as the only character in a TCP urgent mode send operat i on;

c. Send the character string STOP; and

I d. Send the other protocol’s analog of the TELNET U4, if any.

The user (or process acting on his behalf) must transmit the TELNET SYNCkk
sequence of step b above to ensure that the TELNET 1P gets through to the
server’s TELNET interpreter. The Urgent should wake up the TELNET process;
the 1P should wake up the next higher level process.

4.6 The NVT printer and keyboard.

10
 Downloaded from http://www.everyspec.com

MIL-STD-I 782
I 10 May 1984

I .
4.6.1 Uk’7 printer codes. The NVT printer has an unspecified carriage width
and page Ten and can produce representations of al 1 95 ASCII graPhics
(codes 32 th%gh 126). Of the 33 ASCII control codes (O through 31 and 127),
and the 128 uncovered codes (128 through 255), the following have specified
meaning to the NVT printer:

WE CODE MEANING

a. NULL (NUL) o No Operation

b. Ltne Feed (LF) 10 Moves the printer to the next

print line, keeping the same
horizontal position.

c. Carriage Return (CR) 13 Moves the prl nter to the Ief t

margin of the current line.

In addltlon, the following codes shal 1 have defined, but not required, effects
on the NW printer. Neither end of a TELNET connection maY assume that the
other party wi 11 take, or wi 1 I have taken, any particular action upon receipt
or transmission of the following:

NNE WDE 14EANING

d. BELL (8 EL) 7 Produces an audible or visible

sf9nal (tiiti does NOT move the
print head ).

e. 8ack Space (8S) 8 Noves the print head one

character position towards the
left margin.

f. Horizontal Tab (HT) 9 Moves the printer to the next

horizontal tab stop. It remains
unspecified how either party
determines or establishes where
such tab stops are located.

9. Vertical Tab (VT) 11 Moves the printer to the next

vertical tab stop. It renains
unspecified how either party
determines or establishes where
such tab stops are located.

h. Form Feed (FF) 12 Moves the printer to the top of

the next page, keeping the same
horizontal position.

Al 1 remaining codef do not cause the NVT printer to take any action.

11
 Downloaded from http://www.everyspec.com

MIL-STD-1 782
10 May 1984

4.6.1.1 Example of code use. The sequence ‘W LFm, as defined, WI 11 cause

the NVT to be posit i oned at he left margin of the next print line (as would,
for example, the sequence ‘LF CRm). Nowever, many systems and termi -nals do
not treat CR and LF independently, and wi 11 have to go to some effort to
simulate their effect. (For example, some terminals do not have a CR
independent of the LF, but on such terminals it may be possible to simulate a
CR by backspacing. ) Therefore, the sequence ‘CR LF” must be treated as a
single ‘new 1ine’ character and used whenever their combined action is
intended; the sequence ‘CR NUL= must be used tiere a carriage return alone is
actual lY des i red; and the CR character must be avoided in other contexts.
?his rule gives assurance to systems which must decide whetiier ta perform a
%sew 1ine’ function or a multi pie-backspace that the TELNET stream contains a
character following a CR that wi 11 allow a rational decision. We that “CR
LF’ or Wit NUL- is required in both directions (in the default ASCII mode), to
preserve the syvsnetry of the NVT model. Even though it may be known in scxns
situations (e.g.. with remote echo and suppress go ahead options in effect)
that characters are not being sent to an actual printer, nonethe-less, for the
sake of consistency, the protocol requires that a NUL be inserted following a
CR”not followed by a LF in the data stream. The converse of this is that a
NUL received in the data stream after a CR (in the absence of OPtiOfls
negotiations which explicitly specify otherwise) should be stripped out prior
to applying the NVT to local character set mapping.

4.6.1.2 ASCII code generation. The NVT keyboard has keys, or key
combinations, or key sequences, for generating al 1 128 ASCII codes. Note that
although many have no effect on the NVT printer, the NW keYbOard is caPable
of generating them.

4.6.1.3 Additional codes. In addi t ion to these codes, the WT keyboard

shal 1 be ca~ing the following additional codes which, except as
noted, have defined, but not required, meanings. The actual code assignments
for these ‘characters n are in the TELNET Comnand section, because they are
viewed as being, in some sense, generic and should be available even when the
data stream is interpreted as being some other character set.

This key aI lows the user to clear his data path to the
oth~r.
46131.pir~y =activation of this key causes a CFi (see command section) to
be sent in the data stream and a TCP Urgent notification is associated with
it. The pair CM-Urgent is to have required meaning as defined previously.

This code is provided because it is a signal

OUWM ri%wf%k
systems . It is intended
ich is currently
to indicate
given local meaning within
that the Break Key or the Attention
many
KeY
was hit. Note, however, that this is intended to provide a 129th code for
systems which require it, not as a synonyn for the 1P standard representation.

4.6.1 .3.3 Interrupt process (IP~. Suspend, interrupt, abort or terminate

the process to whi h ‘the is connected. Also, part of the out-of-band
signal for other p~otocols which use TELNET.

12
 Downloaded from http://www.everyspec.com

nIL-sm-1782
IO &ly 1984

b.6.1.3.4 Abert output (AO). Allow the current procees to (appear to)
run to completion, but do not send its output to the user. Also, send a
Synch to the user.

4.6.1.3.5 Are you there (ATT). Send back co the NVT some visible (i.e.,
printable) evidence that the AYT was received.

4.6.1.3.6 Erase character (EC). The recipient sheuld delete the last
preceding undeleted character or ‘print position- from the data stream.
I
4.6.1.3.7 Eraae line (EL). The recipient should delete character frem
{ the data atreem hack to, but not including, the Iaet ‘CR Lp- aaquence sent
riverthe TELNST connection.

4.6.1.3.8 Intent of additional cedes. The spirit of these ‘extra- ~Ye.

and also the printer format effectora, ia that they ahauld represent a
netural exteneion of the moppin~ that already mwt be done frem ‘NVT- into
-local-. Just as the NW data byte 68 (104 octal) sheuld be mapped into
whatever the 1o-1 code for ‘upparcaae D- is, so the SC character should be
mapped into whatever the local _Sraae Character” fwaction is. Further, just
as the mapping for 124 (174 octal) ie aomevhat arbitrary in an environment
that haa no ‘vertical bar- character, the SL character may have a aomewbat
I arbltrary maDPing (or none at all) if there 1s no 10=1 ‘Eraae Line- fadlity.
Similarly for format effectora:. if the terminal actually doee have a ‘Verti-
cal Tab-, then the mapping for W ia obvious, and only when the terminal
doee not have a vertical tab ahoald the effect of VT be unpredictable.

4.7 l13LNETcemmand structure. All TELNET ccammamiscoaaist of at leaat a

I two byte sequence: the ‘Interpret aa Ccmnuand-(MC) escape character foll~d
by the code for the cemmand. The coummm!a dealing with option negotiation
are three byte aequencea, the tMrd. byte being the code for the option refer-
enced. This format waa chosen eo that aa more ccmprehenaive uae of the
‘data apace- ia made — by negotiation from the basic NVT, of course —
colliaione of data bytes with reeemed cwmmand valuea will be minimized, all
such colliaiona requiring the inconvenience, and inefficiency, of ‘eacapiwg-
the data bytes into the stream. With the current act-up, only the IAC need
be dwubled to be sent aa data, and the other 255 codes may be paaaed trans-
parently.

4.7.1 TELNST commands defined. The following are the defined IKLNET
cammanda. Note that thaae codee and co& aequencee have the indicated meaning
only when imm?diate2y preceded by an IAC.

corm

a. SE 240 End of aubnegotlation paraueterw.

/
b. NOP 241 No operation.

c. Data Mark 242 The data stream portion of a Synch.

This should alwaya be accompanied
by 0 TCP Urgent notification.

13
 Downloaded from http://www.everyspec.com

HIL-SID-1762

1
10,Flay1986
.. . . . .. .

I d. Break 263 Nv2 cheracter B7LK.

e. Interrupt Process 244 The function IP.

f. Abert output 245 The funccion M.

g. Are You There 246 The function AYT.

h. Rraee character 247 The fynction S4.

i. Ereee Line 248 The fcmction BL.

..-.
j. Co ahead 249 The CA eignal.

k. SB 2s0 Indicetee that what follewe 1s

subnegotiation of the itaiiceted
option.

1. WILL (Optiaa code) 251 Iadicetes the desire te begin per-

fnradag, or confirmation tb8t you
ere new performing, the irulicated
eptfon.

m. UON’T (option code) 2s2 I.adicatesthe refusal co perform, or

continue performing, the indiated
option.

n. DO (option code) 253 Indicatea the request that the other

party perform, or confirmation that
you are erpecting the other perry to
perform, the indicated option.

0. 00N’T (option code) 254 Indicetes the “demsndthat the other

party stop performing,,or cenfirmatian
that you are no longer expecting t%
other party to perform, the Indiated
option.

v. IAc 255 Data Byte 2S5.

6.8 Connection establishment. Tbe -T lVP connection is established

between the ueer’e uert U and the server’s mrt L. The server Mstene on
its veil knewn port-L for such connectlpna.- Since a TCP connection ie full
duplex and identified by the pair of perte, the server an emgaga in many
eiuultaneeue comneccioaa involving its pert L and different user
perts u.
,
6.8.1 Port esslgmment. When used for remnte user access to eemice hofita
(i.e.. remote terminel ecceea) this protocol is assigned server pert 23 (27
octal). Thet is L-23.

14
 Downloaded from http://www.everyspec.com

M! L-STD-1782
10 May 1984

I :,.’

Custodians: Preparing Activity:

Army-cR OCA - Oc
Navy - CM .
At r Force - 90 (Project IPSC-01 76-01

Review Activities: Other Interest:

Army-sc,CR,Ao NSA - NS
Navy - AS, YO, MC, OM, NO, NC, EC, SA J-m-n
Air Force -01, 02, 11, 13, 17, 99, 90

b’

15
 Downloaded from http://www.everyspec.com

MIL-STD-1782
10 May 1984
,., :..:
.. .
APPENDIX A

TELNET 81NARY TRANSMISSION

10. Catnnand name and code.

TRAJLSNIT-81NARY o

20. Comnand meanings.

20. IAC UILL TRANSMIT-BINPRY. me sender of this ccmsnand REQUESTS

permission to begin transml t ttng, or conftrms that it will now begfn
transdttlng characters whtch are to be t nterpreted as 8 btts of binary data
! by the recel ver of the data.

20.2 IAC UON’ T TRANS141T-81NARY. If the connection ts already being

operated in binary transmission mode, the sender of thfs c-and OWDS to
begin transmitting data characters which are to be Interpreted as standard NVT
ASC1 X characters by the receiver of the data. If the connection $S not
already being operated In binary transmission mode, the sender of this cansnand
REFUSES to begin transmlttin characters which are to be Interpreted as binary
characters by the receiver o? the data (i.e., the sender of the data dmands
to continue transmitting characters in its present mode). A connection is
I
being operated in binary transmi sslon mode only when one party has requested
it and the other has acknowledged it.

20.3 IAC 00 TRANSMIT-81 NlAY. The sender of this ccinnand REQUESTS that the
sender 07 he data start transmitting, or conf i m that the sender of data is
I expected to transmit, characters which are to be interpreted as 8 bits of
I binary data (i.e., by the party sending this comnand).

20.4 [AC DON’ T TRANSMIT-BINPRY. If the connection is already being

operated in binary transmission mode, the sender of this comnand DEIWDS that
the sender of the data start transml ttlna characters which are to be
I interpreted
(i e.,
as standard NVT ASCII characters
the party sending thts comnand).
by the receiver
If the connection
of the data
1s not already
being operated in bfnary transml sslon mode, the sender of this consnand DEMANOS
that the sender of data continue transml ttlng characters which are to be
interpreted In the present mode. A connection Is being operated in binary
transmi sslon uncle anly when one party has requested it and the other has
acknawl edged it.

30. &fault.

WON’ T TRANS141T-81NPAY

DON’T TRANSMIT-81 NAftY

The connection Is not’operated In binary mode.

16
 Downloaded from http://www.everyspec.com

MIL-STO-1782
,.. 10 May 1984

40. Not~vation for the optton. It “is sometimes useful to have available a
binary ~ransmission path within TELNET without having to utf Iize one of the
more efficient, higher level protocols providing binary transmission (such as
the File Transfer Protocol ). The use of the IAC prefix wlthln the basic
TELNET protocol provides the option of binary transmission In a natural way,
requlrlng only the addttion of a mechanism by which the parties involved can
agree to INTERPRET the characters transmitted over a TELNET connect 1on as
binary data.

50. Oescrlption of the option. Mith the binary transmission option In

effect, he receiver should interpret characters received f mm the transmitter
which are not preceded with IAC as 8 bit binary data, with the exception of
IAC followed by IAC which stands for the 8 bit binary data with the decimal “
value 255. SAC f ol lowed by an effective TELNET coasnand (plus any addttfonal
characters required to complete the comnand) is stl 11 the consnand even with
the binary transmission option In effect. IAC followed by a character which
Is not a deffned TELNET command has the same meaning as IAC followed by NOP,
although an IAC f ol lowed by an undef Ined conmand should not normal lY be sent
in this axwle.

60. Implementation suggestions. It is foreseen that implementations of the

.blnary transmission option will choose to refuse some other options (such as
the EBCOIC transmission option) wht le the binary transmission opt{on is in
effect. However; if a pair of hosts can understand being in binary
transmission mode simultaneous with being In, for example, echo mode, then it
is alright if they negotiate that combination. The meanings of WON’T and
00N’ T are dependent upon whether the connection is presently being operated in
binary mode or not. Consider a connection operating in EBCDIC mode whfch
invo?ves a system which has chosen not to implenent any knowledge of the
binary comnand. If thts system were to receive a 00 lTMNSMIT-81NARY, it would
not recognize the TRANSMIT-8 INPRY opt ton and therefore wuld return a lfON’ T
lRANSMIT-81NPRY. If the default for the NON’ T TTt~SMIT-81NARY were always NVT
ASCI 1, the sender of the 00 TRANSMIT-81NARY tmuld expect the recipient to have
switched to NvT ASCII, tiereas the rece{ver of the 00 TRANSMIT-81NARY ‘would
not make this interpretation. Thus, we have the rule that when a connection
is not presently operating In binary nude, the default (1 e., the
interpretation of UON’ T and lXIN’ T) Is to cent fnue operating In the current
mode, tiether that is NVT ASCII, EBCOIC, or some other rode. This rule,
however, 1s not appl led once a connection 1s operating fn a binary mode (as
agreed to by both ends); th{s would require each end of the connection” to
mafntaln a stack, contalntng al 1 of the encodlng+nethod transitions witfch had
previously occurred on the connection, in order to properly Interpret a kfON’ T
or CNIN’T. lhus, a UON’ T or 00N’ T received after the connection is operatl ng
in binary mode causes the encoding method to revert to NW ASCII.

17
I Downloaded from http://www.everyspec.com

MI L-STD-1 782
10 May 1984
..

70. 8~nary transml ssion mode. It should be remembered that a TELNET

connection 1s a two way comnuni_catlon channel. The binary transmission mode
must be negotiated separately for each direction of data flow, if that is
desired. Implementation of the binary transmission .oPtion o as is the case
with implementations of al 1 other TELNET options, must follow the looP
preventing rules given in the 6eneral Considerations section of the TELNET
Protocol Specification. Consider now some issues of binary transmission both
to and from both a process and a terminal:

70.1 Binary transmission frcxn a terminal. The implementer of the binary

transmission option shoul d consider how (or whether) a tetWinal transmitting
over a TELNET connection with binary transmission in effect is allowed to
generate al 1 eight bit characters, ignoring parity considerations, etc., on
input from the terminal.

70.2 8inary transmission to a process. The implementer of the binary

transmission option should consider how (or whether) al 1 characters are passed
to a process receiving over a connection with binary transmission in effect.
A an example of the possible problem, TOPS-20 intercepts certain characters
(e.g., ETX, the terminal control-C) at monitor level and does not pass them to
the process.

70.3 8inary transmission from a process. The i lementer of the binary

‘transmission option should consider how (or whether 7 a process transmitting
over a connection with binary transmission in effect is allowed to send al 1
eight bit characters with no characters intercepted by the monitor and changed
to other characters. An exanqle of such a conversion may be found in the
TOPS-20 system where certain non-printing characters are normal lY converted to
a Circumflex (up-arrow) followed by a printing character.

70.4 8inary transmission to a terminal. The implementer of the binary

transmi sslon option shou Id consider how (or tiether) al 1 characters received
over a connection with binary transmission in effect are sent to a local
terminal. At issue may be the addition of timing characters normal lY inserted
local ly, parity calculations, and any normal code conversion.

18
 Downloaded from http://www.everyspec.com

MI L-STD-1782
10 May 1984

APPENDIX 8

TELNET EClt3 OPTION

10. Cunnand name and code.

ECNO 1

20. Coionand meanings.

20.1 IAC MILL ECW. The sender of this cotnnand REQUES~ to begin, or
con-firms that now begin, echol ng data characters 1t receives over the
TELNET connection ~ack to the sender of the data characters.

20.2 IAC ltON’ T ECHO. The sender of this comnand DEMANOS to stop, or
refuses to start, echoing the data characters ft receives over the TELNET
connect f on back to the sender of the data characters.

20.3 IAC 00 ECHO. The sender of this comnand REQUESTS that the rece~ver of
this cousnand be gin echoing, or confirms that the receiver of this cotnnand is
expected to echo, data characters ft receives over the TELNET connection back
to the sender.
I
20.4 IAC DON’ T ECHO. me sender of this comnand DEMANOS the receiver of
this command stop, or not start, echoing data characters ft recetves over the
TELNET connect ton.

30. Default.

lfON’ T EcND

! MN*T ECH)

No echoing Is done over the TELNET connection.

I
40. hbtivat{on for the option. The NW has a printer and a keyboard which
are nomlna 11y interconnected so that “echoes” need never traverse the network;
that is to say, the NVT nominally operates in a mode where characters typed on
the keyboard are (by some means) local ly turned around and printed on the
printer. In highly Interactive situations it Is appropriate for the remote
process (comnand language interpreter, etc. ) to which the characters are being
sent to control the way they are echoed on the prl nter. In order to support
such interactive situations, 1t is necessary that there be a TELNET option to
al ltnt the parties at the two ends of the TELNET connection to agree that
characters typed on an NVT keyboard are to be echoed by the party at the other
end of the TELNET connection.
/

19
 Downloaded from http://www.everyspec.com

fiIL-STO-1782
10,kbly]984
.. ... .
..
5.0 Ocscription of the option. When the echo@g option is in effect, the
party at the end performing the echoing 1.sexpected to transmit (echo) data
character it receives back to the sender of the deta characters.. The option
does not require that the characters echsed be exactly the characters received
(for example, a sumber of systems echo the AMII E* *eracter with sO=tM~
other then the ESC character). When the echoing option is not in effect, the
receiver of data charactem shsuld not echo them back to the sender; this,
of cou=e, does not prevent the receiver from responding to data cbaractere
! received. The normal TELSET connection is two way. That ia, deta flows in
each direction on the connection independently; and neither, either, or both
dlrectfone may be eperatfng sfmultmeeusly in echo msde. There are five
reasonable nmdee of operetlon for echeing on e connection pair:

4
moceesl moceeea
*
Neither eul echoes

PRoceeel
4, f
*
?wcese a

One end echoes for itself

-
mocrss 1 mocrss 2
)b
One end echeee for the other

PsOcrssl mocree2
4, (~

Seth ends echo for themselves

“’L “
One ecd echoes for both ends
FIGURE’1. Five reasossble medee of operation for
echoing on a connection pair.

20
 Downloaded from http://www.everyspec.com

Ml L-STD-l 782
.. ... 10 May 1984

opt ton provides the capabl 1ity to decide on whether or not either end
echo for the other. It does not, however, provide any control over
whether or not ah end echoes for itself; this decision must be left to the
sole di scret ion of the systems at each end (although they may use information
regardin the state of “remote- echoing ne otiations in making this
decision?. If BOTH hosts enter the mode o? echoing characters transmitted by
the other host, then any character transmitted in either direction Vi 11 be
“echoed” back and forth indefinitely. Therefore, care should be taken in each
implementation that if one site Is echoing. echoing is not permitted to be
turned on at the other. As discussed in Section 4, both parties to a
full-duplex TELNET connection initfally assume each direction of the
““connection is being operated in the default mode which is non-echo (non-echo
is not using this option, and the “same as DON’T ECHO, WON’T ECtO). If either
party desires himself to echo characters to the other party or for the other
party to echo characters to him, that party gives the appropriate connmnd
(HILL ECHD or DO ECHO) and waits (and hopes) for acceptance of the option. If
the request to operate the connection in echo mode is refused, then the
connection continues to operate In non-echo mode. If the request to operate
the connection in echo mode is accepted, the connection is operated in echo
mode. After a connection has been changed to echo mode, either party may
demand that it revert to non-echo mode by giving the appropriate DON’T EcHD or
IION’ T ECHO csxnnand (which the other party must conf i nn thereby allowing the
connection to operate in non-echo mode). Just as each direction of the TELNET
connec-tion may be put in remote echoing mode independently, each directton of
the TELNET connection must be removed from remote echoin9 mode separately:

60. Implementation of the option. Implementations of the echo option, as

implementations of all other ~ options, must follow the loop preventing
rules given in the @neral Requirements section of the TELNET Protocol
Standard. Also, so that switches between echo and non-echo mode can be made
with minimal confusion (momentary double echoing, etc. ), switches in mode of
operation should be made at times precisely coordinated with the reception and
transmission of echo requests and demands. For instance, if one party
responds to a OD ECHO with a HILL ECHO, al 1 data characters received after the
DO ECHO should be echoed and the HILL ECHO should insnedi ately precede the
first of the echoed characters. The echoing option alone will normal Ty not be
sufficient to effect what is consnonly understood to be remote computer echoing
of characters typed on a terminal keyboard-- the SUPPRESS-GU AHEAD option wi 11
normal ly have to be Invoked in conjunction with the ECHD option to effect
character-at-a-time remote echoing.

60. ] A SW le implementation of the option. The following is a description

of a posslbl e Implementation tor a simple user system called WiOST”. A
possible implementation could be that for each user tetminal, the UKIST would
keep three state bits: whether the terminal echoes for itself (UHOST ECHO
always ) or not (ECHO mode possible), wtsether the (human) user prefers to
“operate in ECHD ~de or in non-ECHO mode, and whether the connection from this
terminal to the server is in ECHO or non-ECHO mode. We wi 11 cal 1 these three
bits P(hysical ), O(esired), and A(ctual ). When a terminal dials UD the UHOST
the P-bit is set appropriately, the O-bit is Set equal to it, and” the A-bit i;
- set to non-ECHO. The P-hi t and D-hit may be manual ly reset by
.

21
 Downloaded from http://www.everyspec.com

MIL-STO-17E2
1 .. 10.Nay 1984 . . ..-.
...

direct cemrmnde if the user w &oiree. F“orexample, a user in Ecwaii on a

‘full-duplex-terminal, would choose not to operate in ECSO wde, regardlees
of the preference of a maln2amd server. He sheuld direct the OSOST to change
hia O-bit from ECHO to non-KCNO. When a connection la opened from the OSOST
terminal to a server, the OEOST wotid send the server a 00 ECEO command if
the H2N (vith non-EC30 leaa than R~O) of the P- and D-bite ie different
frem the A-bit. If a WON’T 132H0or W2LL ~0 arr2ves fran the server, the
OEOST will set the A-bit to the MN of the received request, the P-bit, end
the O-bit. If tMs changee the atete of the A-bit, the UEOST till send off
the appropriate acknowledgment; if it”does not, then the DEOST wfil send off
the appropriate refusal if not changing mant that it bnd to &my the request
(i.e., the KIN of the P-and o-bits was lees then the received A-request). If
while a connectIon is open, the ONOST tervdna2 user changes either the P-bit
or O-bit, the OSOST will repeat che abeve teats and send off a 00 ECEO or
00N’T SCRO, If neceaaary. When the connection is closed, the OEOST wou2d
reset the A-bit to indicate IJNOSTecbelng. While the UHOST’s implementation
would not involve DO ECNO or OONIT IZEO cmmamfs being sent to the server
except vhen the tonnectinn is opened or the user explicitly changee Ms
echoing mxla. bimer keste might lmvoke such nmde awltches quite frequently.
For instance, while e Line-at-a-time eystem were runaing, che server might
attempt to put the user in local echo mode by aesding the WON’T 132H0command
to the user; but while a characte~t-a-cima ayatem were running, the server
-aixhtattempt to invoke rent.teechoing for the ueer by serslingthe WILL SCNO
command to the user. Furthernmre, vhile the ONOST will never send a U2LL
ECNO cmmsmi and will only send a WON’T SCHO to refuse a server sent 00 ECHO
c-rid, a server heat might often send the U2LL and ~N’T ECNO crsmnands.

22
 Downloaded from http://www.everyspec.com

MI L-STD-1782
10 May 1984

I ... APPENDIX C

TELNET SUPPRESS GO ANEAD OPTION

10. Comnand name and code.

SUPPRESS-60 -ANEAD 3

20. Conwmnd meaninqs.

.20.1 IAC WILL SUPPRESS-60 -ANEAD. The sender of this cmnnand requests’
‘ pennlsslon to begin suppressing transmission of the TELN~ GO ANEAD (GA)
character when transmitting data characters, or the sender of this comnand
confirms it will now begin suppressing transmission of GAs with transmitted
data characters.

20.2 IAC UON’ T SUPPRESS-GO-ANEAD. The sender of this comnand demands to

begin transmitt Ing, or to continue transmitting, the 6A character when
trans-mitting data characters.

20.3 IAC 00 SUPPRESS-GO-ANEAD. The sender of this ccunnannd requests that

the sender of data start suppressing GA when transmitting data, or the sender
of this comnand confirms that the sender of data is expected to suppress
transmission of &%,

20.4 IAC DON’T SUPPRESS-W-ANEAD. The sender of this consnand demands that
the rece~ver of the command start or cent inue transmitting GAs when
transmitting data.

30. kfault.

MON’ T SUPPRESS -60-ANEAD

DON’ T SUPPRESS-GO -ANEAD

@ aheads are transmitted.

40. Notlvation for the option. blhile the NVT nominally follows a half
duplex protocol complete wit h a GO ANEAO signal, there is no reason why a full
duplex connection between a ful 1 duplex terminal and a host optimized to
handle full duplex terminals should be burdened with the GO ANEAD signal.
Therefore, it is desirable to have a TELNET option with which parties
i n-volved can agree that one or the other or both should suppress transmission
of 60 ANEAOS.

50. Description of the option. Uhen the SUPPRESS-&WINEAD option is in

effect on the connect ion between a sender of data and the receiver of the
data, the sender heed not transmit *. It seems probable that the Parties to
the TELNET connection wi 11 suppress GO ANEAD in both directions of the TELNET
connection if ~ ANEAD is suppressed at al 1; but, nonetheless, it

23
 Downloaded from http://www.everyspec.com

MI L-STD-1 782
10 may 1984
.....
mist be suppressed in both directions independent y. Uith the
SUPPRESS-61WlHEAD option in effect, the IAC GA comnand should be treated as a
NOP if received, although IAC 6A should not normally be sent in this mode.

60. Implementation considerations. As the SUPRESS-EO-ANEAD option is sort

of the opposite of a Ine-at-a time mode, the sender of data which is
suppressing 60 MEAOs should attempt to actually transmit characters as soon
as possible (i e., with minimal buffering) consistent with any other
agreements which are in effect. In many TELNET implementations it will be
desirable to couple the SUPPRESS-60 -PHEAO option to the echo oPtion so that
when the echo option ,is in effect, the SUPPRESS-6 Q-ANEADoption is in ef feet
simultaneous y: both of these options WI 11 normal 1y have to be in effect
simultaneous ly to effect what is comnonl y understood to be character-at-a time
echoing by the remote computer.

24
 Downloaded from http://www.everyspec.com

MI L-STD-1782
10 May 1984
.....
I“ APPENDIX D

TELNET STATUS OPTION

10. Consnand name and code.

STA?US 5

20.1 Cannand meanings. lhis option epplies separately to each dfrectfon of

data flow.

20.1 IAC NILL STATUS. The sender of HILL status agrees to send status
information. spontaneously or In response b future requests.

20.2 IAC WON’T STATUS. Sender refuses to carry on any further discussion
of the current status of options.

20.3 IAC 00 STATUS. The sender of 00 wishes to be able to send request for
status 0? in option information or conffm that he is wi 11 ing to send such
requests.

20.4 IAC 00N’ T STATUS. Sender refuses to carry on any further discussion
of the current status of options.

20.5 IAC SB STATUS SENO IAC SE. Sender requests receiver to transmit his
(the receiver]s ) perception of th e current status of TELNET options. The code
for SEND is 1.

20.6 IAC SB STATUSIS. . . IAC SE. Sender is stating his Deception of the
current status of T options. The code for IS is o.

30. Default.

00N’ T STATUS, WON’T STATUS

The current status of options” wi 11 not be df scussed.

40. Motivation for the option. This option allows a userbocess to verify
the current status of T options (e.g., echoing) as viewed by the person/-
process on” the other end of the TELNET connection. Sfmply renegotiating
options could lead to the nonterminat ing request loop problem discussed in
paragraph 4.2.3. This option fits into the normal structure of TELNET optfons
by deferring the actual transfer of status i nfonnation to the SB consnand.

50. Description of the optfon. IJILL and DO are used only to obtain and
grant permission tor future di scussion. The actual exchange of status
informatf on occurs ,yithin option subcomnands ( IAC SB STATUS...). Once the tw
hosts have exchanged a MILL and a 00, the sender of the HILL STATUS is free to
transmit status information, spontaneously or in response to a request from

25
 Downloaded from http://www.everyspec.com

I .. MI L-STD-1782
10 tiy 1984 .“. ..

the sender of the DO. At worst, thfs may lead to transmitting the information
twice. Only the sender of the DO may send requests ( IAC S8 STA~ SEND IAC
SE) and only the sender of the MILL may transmit actual status information
(withtn an XAC S8 STATUS IS . . . IAC SE Comnand). IS has the subc-ands UILL.
CUI and S8. They are used EXACTLY as used during the actual negotiation of
TELNET options, except that S8 is terminated with SE, rather. than IAC SE.
Tiansmisslon of SE, as a regular data byte, is accomplished by doubling the
byte (SE SE). Options that are not explicitly described are assumed to be in
their default states. A single IAC S8 STATUS IS... IAC SE describes the
condi t ion of ALL optl ons.

60. fiample of option application. “ lhe following is an example of use of

the opt?on:

I+xtl : IAC DO STATUS

l@t2: IAC NILL STATUS

(lbst2 is now free to send status information at any time.

Sol ici tations frcsn Nostl are NOT necessary. lhis should not produce
any dangerous race conditions. At wurst, two IS’s wi 11 be sent. )

Nostl (perhaps): IAC S8 STATUS SEND IAC SE

Nost2 (the following stream is broken into multiple 1ines only for
readability. No carriage returns are implied.):

IAC S8 STATUS IS

WILL ECNO

@O SUPPRESS-GO-ANEAO

WILL STATUS

00 STATUS

MC SE

Explanation of kbt2’s perceptions: It is responsible for echoing

back the data characte~ it receives over the TELNET connection;
it wilt not send &-head signals; it will both issue and request
, Status infonoation.

26
 Downloaded from http://www.everyspec.com

MI L-STD-1782
10 May 1984

APPENI X E

TELNET TIMING lWiK OPTION

10. Coaznand name and code.

TIMING-MMK 6

20. Comaand meanings.

20.1 [AC UILL TIM ING-WRK.. The sender of this ccmsnand ASSURES the receiver
of th 1s comnand is fnserted In the data stream at the “appropriate
place” to insure s~c~ronization with a 00 TIMING-MPRK transmitted by the
receiver of this comnand.

20.2 IAC UON’T TIMING-WRK. The sender of this consaand REFUSES to insure
that this comnand is inserted in the data stream at the ‘appropriate place- to
insure synchronization.

20.3 IAC 00 TIMING-MPRK. The sender of this command REQUESTS that the
receiver of his coinnand return a WILL TIMING-MARK In the data stream at the
‘appropriate place” as defined in paragraph 11.4 below.

20.4 IAC DON’T TIMING-14ARK. The sender of this command notifies the
receiver of hls consnand thaf a HILL TIMING-MARK (previously transmitted by
the receiver of this comnand ) has been IGNOREO.

30. Oefaul t.

IION’T TIMING-MARK, CtlN’T TIMING-MARK

i.e., No explicit attempt is made to synchronize the activities at the two

ends of the TELNET connection.

40. Motivation for the o It is sometimes useful for a user or

process at one end of a TEL connection to be sure that previously
transmitted data has been co+npletel y processed, printed, discarded, or
otherwise disposed of. Thfs option provtdes a mechanism for doing this. In
addition, even if the option request (00 TIMING-WWK) is refused (by WON’T
TIMING-MARK) the requester is at least assured that the ref user has received
(if not processed) al 1 previous data.

50. ExamP As an example of a particular

connection between a ohysical lY ful 1 duplex
~ekinal and a “~ul 1 duplex” server system which pe%i ts the- user to ‘type
ahead- while the server is processing previous user input. Suppose that both
sides have agreed .,to Suppress Go Ahead and that the server has agreed to
provide echoes. The server now discovers a Ccxwnand whfch 1t cannot Parse.
perhaps because of a user typing error. It would like to throw away all of
the user’s “type-ahead” (since failure of the parsing of one ccmand is likely

27
 Downloaded from http://www.everyspec.com

.. ML-STD-1782

1
10 &y 1984

I tO lad
tO incorrect results if subaeq~nc c~~s are =ecuted), se~ tba
user error message, and raeume interpretation of canmande which the ueer
an
typed after seeing the error meesage. If the user were local, the eystem
wnuld be able to discard the buffered input; but input may be b@ fered in
the ueer’s best or edsewhere. Therefore, the server might send a’00 TRUNG
MARK and hope to receive a WILL T7H2NG+4AKK from the user at the ‘appropriate
place- in the data Etreem. The ‘appropriate piece- (in ebsence of other
information) Is clearly juet before the firet chnractei which the user typed
aft:r,eaeing the error meseaga. “ That is,.it ehnuld eppaar that the timimg
mark wan ‘printed- on the userma termlnel and that, %n response, tbe uoer
typed en anewering timing mark. Next, rsupposethat the ueer in the exe!@le
above realized that he had mieapalled a ccumand, realized that the server
wou2d send a DO T~2N~, and wanted to etart ‘typing ah?ad- again wlt~ut
waitimg for this to occur. 2tamight then imetruct MS ewn eyetem to send a
WILL TIMXNC+AKK to the server and then begin ‘typing ahead- again. (Imple-
mantere.ehould remember that the user’s en eystem aunt remember that it
sent the WILL T21f2NC-NAKKeo co to dieterd the DOiDON’T T12UNC+IAKK when it
eventually arrivae.) Thw, in this ase the “appropriate place- for the
insertion of the H21.LT2N2NC+AEK 10 the piece defined by the ueer. In botb
of the examplae above, it ie the raopeneibility of the system which tranemlta
the DO TIM2NC-NAKK to discard any uuvanted character; the WILL T12UN0—NAKK
on2y provides help in deciding which charactere are ‘unwanted-.

6.0 Daacription of the op tion. Suppose that Process A of Figure 2 Wishes

to eyncbronfze with B. The 00 T2MNC+ARK la sent frca A to B. B cxm refuse
by replying WON’T TI141NC-NAKK,or agree by permitting the”timlog =rk to
flev through Me ‘outgoing- buffer, BUF2. Then, ineteed nf delivering it to
the termlmal, B will enter the mark into his ‘incoming- buffer BUF1, to flew
through tevard A. When the mark baa propagated through B ‘e incnmlng kuffer,
I B returns the WILL T2MNC+AKK over the TELNET connection to A.

?uocEae A rrLNrlcOnut&n
, ‘reuMmu

“ ‘-o- “~
+
-l:Fiil-

oonMwe MARs “ -1%’ul-

* *
(NV+
PRecraal

FIGUKB 2. Synchronization of proceeees.

When A receives the’WILL T2NING-MAKK, he knnw.s that e21 the information he

sent to B before sending the timing mark been dellvered, and all the informa-
tion neat frem B to A before turnarwed of the timing mark hee been delinred. :

28
 Downloaded from http://www.everyspec.com

MIL-STD-1782
10 May 1984

70. Three typical applications.

70.1 Round-trip delay. Measure round-trl p delay between a process and a

terminal or another process.

70.2 Resynchroni zation. Desynchronizing an Interaction ts described in

paragraph 4 above. is a process interpreting comnands forwarded from a
I termtnal by B. Hhen A sees an illegal comnand it:

a. Sends <carriage return>, <1 ine feed>, cquestion mark>.

1 b. Sends 00 TIMING-MARK.
I
c. Sends an error message.
I d. Starts reading input and thrcwing it away until it receives a
MILL TIMING-MARK.

e. Resumes interpretation of input.

I This achieves the effect of f Iushfng all “type ahead” after the erroneous
comnand, up to the point when the user actual 1y saw the question mark.

1“ 70.3 Oual synchronization.

wants to th row away unwanted
The dual of paragraph
output frc+n A.
7.2. The terminal user

1 a. B sends 00 TI141NG-44PRK, followed by some new consnand.

1 b. 6 starts
receives
reading output from A and throwing
MILL TIMING-MPRK.
it away until it

I c. B resumes forwarding A’s output to the terminal.

This achieves the effect of flushing all output from A, up to the point where
A saw the timing mark, but not output generated in response to the following
conznand.

29
 Downloaded from http://www.everyspec.com

1.
I MI L-STD-1782
,.,.. . . .

I 10 May 1984

APPENDIX F
I
TEINET EXTENDED OPTIONS - LIST OPTION

I 10. Cotnnand name and code.

EXTENDED-OPTIONS-LIST (EXOPL) 255

I
20. Command meanings.

20.1 IAC UILL EXOf’L. The sender of thfs comnand REQUESTS penni ss ion to
begin negotiating, or confirms that It will begin negotiating, TELNET options
which are on the ‘Extended OptIons List. ”

20.2 IAC UON’T EXOPL. The sender of this coinnand REFUSES to negotiate, or
to continue negotl sting, options on the ‘,Extended options LiSt. o

20.3 IAC 00 EXOPL. The sender of this consnand REQUESTS that the receiver
of this coinnand b egfn negotiating, or confirms that the receiver of this
.comnand is expected to begin negotiating, TELNET options With are on the
‘Extended Options List. 0

20.4 IAC DON’T EXOPL. The sender of this comnand OEMNDS that the receiver
conduct no further negotiation of options on the ‘Extended Options List. ●

20.5 IAC S8 EXOPL <subconmand>. The subcotonand contains information

required for he negotl ation of an option of the ‘Extended Options List. 0 The
format of the subcomnand is discussed in paragraph 5 below.

30. Default.

UON’ T EXOPL, KIN’ T EXOPL

Negotiation of options on the “Extended Options Li St” is not permitted.

40. Motivation for the option. Eventual lY, a 257th TELNET option wi 11 be
needed. Ttl 1s option w1ll extend the option list for another 256 options in a
manner which is easy to implement. The option is proposed now, rather than
later (probably much 1ater), in order to reserve the option number (255).
~
50. Oescript ion of the option. The EXOPL option has five subcomnand codes:
MILL; ~ They have exactly the same meanings as the
TELNET cotnn&sds ‘wi th t~ea~ame &mes, and are used in exactly the same way.
For consistency, these subconsnand codes wi 11 have the same values as the
TELNET comnand codes, (250-254). Thus, the format for negotiating a specific
option on the ‘Extended Options List” (once both parties have agreed to use
it) is:

I IAC SB EXOPL DO/OON’ T/HILL/WON’ T/<optton code> IAC SE

I 30. .
I Downloaded from http://www.everyspec.com

MIL-STO-1782
10 May 1964

Once both sides have agreed to use the specific option specified by <option
code>, subnegoti at ion may be required. In this case the format to be used is:

IAC SB EXOPL SB <option code> <parameters> SE IAC SE

31
 Downloaded from http://www.everyspec.com

INSTRUCTIONS h . eantinuimg effort fn mtk. our ttsndardiition documun~ better, the DoD pmvidci this form for ucc i.
mbmitdng commen~ ●d cugsudmu (or impmvemeoti. AU wcm of mitilary dandmdizafion docume.ta are inritcd to provide
qations. ‘II& form -g be de-bed, folded dons the fins hdiafed, taped afoas ibe loon edse (DO NOT STAPLE), md
.. mailed. fn block 6, be u spccifii u padbfe cbout particular Probtem - web u mudins -f&b required intemwekation. -
h @d. ~=. 4 -Ms’-% -- kr-mwtlble. andslvdcmwaed wrhs chansuwbkb wmdd autiti ti
~bfcum. f?ntc?in bfock 6 my mmah not refated to t slteeiflc omsms)b of Ilte document. If bfak 7 u filfed out, M
tirmwicdgement WI be mded b you wklbfn sO day8 to let you know tit your commenb warm received and are L4ng
cOmi&l’cd.

NOl%: ‘fW form may mot be A to mqued ~pfcg of daumenu, nor to mquak wafwm, dwfsfhns, or chrkfhtton of
-fkab m@remeat! on mlrmnt CcJltncfs. cOmmcntE Suf.vnittad on UI18form do not COoafitule 0? impfy au ftlori=tion
b wake my po?tkm at tbe demmed dommentia) or to amend cunhctual $’eqolmmm&

(Fold aiuu CM u-)

OFflCfAL
?ENALIV
su51Nm
FOCI●RWATE uSE SW BHJNESS
Ve
REPLY MAIL
FIWIT A1.,~&l., VA. MO. A9M
111111 u No

UNITED
POSTAGE
NECE~RV
IF MAILEO
8M THE
STATES

POSTAOE WILL Ot? PAID 8V

Director
Defense Ccmnuni cations Engl neering Center
/ lnteroperability 6 Standards Office
I 1860 Ulehle Avenue
Reston, VA 22090-5500
 Downloaded from http://www.everyspec.com

STANDARDIZATION DOCUMENT IMPROVEMENT PROPOSAL

& Inmucfiom - Kercrse Side)
.. OOCulAENT Nuwaen 2. 00 CUWENT TITLE
.
7&.. 4. Tvve OF 0noANt7.ATtON (mm -$
L NAWEOFSUSMi~lNO OR~Nl_TlOM

0 VENDOR

❑ us,.

AOORESS mmt C@. S**. =P Cdl

MANUPA~URER
cl”

D O,”cll(stifi,:

PROBLEM [email protected]

. P.qul N“* - wa.dhlw

& — w41dlnw

c R.uOFJR.!hWI# f- R—lam:

REMARKS

-.. .
.

I. NAME OF SUn MITIER ,kl. Fh, M,,, - 00I1md b, WORK TE1.EPMONE NUUBER/fnslnd# A-
C*) - 09 Wllld

MAILING 400RESS ,Sl,.cf, CIW. Sfa~. X,, C&, - OP,IONI 8, oATE OF SU8UISSION tVVMMDD)

.—
OUS EO, T,ON
DD.%’’)!!.
1426 P~EV, OS OBSOLETE.