rfc1123.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,441 行 · 第 1/5 页

         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
              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.



   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.

   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
      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.



Internet Engineering Task Force                                [Page 14]




RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989


   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| | | | |
                                               |          | | | | | |
                                               |          | | | | | |