5. YP ISSUES AND DISCUSSION

The term "Yellow Pages" is used in almost as many ways as the term "domain", so it is useful to define what is meant herein by YP. The general problem to be solved is to create a method for creating mappings from one kind of identifier to another, often with an inverse capability. The traditional methods are to search or use a precomputed index of some kind.

Searching is impractical when the search is too large, and precomputed indexes are possible only when it is possible to specify search criteria in advance, and pay for the resources necessary to build the index. For example, it is impractical to search the entire domain tree to find a particular address RR, so we build the IN- ADDR.ARPA YP. Similarly, we could never build an Internet-wide index of "hosts with a load average of less than 2" in less time than it would take for the data to change, so indexes are a useless approach for that problem.

Such a precomputed index is what we mean by YP, and we regard the IN-ADDR.ARPA domain as the first instance of a YP in the DNS. Although a single, centrally-managed YP for well-known values such as TCP-port is desirable, we regard organization-specific YPs for, say, locally defined TCP ports as a natural extension, as are combinations of YPs using search lists to merge the two.

In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC 1010], it is clear that there are several mappings which might be of value. For example:

   <assigned-network-name> <==> <IP-address>
   <autonomous-system-id>  <==> <number>
   <protocol-id>           <==> <number>
   <port-id>               <==> <number>
   <ethernet-type>         <==> <number>
   <public-data-net>       <==> <IP-address>

Following the IN-ADDR example, the YP takes the form of a domain tree organized to optimize retrieval by search key and distribution via normal DNS rules. The name used as a key must include:

1. A well known origin. For example, IN-ADDR.ARPA is the current IP-address to host name YP.
2. A "from" data type. This identifies the input type of the mapping. This is necessary because we may be mapping something as anonymous as a number to any number of mnemonics, etc.
3. A "to" data type. Since we assume several symmetrical mnemonic <==> number mappings, this is also necessary.

This ordering reflects the natural scoping of control, and hence the order of the components in a domain name. Thus domain names would be of the form:

   <from-value>.<to-data-type>.<from-data-type>.<YP-origin>

To make this work, we need to define well-know strings for each of these metavariables, as well as encoding rules for converting a <from-value> into a domain name. We might define:

   <YP-origin>     :=YP
   <from-data-type>:=TCP-port | IN-ADDR | Number |
                     Assigned-network-number | Name
   <to-data-type>  :=<from-data-type>

Note that "YP" is NOT a valid country code under [ISO 3166] (although we may want to worry about the future), and the existence of a syntactically valid <to-data-type>.<from-data-type> pair does not imply that a meaningful mapping exists, or is even possible.

The encoding rules might be:

   TCP-port        Six character alphanumeric

   IN-ADDR         Reversed 4-octet decimal string

   Number          decimal integer

   Assigned-network-number
                   Reversed 4-octet decimal string

   Name            Domain name