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