As per Relevance of the word engineering, we have this rfc below:
Network Working Group Internet Engineering Task
Request for Comments: 1123 R. Braden,
October 1989
Requirements for Internet Hosts -- Application and
Status of This
This RFC is an official specification for the Internet community.
incorporates by reference, amends, corrects, and supplements
primary protocol standards documents relating to hosts.
of this document is unlimited
This RFC is one of a pair that defines and discusses the
for Internet host software. This RFC covers the application
support protocols; its companion RFC-1122 covers the
protocol layers: link layer, IP layer, and transport layer
Table of
1. INTRODUCTION ............................................... 5
1.1 The Internet Architecture .............................. 6
1.2 General Considerations ................................. 6
1.2.1 Continuing Internet Evolution ..................... 6
1.2.2 Robustness Principle .............................. 7
1.2.3 Error Logging ..................................... 8
1.2.4 Configuration ..................................... 8
1.3 Reading this Document .................................. 10
1.3.1 Organization ...................................... 10
1.3.2 Requirements ...................................... 10
1.3.3 Terminology ....................................... 11
1.4 Acknowledgments ........................................ 12
2. GENERAL ISSUES ............................................. 13
2.1 Host Names and Numbers ................................. 13
2.2 Using Domain Name Service .............................. 13
2.3 Applications on Multihomed hosts ....................... 14
2.4 Type-of-Service ........................................ 14
2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15
Internet Engineering Task Force [Page 1]
RFC1123 INTRODUCTION October 1989
3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16
3.1 INTRODUCTION ........................................... 16
3.2 PROTOCOL WALK-THROUGH .................................. 16
3.2.1 Option Negotiation ................................ 16
3.2.2 Telnet Go-Ahead Function .......................... 16
3.2.3 Control Functions ................................. 17
3.2.4 Telnet "Synch" Signal ............................. 18
3.2.5 NVT Printer and Keyboard .......................... 19
3.2.6 Telnet Command Structure .......................... 20
3.2.7 Telnet Binary Option .............................. 20
3.2.8 Telnet Terminal-Type Option ....................... 20
3.3 SPECIFIC ISSUES ........................................ 21
3.3.1 Telnet End-of-Line Convention ..................... 21
3.3.2 Data Entry Terminals .............................. 23
3.3.3 Option Requirements ............................... 24
3.3.4 Option Initiation ................................. 24
3.3.5 Telnet Linemode Option ............................ 25
3.4 TELNET/USER INTERFACE .................................. 25
3.4.1 Character Set Transparency ........................ 25
3.4.2 Telnet Commands ................................... 26
3.4.3 TCP Connection Errors ............................. 26
3.4.4 Non-Default Telnet Contact Port ................... 26
3.4.5 Flushing Output ................................... 26
3.5. TELNET REQUIREMENTS SUMMARY ........................... 27
4. FILE TRANSFER .............................................. 29
4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29
4.1.1 INTRODUCTION ...................................... 29
4.1.2. PROTOCOL WALK-THROUGH ............................ 29
4.1.2.1 LOCAL Type ................................... 29
4.1.2.2 Telnet Format Control ........................ 30
4.1.2.3 Page Structure ............................... 30
4.1.2.4 Data Structure Transformations ............... 30
4.1.2.5 Data Connection Management ................... 31
4.1.2.6 PASV Command ................................. 31
4.1.2.7 LIST and NLST Commands ....................... 31
4.1.2.8 SITE Command ................................. 32
4.1.2.9 STOU Command ................................. 32
4.1.2.10 Telnet End-of-line Code ..................... 32
4.1.2.11 FTP Replies ................................. 33
4.1.2.12 Connections ................................. 34
4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34
4.1.3 SPECIFIC ISSUES ................................... 35
4.1.3.1 Non-standard Command Verbs ................... 35
4.1.3.2 Idle Timeout ................................. 36
4.1.3.3 Concurrency of Data and Control .............. 36
4.1.3.4 FTP Restart Mechanism ........................ 36
4.1.4 FTP/USER INTERFACE ................................ 39
Internet Engineering Task Force [Page 2]
RFC1123 INTRODUCTION October 1989
4.1.4.1 Pathname Specification ....................... 39
4.1.4.2 "QUOTE" Command .............................. 40
4.1.4.3 Displaying Replies to User ................... 40
4.1.4.4 Maintaining Synchronization .................. 40
4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41
4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44
4.2.1 INTRODUCTION ...................................... 44
4.2.2 PROTOCOL WALK-THROUGH ............................. 44
4.2.2.1 Transfer Modes ............................... 44
4.2.2.2 UDP Header ................................... 44
4.2.3 SPECIFIC ISSUES ................................... 44
4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44
4.2.3.2 Timeout Algorithms ........................... 46
4.2.3.3 Extensions ................................... 46
4.2.3.4 Access Control ............................... 46
4.2.3.5 Broadcast Request ............................ 46
4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47
5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48
5.1 INTRODUCTION ........................................... 48
5.2 PROTOCOL WALK-THROUGH .................................. 48
5.2.1 The SMTP Model .................................... 48
5.2.2 Canonicalization .................................. 49
5.2.3 VRFY and EXPN Commands ............................ 50
5.2.4 SEND, SOML, and SAML Commands ..................... 50
5.2.5 HELO Command ...................................... 50
5.2.6 Mail Relay ........................................ 51
5.2.7 RCPT Command ...................................... 52
5.2.8 DATA Command ...................................... 53
5.2.9 Command Syntax .................................... 54
5.2.10 SMTP Replies ..................................... 54
5.2.11 Transparency ..................................... 55
5.2.12 WKS Use in MX Processing ......................... 55
5.2.13 RFC-822 Message Specification .................... 55
5.2.14 RFC-822 Date and Time Specification .............. 55
5.2.15 RFC-822 Syntax Change ............................ 56
5.2.16 RFC-822 Local-part .............................. 56
5.2.17 Domain Literals .................................. 57
5.2.18 Common Address Formatting Errors ................. 58
5.2.19 Explicit Source Routes ........................... 58
5.3 SPECIFIC ISSUES ........................................ 59
5.3.1 SMTP Queueing Strategies .......................... 59
5.3.1.1 Sending Strategy .............................. 59
5.3.1.2 Receiving strategy ........................... 61
5.3.2 Timeouts in SMTP .................................. 61
5.3.3 Reliable Mail Receipt ............................. 63
5.3.4 Reliable Mail Transmission ........................ 63
5.3.5 Domain Name Support ............................... 65
Internet Engineering Task Force [Page 3]
RFC1123 INTRODUCTION October 1989
5.3.6 Mailing Lists and Aliases ......................... 65
5.3.7 Mail Gatewaying ................................... 66
5.3.8 Maximum Message Size .............................. 68
5.4 SMTP REQUIREMENTS SUMMARY .............................. 69
6. SUPPORT SERVICES ............................................ 72
6.1 DOMAIN NAME TRANSLATION ................................. 72
6.1.1 INTRODUCTION ....................................... 72
6.1.2 PROTOCOL WALK-THROUGH ............................. 72
6.1.2.1 Resource Records with Zero TTL ............... 73
6.1.2.2 QCLASS Values ................................ 73
6.1.2.3 Unused Fields ................................ 73
6.1.2.4 Compression .................................. 73
6.1.2.5 Misusing Configuration Info .................. 73
6.1.3 SPECIFIC ISSUES ................................... 74
6.1.3.1 Resolver Implementation ...................... 74
6.1.3.2 Transport Protocols .......................... 75
6.1.3.3 Efficient Resource Usage ..................... 77
6.1.3.4 Multihomed Hosts ............................. 78
6.1.3.5 Extensibility ................................ 79
6.1.3.6 Status of RR Types ........................... 79
6.1.3.7 Robustness ................................... 80
6.1.3.8 Local Host Table ............................. 80
6.1.4 DNS USER INTERFACE ................................ 81
6.1.4.1 DNS Administration ........................... 81
6.1.4.2 DNS User Interface ........................... 81
6.1.4.3 Interface Abbreviation Facilities ............. 82
6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84
6.2 HOST INITIALIZATION .................................... 87
6.2.1 INTRODUCTION ...................................... 87
6.2.2 REQUIREMENTS ...................................... 87
6.2.2.1 Dynamic Configuration ........................ 87
6.2.2.2 Loading Phase ................................ 89
6.3 REMOTE MANAGEMENT ...................................... 90
6.3.1 INTRODUCTION ...................................... 90
6.3.2 PROTOCOL WALK-THROUGH ............................. 90
6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92
7. REFERENCES ................................................. 93
Internet Engineering Task Force [Page 4]
RFC1123 INTRODUCTION October 1989
1.
This document is one of a pair that defines and discusses
requirements for host system implementations of the Internet
suite. This RFC covers the applications layer and support protocols
Its companion RFC, "Requirements for Internet Hosts --
Layers" [INTRO:1] covers the lower layer protocols: transport layer
IP layer, and link layer
These documents are intended to provide guidance for vendors
implementors, and users of Internet communication software.
represent the consensus of a large body of technical experience
wisdom, contributed by members of the Internet research and
communities
This RFC enumerates standard protocols that a host connected to
Internet must use, and it incorporates by reference the RFCs
other documents describing the current specifications for
protocols. It corrects errors in the referenced documents and
additional discussion and guidance for an implementor
For each protocol, this document also contains an explicit set
requirements, recommendations, and options. The reader
understand that the list of requirements in this document
incomplete by itself; the complete set of requirements for
Internet host is primarily defined in the standard
specification documents, with the corrections, amendments,
supplements contained in this RFC
A good-faith implementation of the protocols that was produced
careful reading of the RFC's and with some interaction with
Internet technical community, and that followed good
software engineering practices, should differ from the
of this document in only minor ways. Thus, in many cases,
"requirements" in this RFC are already stated or implied in
standard protocol documents, so that their inclusion here is, in
sense, redundant. However, they were included because some
implementation has made the wrong choice, causing problems
interoperability, performance, and/or robustness
This document includes discussion and explanation of many of
requirements and recommendations. A simple list of
would be dangerous, because
o Some required features are more important than others, and
features are optional
o There may be valid reasons why particular vendor products
Internet Engineering Task Force [Page 5]
RFC1123 INTRODUCTION October 1989
are designed for restricted contexts might choose to
different specifications
However, the specifications of this document must be followed to
the general goal of arbitrary host interoperation across
diversity and complexity of the Internet system. Although
current implementations fail to meet these requirements in
ways, some minor and some major, this specification is the
towards which we need to move
These requirements are based on the current level of
architecture. This document will be updated as required to
additional clarifications or to include additional information
those areas in which specifications are still evolving
This introductory section begins with general advice to host
vendors, and then gives some guidance on reading the rest of
document. Section 2 contains general requirements that may
applicable to all application and support protocols. Sections 3, 4,
and 5 contain the requirements on protocols for the three
applications: Telnet, file transfer, and electronic mail
respectively. Section 6 covers the support applications: the
name system, system initialization, and management. Finally,
references will be found in Section 7.
1.1 The Internet
For a brief introduction to the Internet architecture from a
viewpoint, see Section 1.1 of [INTRO:1]. That section
contains recommended references for general background on
Internet architecture
1.2 General
There are two important lessons that vendors of Internet
software have learned and which a new vendor should
seriously
1.2.1 Continuing Internet
The enormous growth of the Internet has revealed problems
management and scaling in a large datagram-based
communication system. These problems are being addressed,
as a result there will be continuing evolution of
specifications described in this document. These changes
be carefully planned and controlled, since there is
participation in this planning by the vendors and by
organizations responsible for operations of the networks
Internet Engineering Task Force [Page 6]
RFC1123 INTRODUCTION October 1989
Development, evolution, and revision are characteristic
computer network protocols today, and this situation
persist for some years. A vendor who develops
communication software for the Internet protocol suite (or
other protocol suite!) and then fails to maintain and
that software for changing specifications is going to leave
trail of unhappy customers. The Internet is a
communication network, and the users are in constant
through it. Experience has shown that knowledge
deficiencies in vendor software propagates quickly through
Internet technical community
1.2.2 Robustness
At every layer of the protocols, there is a general rule
application can lead to enormous benefits in robustness
interoperability
"Be liberal in what you accept,
conservative in what you send
Software should be written to deal with every
error, no matter how unlikely; sooner or later a packet
come in with that particular combination of errors
attributes, and unless the software is prepared, chaos
ensue. In general, it is best to assume that the network
filled with malevolent entities that will send in
designed to have the worst possible effect. This
will lead to suitable protective design, although the
serious problems in the Internet have been caused
unenvisaged mechanisms triggered by low-probability events
mere human malice would never have taken so devious a course
Adaptability to change must be designed into all levels
Internet host software. As a simple example, consider
protocol specification that contains an enumeration of
for a particular header field -- e.g., a type field, a
number, or an error code; this enumeration must be assumed
be incomplete. Thus, if a protocol specification defines
possible error codes, the software must not break when a
code shows up. An undefined code might be logged (see below),
but it must not cause a failure
The second part of the principle is almost as important
software on other hosts may contain deficiencies that make
unwise to exploit legal but obscure protocol features. It
unwise to stray far from the obvious and simple, lest
effects result elsewhere. A corollary of this is "watch
Internet Engineering Task Force [Page 7]
RFC1123 INTRODUCTION October 1989
for misbehaving hosts"; host software should be prepared,
just to survive other misbehaving hosts, but also to
to limit the amount of disruption such hosts can cause to
shared communication facility
1.2.3 Error
The Internet includes a great variety of host and
systems, each implementing many protocols and protocol layers
and some of these contain bugs and mis-features in
Internet protocol software. As a result of complexity
diversity, and distribution of function, the diagnosis of
problems is often very difficult
Problem diagnosis will be aided if host implementations
a carefully designed facility for logging erroneous
"strange" protocol events. It is important to include as
diagnostic information as possible when an error is logged.
particular, it is often useful to record the header(s) of
packet that caused an error. However, care must be taken
ensure that error logging does not consume prohibitive
of resources or otherwise interfere with the operation of
host
There is a tendency for abnormal but harmless protocol
to overflow error logging files; this can be avoided by using
"circular" log, or by enabling logging only while diagnosing
known failure. It may be useful to filter and count
successive messages. One strategy that seems to work well is
(1) always count abnormalities and make such counts
through the management protocol (see Section 6.3); and (2)
allow the logging of a great variety of events to
selectively enabled. For example, it might useful to be
to "log everything" or to "log everything for host X".
Note that different managements may have differing
about the amount of error logging that they want
enabled in a host. Some will say, "if it doesn't hurt me,
don't want to know about it", while others will want to take
more watchful and aggressive attitude about detecting
removing protocol abnormalities
1.2.4
It would be ideal if a host implementation of the
protocol suite could be entirely self-configuring. This
allow the whole suite to be implemented in ROM or cast
silicon, it would simplify diskless workstations, and it
Internet Engineering Task Force [Page 8]
RFC1123 INTRODUCTION October 1989
be an immense boon to harried LAN administrators as well
system vendors. We have not reached this ideal; in fact,
are not even close
At many points in this document, you will find a
that a parameter be a configurable option. There are
different reasons behind such requirements. In a few cases
there is current uncertainty or disagreement about the
value, and it may be necessary to update the recommended
in the future. In other cases, the value really depends
external factors -- e.g., the size of the host and
distribution of its communication load, or the speeds
topology of nearby networks -- and self-tuning algorithms
unavailable and may be insufficient. In some cases
configurability is needed because of
requirements
Finally, some configuration options are required to
with obsolete or incorrect implementations of the protocols
distributed without sources, that unfortunately persist in
parts of the Internet. To make correct systems coexist
these faulty systems, administrators often have to "mis
configure" the correct systems. This problem will
itself gradually as the faulty systems are retired, but
cannot be ignored by vendors
When we say that a parameter must be configurable, we do
intend to require that its value be explicitly read from
configuration file at every boot time. We recommend
implementors set up a default for each parameter, so
configuration file is only necessary to override those
that are inappropriate in a particular installation. Thus,
configurability requirement is an assurance that it will
POSSIBLE to override the default when necessary, even in
binary-only or ROM-based product
This document requires a particular value for such defaults
some cases. The choice of default is a sensitive issue
the configuration item controls the accommodation to
faulty systems. If the Internet is to converge successfully
complete interoperability, the default values built
implementations must implement the official protocol,
"mis-configurations" to accommodate faulty implementations
Although marketing considerations have led some vendors
choose mis-configuration defaults, we urge vendors to
defaults that will conform to the standard
Finally, we note that a vendor needs to provide
Internet Engineering Task Force [Page 9]
RFC1123 INTRODUCTION October 1989
documentation on all configuration parameters, their limits
effects
1.3 Reading this
1.3.1
In general, each major section is organized into the
subsections
(1)
(2) Protocol Walk-Through -- considers the
specification documents section-by-section,
errors, stating requirements that may be ambiguous
ill-defined, and providing further clarification
explanation
(3) Specific Issues -- discusses protocol design
implementation issues that were not included in the walk
through
(4) Interfaces -- discusses the service interface to the
higher layer
(5) Summary -- contains a summary of the requirements of
section
Under many of the individual topics in this document, there
parenthetical material labeled "DISCUSSION"
"IMPLEMENTATION". This material is intended to
clarification and explanation of the preceding
text. It also includes some suggestions on possible
directions or developments. The implementation
contains suggested approaches that an implementor may want
consider
The summary sections are intended to be guides and indexes
the text, but are necessarily cryptic and incomplete.
summaries should never be used or referenced separately
the complete RFC
1.3.2
In this document, the words that are used to define
significance of each particular requirement are capitalized
These words are
Internet Engineering Task Force [Page 10]
RFC1123 INTRODUCTION October 1989
* "MUST
This word or the adjective "REQUIRED" means that the
is an absolute requirement of the specification
* "SHOULD
This word or the adjective "RECOMMENDED" means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications should
understood and the case carefully weighed before
a different course
* "MAY
This word or the adjective "OPTIONAL" means that this
is truly optional. One vendor may choose to include
item because a particular marketplace requires it
because it enhances the product, for example;
vendor may omit the same item
An implementation is not compliant if it fails to satisfy
or more of the MUST requirements for the protocols
implements. An implementation that satisfies all the MUST
all the SHOULD requirements for its protocols is said to
"unconditionally compliant"; one that satisfies all the
requirements but not all the SHOULD requirements for
protocols is said to be "conditionally compliant".
1.3.3
This document uses the following technical terms
A segment is the unit of end-to-end transmission in
TCP protocol. A segment consists of a TCP header
by application data. A segment is transmitted
encapsulation in an IP datagram
This term is used by some application layer
(particularly SMTP) for an application data unit
A [UDP] datagram is the unit of end-to-end transmission
the UDP protocol
Internet Engineering Task Force [Page 11]
RFC1123 INTRODUCTION October 1989
A host is said to be multihomed if it has multiple
addresses to connected networks
1.4
This document incorporates contributions and comments from a
group of Internet protocol experts, including representatives
university and research labs, vendors, and government agencies
It was assembled primarily by the Host Requirements Working
of the Internet Engineering Task Force (IETF).
The Editor would especially like to acknowledge the
dedication of the following people, who attended many
meetings and generated 3 million bytes of electronic mail over
past 18 months in pursuit of this document: Philip Almquist,
Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC),
Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig
(BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
In addition, the following people made major contributions to
effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike
(BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA),
Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff
(DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (
Technology), and Mike StJohns (DCA). The following also
significant contributions to particular areas: Eric
(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith
(Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt
(IBM), Erik Naggum (Naggum Software, Norway), Robert
(Prime Computer), David Waitzman (BBN), Frank Wancho (USA),
Welch (Ohio State), Bill Westfield (Cisco), and Rayan
(Toronto).
We are grateful to all, including any contributors who may
been inadvertently omitted from this list
Internet Engineering Task Force [Page 12]
RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
2. GENERAL
This section contains general requirements that may be applicable
all application-layer protocols
2.1 Host Names and
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed:
restriction on the first character is relaxed to allow either
letter or a digit. Host software MUST support this more
syntax
Host software MUST handle host names of up to 63 characters
SHOULD handle host names of up to 255 characters
Whenever a user inputs the identity of an Internet host, it
be possible to enter either (1) a host domain name or (2) an
address in dotted-decimal ("#.#.#.#") form. The host SHOULD
the string syntactically for a dotted-decimal number
looking it up in the Domain Name System
DISCUSSION
This last requirement is not intended to specify the
syntactic form for entering a dotted-decimal host number
that is considered to be a user-interface issue.
example, a dotted-decimal number must be enclosed
"[ ]" brackets for SMTP mail (see Section 5.2.17).
notation could be made universal within a host system
simplifying the syntactic checking for a dotted-
number
If a dotted-decimal number can be entered without
identifying delimiters, then a full syntactic check must
made, because a segment of a host domain name is now
to begin with a digit and could legally be entirely
(see Section 6.1.2.4). However, a valid host name can
have the dotted-decimal form #.#.#.#, since at least
highest-level component label will be alphabetic
2.2 Using Domain Name
Host domain names MUST be translated to IP addresses as
in Section 6.1.
Applications using domain name services MUST be able to cope
soft error conditions. Applications MUST wait a
interval between successive retries due to a soft error, and
Internet Engineering Task Force [Page 13]
RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
allow for the possibility that network problems may deny
for hours or even days
An application SHOULD NOT rely on the ability to locate a
record containing an accurate listing of all services at
particular host address, since the WKS RR type is not often
by Internet sites. To confirm that a service is present,
attempt to use it
2.3 Applications on Multihomed
When the remote host is multihomed, the name-to-
translation will return a list of alternative IP addresses.
specified in Section 6.1.3.4, this list should be in order
decreasing preference. Application protocol
SHOULD be prepared to try multiple addresses from the list
success is obtained. More specific requirements for SMTP
given in Section 5.3.4.
When the local host is multihomed, a UDP-based request/
application SHOULD send the response with an IP source
that is the same as the specific destination address of the
request datagram. The "specific destination address" is
in the "IP Addressing" section of the companion RFC [INTRO:1].
Similarly, a server application that opens multiple
connections to the same client SHOULD use the same local
address for all
2.4 Type-of-
Applications MUST select appropriate TOS values when they
transport layer services, and these values MUST be configurable
Note that a TOS value contains 5 bits, of which only the most
significant 3 bits are currently defined; the other two bits
be zero
DISCUSSION
As gateway algorithms are developed to implement Type-of
Service, the recommended values for various
protocols may change. In addition, it is likely
particular combinations of users and Internet paths will
non-standard TOS values. For these reasons, the TOS
must be configurable
See the latest version of the "Assigned Numbers"
[INTRO:5] for the recommended TOS values for the
application protocols
Internet Engineering Task Force [Page 14]
RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
2.5 GENERAL APPLICATION REQUIREMENTS
| | | | |S| |
| | | | |H| |
| | | | |O|M|
| | |S| |U|U|
| | |H| |L|S|
| |M|O| |D|T|
| |U|U|M| | |
| |S|L|A|N|N|
| |T|D|Y|O|O|
FEATURE |SECTION | | | |T|T|
-----------------------------------------------|----------|-|-|-|-|-|--
| | | | | | |
User interfaces: | | | | | | |
Allow host name to begin with digit |2.1 |x| | | | |
Host names of up to 635 characters |2.1 |x| | | | |
Host names of up to 255 characters |2.1 | |x| | | |
Support dotted-decimal host numbers |2.1 | |x| | | |
Check syntactically for dotted-dec first |2.1 | |x| | | |
| | | | | | |
Map domain names per Section 6.1 |2.2 |x| | | | |
Cope with soft DNS errors |2.2 |x| | | | |
Reasonable interval between retries |2.2 |x| | | | |
Allow for long outages |2.2 |x| | | | |
Expect WKS records to be available |2.2 | | | |x| |
| | | | | | |
Try multiple addr's for remote multihomed host |2.3 | |x| | | |
UDP reply src addr is specific dest of request |2.3 | |x| | | |
Use same IP addr for related TCP connections |2.3 | |x| | | |
Specify appropriate TOS values |2.4 |x| | | | |
TOS values configurable |2.4 |x| | | | |
Unused TOS bits zero |2.4 |x| | | | |
| | | | | | |
| | | | | | |
Internet Engineering Task Force [Page 15]
RFC1123 REMOTE LOGIN -- TELNET October 1989
3. REMOTE LOGIN -- TELNET
3.1
Telnet is the standard Internet application protocol for
login. It provides the encoding rules to link a user'
keyboard/display on a client ("user") system with a
interpreter on a remote server system. A subset of the
protocol is also incorporated within other application protocols
e.g., FTP and SMTP
Telnet uses a single TCP connection, and its normal data
("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII
escape sequences to embed control functions. Telnet also
the negotiation of many optional modes and functions
The primary Telnet specification is to be found in RFC-854
[TELNET:1], while the options are defined in many other RFCs;
Section 7 for references
3.2 PROTOCOL WALK-
3.2.1 Option Negotiation: RFC-854, pp. 2-3
Every Telnet implementation MUST include option negotiation
subnegotiation machinery [TELNET:2].
A host MUST carefully follow the rules of RFC-854 to
option-negotiation loops. A host MUST refuse (i.e,
WONT/DONT to a DO/WILL) an unsupported option.
negotiation SHOULD continue to function (even if all
are refused) throughout the lifetime of a Telnet connection
If all option negotiations fail, a Telnet implementation
default to, and support, an NVT
DISCUSSION
Even though more sophisticated "terminals" and
option negotiations are becoming the norm,
implementations must be prepared to support an NVT for
user-server communication
3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
On a host that never sends the Telnet command Go Ahead (GA),
the Telnet Server MUST attempt to negotiate the Suppress
Ahead option (i.e., send "WILL Suppress Go Ahead"). A User
Server Telnet MUST always accept negotiation of the Suppress
Internet Engineering Task Force [Page 16]
RFC1123 REMOTE LOGIN -- TELNET October 1989
Ahead option
When it is driving a full-duplex terminal for which GA has
meaning, a User Telnet implementation MAY ignore GA commands
DISCUSSION
Half-duplex ("locked-keyboard") line-at-a-time
for which the Go-Ahead mechanism was designed have
disappeared from the scene. It turned out to be
to implement sending the Go-Ahead signal in many
systems, even some systems that support native half-
terminals. The difficulty is typically that the
server code does not have access to information
whether the user process is blocked awaiting input
the Telnet connection, i.e., it cannot reliably
when to send a GA command. Therefore, most Telnet
hosts do not send GA commands
The effect of the rules in this section is to allow
end of a Telnet connection to veto the use of GA commands
There is a class of half-duplex terminals that is
commercially important: "data entry terminals,"
interact in a full-screen manner. However,
data entry terminals using the Telnet protocol does
require the Go Ahead signal; see Section 3.3.2.
3.2.3 Control Functions: RFC-854, pp. 7-8
The list of Telnet commands has been extended to include
(End-of-Record), with code 239 [TELNET:9].
Both User and Server Telnets MAY support the control
EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP
SB, and SE
A host MUST be able to receive and ignore any Telnet
functions that it does not support
DISCUSSION
Note that a Server Telnet is required to support
Telnet IP (Interrupt Process) function, even if the
host has an equivalent in-stream function (e.g., Control-
in many systems). The Telnet IP function may be
than an in-stream interrupt command, because of the out
of-band effect of TCP urgent data
The EOR control function may be used to delimit
Internet Engineering Task Force [Page 17]
RFC1123 REMOTE LOGIN -- TELNET October 1989
stream. An important application is data entry
support (see Section 3.3.2). There was concern that
EOR had not been defined in RFC-854, a host that was
prepared to correctly ignore unknown Telnet commands
crash if it received an EOR. To protect such hosts,
End-of-Record option [TELNET:9] was introduced; however,
properly implemented Telnet program will not require
protection
3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10
When it receives "urgent" TCP data, a User or Server
MUST discard all data except Telnet commands until the DM (
end of urgent) is reached
When it sends Telnet IP (Interrupt Process), a User
SHOULD follow it by the Telnet "Synch" sequence, i.e., send
TCP urgent data the sequence "IAC IP IAC DM". The TCP
pointer points to the DM octet
When it receives a Telnet IP command, a Server Telnet MAY
a Telnet "Synch" sequence back to the user, to flush the
stream. The choice ought to be consistent with the way
server operating system behaves when a local user interrupts
process
When it receives a Telnet AO command, a Server Telnet MUST
a Telnet "Synch" sequence back to the user, to flush the
stream
A User Telnet SHOULD have the capability of flushing
when it sends a Telnet IP; see also Section 3.4.5.
DISCUSSION
There are three possible ways for a User Telnet to
the stream of server output data
(1) Send AO after IP
This will cause the server host to send a "flush
buffered-output" signal to its operating system
However, the AO may not take effect locally, i.e.,
stop terminal output at the User Telnet end,
the Server Telnet has received and processed the
and has sent back a "Synch".
(2) Send DO TIMING-MARK [TELNET:7] after IP, and
all output locally until a WILL/WONT TIMING-MARK
Internet Engineering Task Force [Page 18]
RFC1123 REMOTE LOGIN -- TELNET October 1989
received from the Server Telnet
Since the DO TIMING-MARK will be processed after
IP at the server, the reply to it should be in
right place in the output data stream. However,
TIMING-MARK will not send a "flush buffered output
signal to the server operating system. Whether
not this is needed is dependent upon the
system
(3) Do both
The best method is not entirely clear, since it
accommodate a number of existing server hosts that do
follow the Telnet standards in various ways. The
approach is probably to provide a user-controllable
to select (1), (2), or (3).
3.2.5 NVT Printer and Keyboard: RFC-854, p. 11
In NVT mode, a Telnet SHOULD NOT send characters with
high-order bit 1, and MUST NOT send it as a parity bit
Implementations that pass the high-order bit to
SHOULD negotiate binary mode (see Section 3.2.6).
DISCUSSION
Implementors should be aware that a strict reading
RFC-854 allows a client or server expecting NVT ASCII
ignore characters with the high-order bit set.
general, binary mode is expected to be used
transmission of an extended (beyond 7-bit) character
with Telnet
However, there exist applications that really need an 8-
bit NVT mode, which is currently not defined, and
existing applications do set the high-order bit
part or all of the life of a Telnet connection. Note
binary mode is not the same as 8-bit NVT mode,
binary mode turns off end-of-line processing. For
reason, the requirements on the high-order bit are
as SHOULD, not MUST
RFC-854 defines a minimal set of properties of a "
virtual terminal" or NVT; this is not meant to
additional features in a real terminal. A
connection is fully transparent to all 7-bit
characters, including arbitrary ASCII control characters
Internet Engineering Task Force [Page 19]
RFC1123 REMOTE LOGIN -- TELNET October 1989
For example, a terminal might support full-screen
coded as ASCII escape sequences; a Telnet
would pass these sequences as uninterpreted data. Thus
an NVT should not be conceived as a terminal type of
highly-restricted device
3.2.6 Telnet Command Structure: RFC-854, p. 13
Since options may appear at any point in the data stream,
Telnet escape character (known as IAC, with the value 255)
be sent as data MUST be doubled
3.2.7 Telnet Binary Option: RFC-856
When the Binary option has been successfully negotiated
arbitrary 8-bit characters are allowed. However, the
stream MUST still be scanned for IAC characters, any
Telnet commands MUST be obeyed, and data bytes equal to
MUST be doubled. Other character processing (e.g.,
CR by CR NUL or by CR LF) MUST NOT be done. In particular
there is no end-of-line convention (see Section 3.3.1)
binary mode
DISCUSSION
The Binary option is normally negotiated in
directions, to change the Telnet connection from NVT
to "binary mode".
The sequence IAC EOR can be used to delimit blocks of
within a binary-mode Telnet stream
3.2.8 Telnet Terminal-Type Option: RFC-1091
The Terminal-Type option MUST use the terminal type
officially defined in the Assigned Numbers RFC [INTRO:5],
they are available for the particular terminal. However,
receiver of a Terminal-Type option MUST accept any name
DISCUSSION
RFC-1091 [TELNET:10] updates an earlier version of
Terminal-Type option defined in RFC-930. The
version allowed a server host capable of
multiple terminal types to learn the type of a
client's terminal, assuming that each physical
had an intrinsic type. However, today a "terminal"
often really a terminal emulator program running in a PC
perhaps capable of emulating a range of terminal types
Therefore, RFC-1091 extends the specification to allow
Internet Engineering Task Force [Page 20]
RFC1123 REMOTE LOGIN -- TELNET October 1989
more general terminal-type negotiation between User
Server Telnets
3.3 SPECIFIC
3.3.1 Telnet End-of-Line
The Telnet protocol defines the sequence CR LF to mean "end
of-line". For terminal input, this corresponds to a command
completion or "end-of-line" key being pressed on a
terminal; on an ASCII terminal, this is the CR key, but it
also be labelled "Return" or "Enter".
When a Server Telnet receives the Telnet end-of-line
CR LF as input from a remote terminal, the effect MUST be
same as if the user had pressed the "end-of-line" key on
local terminal. On server hosts that use ASCII, in particular
receipt of the Telnet sequence CR LF must cause the same
as a local user pressing the CR key on a local terminal. Thus
CR LF and CR NUL MUST have the same effect on an ASCII
host when received as input over a Telnet connection
A User Telnet MUST be able to send any of the forms: CR LF,
NUL, and LF. A User Telnet on an ASCII host SHOULD have
user-controllable mode to send either CR LF or CR NUL when
user presses the "end-of-line" key, and CR LF SHOULD be
default
The Telnet end-of-line sequence CR LF MUST be used to
Telnet data that is not terminal-to-computer (e.g., for
Telnet sending output, or the Telnet protocol
another application protocol).
DISCUSSION
To allow interoperability between arbitrary Telnet
and servers, the Telnet protocol defined a
representation for a line terminator. Since the
character set includes no explicit end-of-line character
systems have chosen various representations, e.g., CR, LF
and the sequence CR LF. The Telnet protocol chose the
LF sequence as the standard for network transmission
Unfortunately, the Telnet protocol specification in RFC
854 [TELNET:1] has turned out to be somewhat ambiguous
what character(s) should be sent from client to server
the "end-of-line" key. The result has been a massive
continuing interoperability headache, made worse
various faulty implementations of both User and
Internet Engineering Task Force [Page 21]
RFC1123 REMOTE LOGIN -- TELNET October 1989
Telnets
Although the Telnet protocol is based on a
symmetric model, in a remote login session the role of
user at a terminal differs from the role of the
host. For example, RFC-854 defines the meaning of CR, LF
and CR LF as output from the server, but does not
what the User Telnet should send when the user presses
"end-of-line" key on the terminal; this turns out to
the point at issue
When a user presses the "end-of-line" key, some
Telnet implementations send CR LF, while others send
NUL (based on a different interpretation of the
sentence in RFC-854). These will be equivalent for
correctly-implemented ASCII server host, as
above. For other servers, a mode in the User Telnet
needed
The existence of User Telnets that send only CR NUL
CR is pressed creates a dilemma for non-ASCII hosts:
can either treat CR NUL as equivalent to CR LF in input
thus precluding the possibility of entering a "bare" CR
or else lose complete interworking
Suppose a user on host A uses Telnet to log into a
host B, and then execute B's User Telnet program to
into server host C. It is desirable for the Server/
Telnet combination on B to be as transparent as possible
i.e., to appear as if A were connected directly to C.
particular, correct implementation will make B
to Telnet end-of-line sequences, except that CR LF may
translated to CR NUL or vice versa
IMPLEMENTATION
To understand Telnet end-of-line issues, one must have
least a general model of the relationship of Telnet to
local operating system. The Server Telnet process
typically coupled into the terminal driver software of
operating system as a pseudo-terminal. A Telnet end-of
line sequence received by the Server Telnet must have
same effect as pressing the end-of-line key on a
locally-connected terminal
Operating systems that support interactive character-at
a-time applications (e.g., editors) typically have
internal modes for their terminal I/O: a formatted mode
in which local conventions for end-of-line and
Internet Engineering Task Force [Page 22]
RFC1123 REMOTE LOGIN -- TELNET October 1989
formatting rules have been applied to the data stream,
a "raw" mode, in which the application has direct
to every character as it was entered. A Server
must be implemented in such a way that these modes
the same effect for remote as for local terminals.
example, suppose a CR LF or CR NUL is received by
Server Telnet on an ASCII host. In raw mode, a
character is passed to the application; in formatted mode
the local system's end-of-line convention is used
3.3.2 Data Entry
DISCUSSION
In addition to the line-oriented and character-
ASCII terminals for which Telnet was designed, there
several families of video display terminals that
sometimes known as "data entry terminals" or DETs.
IBM 3270 family is a well-known example
Two Internet protocols have been designed to
generic DETs: SUPDUP [TELNET:16, TELNET:17], and the
option [TELNET:18, TELNET:19]. The DET option drives
data entry terminal over a Telnet connection using (sub-)
negotiation. SUPDUP is a completely separate
protocol, which can be entered from Telnet by negotiation
Although both SUPDUP and the DET option have been
successfully in particular environments, neither
gained general acceptance or wide implementation
A different approach to DET interaction has been
for supporting the IBM 3270 family through Telnet
although the same approach would be applicable to any DET
The idea is to enter a "native DET" mode, in which
native DET input/output stream is sent as binary data
The Telnet EOR command is used to delimit logical
(e.g., "screens") within this binary stream
IMPLEMENTATION
The rules for entering and leaving native DET mode are
follows
o The Server uses the Terminal-Type option [TELNET:10]
to learn that the client is a DET
o It is conventional, but not required, that both
negotiate the EOR option [TELNET:9].
o Both ends negotiate the Binary option [TELNET:3]
Internet Engineering Task Force [Page 23]
RFC1123 REMOTE LOGIN -- TELNET October 1989
enter native DET mode
o When either end negotiates out of binary mode,
other end does too, and the mode then reverts
normal NVT
3.3.3 Option
Every Telnet implementation MUST support the Binary
[TELNET:3] and the Suppress Go Ahead option [TELNET:5],
SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of
Record [TELNET:9], and Extended Options List [TELNET:8]
options
A User or Server Telnet SHOULD support the Window Size
[TELNET:12] if the local operating system provides
corresponding capability
DISCUSSION
Note that the End-of-Record option only signifies that
Telnet can receive a Telnet EOR without crashing
therefore, every Telnet ought to be willing to
negotiation of the End-of-Record option. See also
discussion in Section 3.2.3.
3.3.4 Option
When the Telnet protocol is used in a client/server situation
the server SHOULD initiate negotiation of the
interaction mode it expects
DISCUSSION
The Telnet protocol was defined to be
symmetrical, but its application is generally asymmetric
Remote login has been known to fail because NEITHER
initiated negotiation of the required non-default
modes. It is generally the server that determines
preferred mode, so the server needs to initiate
negotiation; since the negotiation is symmetric, the
can also initiate it
A client (User Telnet) SHOULD provide a means for users
enable and disable the initiation of option negotiation
DISCUSSION
A user sometimes needs to connect to an
service (e.g., FTP or SMTP) that uses Telnet for
Internet Engineering Task Force [Page 24]
RFC1123 REMOTE LOGIN -- TELNET October 1989
control stream but does not support Telnet options.
Telnet may be used for this purpose if initiation
option negotiation is disabled
3.3.5 Telnet Linemode
DISCUSSION
An important new Telnet option, LINEMODE [TELNET:12],
been proposed. The LINEMODE option provides a
way for a User Telnet and a Server Telnet to agree
the client rather than the server will perform
character processing. When the client has prepared
complete line of text, it will send it to the server
(usually) one TCP packet. This option will
decrease the packet cost of Telnet sessions and will
give much better user response over congested or long
delay networks
The LINEMODE option allows dynamic switching between
and remote character processing. For example, the
connection will automatically negotiate into single
character mode while a full screen editor is running,
then return to linemode when the editor is finished
We expect that when this RFC is released, hosts
implement the client side of this option, and
implement the server side of this option. To
implement the server side, the server needs to be able
tell the local system not to do any input
processing, but to remember its current terminal state
notify the Server Telnet process whenever the
changes. This will allow password echoing and full
editors to be handled properly, for example
3.4 TELNET/USER
3.4.1 Character Set
User Telnet implementations SHOULD be able to send or
any 7-bit ASCII character. Where possible, any
character interpretations by the user host's operating
SHOULD be bypassed so that these characters can conveniently
sent and received on the connection
Some character value MUST be reserved as "escape to
mode"; conventionally, doubling this character allows it to
entered as data. The specific character used SHOULD be
selectable
Internet Engineering Task Force [Page 25]
RFC1123 REMOTE LOGIN -- TELNET October 1989
On binary-mode connections, a User Telnet program MAY
an escape mechanism for entering arbitrary 8-bit values, if
host operating system doesn't allow them to be entered
from the keyboard
IMPLEMENTATION
The transparency issues are less pressing on servers,
implementors should take care in dealing with issues like
masking off parity bits (sent by an older, non-
client) before they reach programs that expect only
ASCII, and properly handling programs that request 8-
data streams
3.4.2 Telnet
A User Telnet program MUST provide a user the capability
entering any of the Telnet control functions IP, AO, or AYT
and SHOULD provide the capability of entering EC, EL,
Break
3.4.3 TCP Connection
A User Telnet program SHOULD report to the user any TCP
that are reported by the transport layer (see "TCP/
Layer Interface" section in [INTRO:1]).
3.4.4 Non-Default Telnet Contact
A User Telnet program SHOULD allow the user to
specify a non-standard contact port number at the Server
host
3.4.5 Flushing
A User Telnet program SHOULD provide the user the ability
specify whether or not output should be flushed when an IP
sent; see Section 3.2.4.
For any output flushing scheme that causes the User Telnet
flush output locally until a Telnet signal is received from
Server, there SHOULD be a way for the user to manually
normal output, in case the Server fails to send the
signal
Internet Engineering Task Force [Page 26]
RFC1123 REMOTE LOGIN -- TELNET October 1989
3.5. TELNET REQUIREMENTS
| | | | |S| |
| | | | |H| |
| | | | |O|M|
| | |S| |U|U|
| | |H| |L|S|
| |M|O| |D|T|
| |U|U|M| | |
| |S|L|A|N|N|
| |T|D|Y|O|O|
FEATURE |SECTION | | | |T|T|
-------------------------------------------------|--------|-|-|-|-|-|--
| | | | | | |
Option Negotiation |3.2.1 |x| | | | |
Avoid negotiation loops |3.2.1 |x| | | | |
Refuse unsupported options |3.2.1 |x| | | | |
Negotiation OK anytime on connection |3.2.1 | |x| | | |
Default to NVT |3.2.1 |x| | | | |
Send official name in Term-Type option |3.2.8 |x| | | | |
Accept any name in Term-Type option |3.2.8 |x| | | | |
Implement Binary, Suppress-GA options |3.3.3 |x| | | | |
Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | |
Implement Window-Size option if appropriate |3.3.3 | |x| | | |
Server initiate mode negotiations |3.3.4 | |x| | | |
User can enable/disable init negotiations |3.3.4 | |x| | | |
| | | | | | |
Go-Aheads | | | | | | |
Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | |
User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | |
User Telnet ignore GA's |3.2.2 | | |x| | |
| | | | | | |
Control Functions | | | | | | |
Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | |
Support EOR EC EL Break |3.2.3 | | |x| | |
Ignore unsupported control functions |3.2.3 |x| | | | |
User, Server discard urgent data up to DM |3.2.4 |x| | | | |
User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | |
Server Telnet reply Synch to IP |3.2.4 | | |x| | |
Server Telnet reply Synch to AO |3.2.4 |x| | | | |
User Telnet can flush output when send IP |3.2.4 | |x| | | |
| | | | | | |
Encoding | | | | | | |
Send high-order bit in NVT mode |3.2.5 | | | |x| |
Send high-order bit as parity bit |3.2.5 | | | | |x
Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | |
Always double IAC data byte |3.2.6 |x| | | | |
Internet Engineering Task Force [Page 27]
RFC1123 REMOTE LOGIN -- TELNET October 1989
Double IAC data byte in binary mode |3.2.7 |x| | | | |
Obey Telnet cmds in binary mode |3.2.7 |x| | | | |
End-of-line, CR NUL in binary mode |3.2.7 | | | | |x
| | | | | | |
End-of-Line | | | | | | |
EOL at Server same as local end-of-line |3.3.1 |x| | | | |
ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | |
User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | |
ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | |
User Telnet default mode is CR LF |3.3.1 | |x| | | |
Non-interactive uses CR LF for EOL |3.3.1 |x| | | | |
| | | | | | |
User Telnet interface | | | | | | |
Input & output all 7-bit characters |3.4.1 | |x| | | |
Bypass local op sys interpretation |3.4.1 | |x| | | |
Escape character |3.4.1 |x| | | | |
User-settable escape character |3.4.1 | |x| | | |
Escape to enter 8-bit values |3.4.1 | | |x| | |
Can input IP, AO, AYT 