Skip to main content

2. General Issues

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







  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.

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

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

Last updated on