Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1123

Requirements for Internet Hosts - Application and Support

Pages: 98
Internet Standard: 3
Errata
STD 3 is also:  1122
Updates:  08220952
Updated by:  134921815321596677669210
Part 1 of 4 – Pages 1 to 15
None   None   Next

Top   ToC   RFC1123 - Page 1
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
Top   ToC   RFC1123 - Page 2
   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
Top   ToC   RFC1123 - Page 3
            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
Top   ToC   RFC1123 - Page 4
         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
Top   ToC   RFC1123 - Page 5
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
Top   ToC   RFC1123 - Page 6
        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.
Top   ToC   RFC1123 - Page 7
         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
Top   ToC   RFC1123 - Page 8
         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
Top   ToC   RFC1123 - Page 9
         be an immense boon to harried LAN administrators as well as
         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
Top   ToC   RFC1123 - Page 10
         documentation on all configuration parameters, their limits and
         effects.


   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:
Top   ToC   RFC1123 - Page 11
         *    "MUST"

              This word or the adjective "REQUIRED" means that the item
              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.
Top   ToC   RFC1123 - Page 12
         Multihomed
              A host is said to be multihomed if it has multiple IP
              addresses to connected networks.



   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.
Top   ToC   RFC1123 - Page 13
2.  GENERAL ISSUES

   This section contains general requirements that may be applicable to
   all application-layer protocols.

   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
Top   ToC   RFC1123 - Page 14
      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
      by Internet sites.  To confirm that a service is present, simply
      attempt to use it.

   2.3  Applications on Multihomed hosts

      When the remote host is multihomed, the name-to-address
      translation will return a list of alternative IP addresses.  As
      specified in Section 6.1.3.4, this list should be in order of
      decreasing preference.  Application protocol implementations
      SHOULD be prepared to try multiple addresses from the list until
      success is obtained.  More specific requirements for SMTP are
      given in Section 5.3.4.

      When the local host is multihomed, a UDP-based request/response
      application SHOULD send the response with an IP source address
      that is the same as the specific destination address of the UDP
      request datagram.  The "specific destination address" is defined
      in the "IP Addressing" section of the companion RFC [INTRO:1].

      Similarly, a server application that opens multiple TCP
      connections to the same client SHOULD use the same local IP
      address for all.

   2.4  Type-of-Service

      Applications MUST select appropriate TOS values when they invoke
      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 MUST
      be zero.

      DISCUSSION:
           As gateway algorithms are developed to implement Type-of-
           Service, the recommended values for various application
           protocols may change.  In addition, it is likely that
           particular combinations of users and Internet paths will want
           non-standard TOS values.  For these reasons, the TOS values
           must be configurable.

           See the latest version of the "Assigned Numbers" RFC
           [INTRO:5] for the recommended TOS values for the major
           application protocols.
Top   ToC   RFC1123 - Page 15
   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY

                                               |          | | | |S| |
                                               |          | | | |H| |F
                                               |          | | | |O|M|o
                                               |          | |S| |U|U|o
                                               |          | |H| |L|S|t
                                               |          |M|O| |D|T|n
                                               |          |U|U|M| | |o
                                               |          |S|L|A|N|N|t
                                               |          |T|D|Y|O|O|t
FEATURE                                        |SECTION   | | | |T|T|e
-----------------------------------------------|----------|-|-|-|-|-|--
                                               |          | | | | | |
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| | | | |
                                               |          | | | | | |
                                               |          | | | | | |


(next page on part 2)

Next Section