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




 



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