Page 1 of 97
`
`>
`
`Network Working Group Internet Engineering Task Force
`Request for Comments: 1123 R. Braden, Editor
`October 1989
`
`Requirements for Internet Hosts --Application and Support
`Status of This Memo
`This RFC is an official specification for the Internet community. It
`incorporates by reference, amends, corrects, and supplements the
`primary protocol standards documents relating to hosts. Distribution
`of this document is unlimited.
`Summary
`This RFC is one of a pair that defines and discusses the requirements
`for Internet host software. This RFC covers the application and
`support protocols; its companion RFC-1122 covers the communication
`protocol layers: link layer, IP layer, and transport layer.
`
`Table of Contents
`
`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]
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 1 of 97
`
`

`
`Page 2 of 97
`
`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]
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 2 of 97
`
`

`
`Page 3 of 97
`
`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]
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 3 of 97
`
`

`
`Page 4 of 97
`
`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]
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 4 of 97
`
`

`
`Page 5 of 97
`
`RFC1123 INTRODUCTION October 1989
`
`1. INTRODUCTION
`This document is one of a pair that defines and discusses the
`requirements for host system implementations of the Internet protocol
`suite. This RFC covers the applications layer and support protocols.
`Its companion RFC, "Requirements for Internet Hosts --Communications
`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. They
`represent the consensus of a large body of technical experience and
`wisdom, contributed by members of the Internet research and vendor
`communities.
`This RFC enumerates standard protocols that a host connected to the
`Internet must use, and it incorporates by reference the RFCs and
`other documents describing the current specifications for these
`protocols. It corrects errors in the referenced documents and adds
`additional discussion and guidance for an implementor.
`For each protocol, this document also contains an explicit set of
`requirements, recommendations, and options. The reader must
`understand that the list of requirements in this document is
`incomplete by itself; the complete set of requirements for an
`Internet host is primarily defined in the standard protocol
`specification documents, with the corrections, amendments, and
`supplements contained in this RFC.
`A good-faith implementation of the protocols that was produced after
`careful reading of the RFC's and with some interaction with the
`Internet technical community, and that followed good communications
`software engineering practices, should differ from the requirements
`of this document in only minor ways. Thus, in many cases, the
`"requirements" in this RFC are already stated or implied in the
`standard protocol documents, so that their inclusion here is, in a
`sense, redundant. However, they were included because some past
`implementation has made the wrong choice, causing problems of
`interoperability, performance, and/or robustness.
`This document includes discussion and explanation of many of the
`requirements and recommendations. A simple list of requirements
`would be dangerous, because:
`o Some required features are more important than others, and some
`features are optional.
`o There may be valid reasons why particular vendor products that
`
`Internet Engineering Task Force [Page 5]
`
`RFC1123 INTRODUCTION October 1989
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 5 of 97
`
`

`
`Page 6 of 97
`
`are designed for restricted contexts might choose to use
`different specifications.
`However, the specifications of this document must be followed to meet
`the general goal of arbitrary host interoperation across the
`diversity and complexity of the Internet system. Although most
`current implementations fail to meet these requirements in various
`ways, some minor and some major, this specification is the ideal
`towards which we need to move.
`These requirements are based on the current level of Internet
`architecture. This document will be updated as required to provide
`additional clarifications or to include additional information in
`those areas in which specifications are still evolving.
`This introductory section begins with general advice to host software
`vendors, and then gives some guidance on reading the rest of the
`document. Section 2 contains general requirements that may be
`applicable to all application and support protocols. Sections 3, 4,
`and 5 contain the requirements on protocols for the three major
`applications: Telnet, file transfer, and electronic mail,
`respectively. Section 6 covers the support applications: the domain
`name system, system initialization, and management. Finally, all
`references will be found in Section 7.
`1.1 The Internet Architecture
`For a brief introduction to the Internet architecture from a host
`viewpoint, see Section 1.1 of [INTRO:1]. That section also
`contains recommended references for general background on the
`Internet architecture.
`1.2 General Considerations
`There are two important lessons that vendors of Internet host
`software have learned and which a new vendor should consider
`seriously.
`1.2.1 Continuing Internet Evolution
`The enormous growth of the Internet has revealed problems of
`management and scaling in a large datagram-based packet
`communication system. These problems are being addressed, and
`as a result there will be continuing evolution of the
`specifications described in this document. These changes will
`be carefully planned and controlled, since there is extensive
`participation in this planning by the vendors and by the
`organizations responsible for operations of the networks.
`
`Internet Engineering Task Force [Page 6]
`
`RFC1123 INTRODUCTION October 1989
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 6 of 97
`
`

`
`Page 7 of 97
`
`Development, evolution, and revision are characteristic of
`computer network protocols today, and this situation will
`persist for some years. A vendor who develops computer
`communication software for the Internet protocol suite (or any
`other protocol suite!) and then fails to maintain and update
`that software for changing specifications is going to leave a
`trail of unhappy customers. The Internet is a large
`communication network, and the users are in constant contact
`through it. Experience has shown that knowledge of
`deficiencies in vendor software propagates quickly through the
`Internet technical community.
`1.2.2 Robustness Principle
`At every layer of the protocols, there is a general rule whose
`application can lead to enormous benefits in robustness and
`interoperability:
`"Be liberal in what you accept, and
`conservative in what you send"
`Software should be written to deal with every conceivable
`error, no matter how unlikely; sooner or later a packet will
`come in with that particular combination of errors and
`attributes, and unless the software is prepared, chaos can
`ensue. In general, it is best to assume that the network is
`filled with malevolent entities that will send in packets
`designed to have the worst possible effect. This assumption
`will lead to suitable protective design, although the most
`serious problems in the Internet have been caused by
`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 of
`Internet host software. As a simple example, consider a
`protocol specification that contains an enumeration of values
`for a particular header field --e.g., a type field, a port
`number, or an error code; this enumeration must be assumed to
`be incomplete. Thus, if a protocol specification defines four
`possible error codes, the software must not break when a fifth
`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 it
`unwise to exploit legal but obscure protocol features. It is
`unwise to stray far from the obvious and simple, lest untoward
`effects result elsewhere. A corollary of this is "watch out
`
`Internet Engineering Task Force [Page 7]
`
`RFC1123 INTRODUCTION October 1989
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 7 of 97
`
`

`
`Page 8 of 97
`
`for misbehaving hosts"; host software should be prepared, not
`just to survive other misbehaving hosts, but also to cooperate
`to limit the amount of disruption such hosts can cause to the
`shared communication facility.
`1.2.3 Error Logging
`The Internet includes a great variety of host and gateway
`systems, each implementing many protocols and protocol layers,
`and some of these contain bugs and mis-features in their
`Internet protocol software. As a result of complexity,
`diversity, and distribution of function, the diagnosis of user
`problems is often very difficult.
`Problem diagnosis will be aided if host implementations include
`a carefully designed facility for logging erroneous or
`"strange" protocol events. It is important to include as much
`diagnostic information as possible when an error is logged. In
`particular, it is often useful to record the header(s) of a
`packet that caused an error. However, care must be taken to
`ensure that error logging does not consume prohibitive amounts
`of resources or otherwise interfere with the operation of the
`host.
`There is a tendency for abnormal but harmless protocol events
`to overflow error logging files; this can be avoided by using a
`"circular" log, or by enabling logging only while diagnosing a
`known failure. It may be useful to filter and count duplicate
`successive messages. One strategy that seems to work well is:
`(1) always count abnormalities and make such counts accessible
`through the management protocol (see Section 6.3); and (2)
`allow the logging of a great variety of events to be
`selectively enabled. For example, it might useful to be able
`to "log everything" or to "log everything for host X".
`Note that different managements may have differing policies
`about the amount of error logging that they want normally
`enabled in a host. Some will say, "if it doesn't hurt me, I
`don't want to know about it", while others will want to take a
`more watchful and aggressive attitude about detecting and
`removing protocol abnormalities.
`1.2.4 Configuration
`It would be ideal if a host implementation of the Internet
`protocol suite could be entirely self-configuring. This would
`allow the whole suite to be implemented in ROM or cast into
`silicon, it would simplify diskless workstations, and it would
`
`Internet Engineering Task Force [Page 8]
`
`RFC1123 INTRODUCTION October 1989
`
`be an immense boon to harried LAN administrators as well as
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 8 of 97
`
`

`
`Page 9 of 97
`
`system vendors. We have not reached this ideal; in fact, we
`are not even close.
`At many points in this document, you will find a requirement
`that a parameter be a configurable option. There are several
`different reasons behind such requirements. In a few cases,
`there is current uncertainty or disagreement about the best
`value, and it may be necessary to update the recommended value
`in the future. In other cases, the value really depends on
`external factors --e.g., the size of the host and the
`distribution of its communication load, or the speeds and
`topology of nearby networks --and self-tuning algorithms are
`unavailable and may be insufficient. In some cases,
`configurability is needed because of administrative
`requirements.
`Finally, some configuration options are required to communicate
`with obsolete or incorrect implementations of the protocols,
`distributed without sources, that unfortunately persist in many
`parts of the Internet. To make correct systems coexist with
`these faulty systems, administrators often have to "mis-
`configure" the correct systems. This problem will correct
`itself gradually as the faulty systems are retired, but it
`cannot be ignored by vendors.
`When we say that a parameter must be configurable, we do not
`intend to require that its value be explicitly read from a
`configuration file at every boot time. We recommend that
`implementors set up a default for each parameter, so a
`configuration file is only necessary to override those defaults
`that are inappropriate in a particular installation. Thus, the
`configurability requirement is an assurance that it will be
`POSSIBLE to override the default when necessary, even in a
`binary-only or ROM-based product.
`This document requires a particular value for such defaults in
`some cases. The choice of default is a sensitive issue when
`the configuration item controls the accommodation to existing
`faulty systems. If the Internet is to converge successfully to
`complete interoperability, the default values built into
`implementations must implement the official protocol, not
`"mis-configurations" to accommodate faulty implementations.
`Although marketing considerations have led some vendors to
`choose mis-configuration defaults, we urge vendors to choose
`defaults that will conform to the standard.
`Finally, we note that a vendor needs to provide adequate
`
`Internet Engineering Task Force [Page 9]
`
`RFC1123 INTRODUCTION October 1989
`
`documentation on all configuration parameters, their limits and
`effects.
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 9 of 97
`
`

`
`Page 10 of 97
`
`1.3 Reading this Document
`1.3.1 Organization
`In general, each major section is organized into the following
`subsections:
`(1) Introduction
`(2) Protocol Walk-Through --considers the protocol
`specification documents section-by-section, correcting
`errors, stating requirements that may be ambiguous or
`ill-defined, and providing further clarification or
`explanation.
`(3) Specific Issues --discusses protocol design and
`implementation issues that were not included in the walk-
`through.
`(4) Interfaces --discusses the service interface to the next
`higher layer.
`(5) Summary --contains a summary of the requirements of the
`section.
`Under many of the individual topics in this document, there is
`parenthetical material labeled "DISCUSSION" or
`"IMPLEMENTATION". This material is intended to give
`clarification and explanation of the preceding requirements
`text. It also includes some suggestions on possible future
`directions or developments. The implementation material
`contains suggested approaches that an implementor may want to
`consider.
`The summary sections are intended to be guides and indexes to
`the text, but are necessarily cryptic and incomplete. The
`summaries should never be used or referenced separately from
`the complete RFC.
`1.3.2 Requirements
`In this document, the words that are used to define the
`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 item
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 10 of 97
`
`

`
`Page 11 of 97
`
`is an absolute requirement of the specification.
`* "SHOULD"
`This word or the adjective "RECOMMENDED" means that there
`may exist valid reasons in particular circumstances to
`ignore this item, but the full implications should be
`understood and the case carefully weighed before choosing
`a different course.
`* "MAY"
`This word or the adjective "OPTIONAL" means that this item
`is truly optional. One vendor may choose to include the
`item because a particular marketplace requires it or
`because it enhances the product, for example; another
`vendor may omit the same item.
`
`An implementation is not compliant if it fails to satisfy one
`or more of the MUST requirements for the protocols it
`implements. An implementation that satisfies all the MUST and
`all the SHOULD requirements for its protocols is said to be
`"unconditionally compliant"; one that satisfies all the MUST
`requirements but not all the SHOULD requirements for its
`protocols is said to be "conditionally compliant".
`1.3.3 Terminology
`This document uses the following technical terms:
`Segment
`A segment is the unit of end-to-end transmission in the
`TCP protocol. A segment consists of a TCP header followed
`by application data. A segment is transmitted by
`encapsulation in an IP datagram.
`Message
`This term is used by some application layer protocols
`(particularly SMTP) for an application data unit.
`Datagram
`A [UDP] datagram is the unit of end-to-end transmission in
`the UDP protocol.
`
`Internet Engineering Task Force [Page 11]
`
`RFC1123 INTRODUCTION October 1989
`
`Multihomed
`A host is said to be multihomed if it has multiple IP
`addresses to connected networks.
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 11 of 97
`
`

`
`Page 12 of 97
`
`1.4 Acknowledgments
`This document incorporates contributions and comments from a large
`group of Internet protocol experts, including representatives of
`university and research labs, vendors, and government agencies.
`It was assembled primarily by the Host Requirements Working Group
`of the Internet Engineering Task Force (IETF).
`The Editor would especially like to acknowledge the tireless
`dedication of the following people, who attended many long
`meetings and generated 3 million bytes of electronic mail over the
`past 18 months in pursuit of this document: Philip Almquist, Dave
`Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
`Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
`John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
`Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
`(BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
`In addition, the following people made major contributions to the
`effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
`(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), Bill
`Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
`(DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
`Technology), and Mike StJohns (DCA). The following also made
`significant contributions to particular areas: Eric Allman
`(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
`(Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
`(IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
`(Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
`Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
`(Toronto).
`We are grateful to all, including any contributors who may have
`been inadvertently omitted from this list.
`
`Internet Engineering Task Force [Page 12]
`
`RFC1123 APPLICATIONS LAYER --GENERAL October 1989
`
`2. GENERAL ISSUES
`This section contains general requirements that may be applicable to
`all application-layer protocols.
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 12 of 97
`
`

`
`Page 13 of 97
`
`2.1 Host Names and Numbers
`The syntax of a legal Internet host name was specified in RFC-952
`[DNS:4]. One aspect of host name syntax is hereby changed: the
`restriction on the first character is relaxed to allow either a
`letter or a digit. Host software MUST support this more liberal
`syntax.
`Host software MUST handle host names of up to 63 characters and
`SHOULD handle host names of up to 255 characters.
`Whenever a user inputs the identity of an Internet host, it SHOULD
`be possible to enter either (1) a host domain name or (2) an IP
`address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
`the string syntactically for a dotted-decimal number before
`looking it up in the Domain Name System.
`DISCUSSION:
`This last requirement is not intended to specify the complete
`syntactic form for entering a dotted-decimal host number;
`that is considered to be a user-interface issue. For
`example, a dotted-decimal number must be enclosed within
`"[ ]" brackets for SMTP mail (see Section 5.2.17). This
`notation could be made universal within a host system,
`simplifying the syntactic checking for a dotted-decimal
`number.
`If a dotted-decimal number can be entered without such
`identifying delimiters, then a full syntactic check must be
`made, because a segment of a host domain name is now allowed
`to begin with a digit and could legally be entirely numeric
`(see Section 6.1.2.4). However, a valid host name can never
`have the dotted-decimal form #.#.#.#, since at least the
`highest-level component label will be alphabetic.
`2.2 Using Domain Name Service
`Host domain names MUST be translated to IP addresses as described
`in Section 6.1.
`Applications using domain name services MUST be able to cope with
`soft error conditions. Applications MUST wait a reasonable
`interval between successive retries due to a soft error, and MUST
`
`Internet Engineering Task Force [Page 13]
`
`RFC1123 APPLICATIONS LAYER --GENERAL October 1989
`
`allow for the possibility that network problems may deny service
`for hours or even days.
`An application SHOULD NOT rely on the ability to locate a WKS
`record containing an accurate listing of all services at a
`particular host address, since the WKS RR type is not often used
`
`file:///C:/Users/jklayman/AppData/Local/Temp/Low/HTU2OCLM.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1010-Page 13 of 97
`
`

`
`Page 14 of 97
`
`by Internet si