6. SPECIFICS FOR YP MAPPINGS

6.1. TCP-PORT

   $origin Number.TCP-port.YP.

   23              PTR     TELNET.TCP-port.Number.YP.
   25              PTR     SMTP.TCP-port.Number.YP.

   $origin TCP-port.Number.YP.

   TELNET          PTR     23.Number.TCP-port.YP.

   SMTP            PTR     25.Number.TCP-port.YP.

Thus the mapping between 23 and TELNET is represented by a pair of PTR RRs, one for each direction of the mapping.

6.2. Assigned networks

Network numbers are assigned by the NIC and reported in "Internet Numbers" RFCs. To create a YP, the NIC would set up two domains:

   Name.Assigned-network-number.YP and Assigned-network-number.YP

The first would contain entries of the form:

   $origin Name.Assigned-network-number.YP.

   0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
   0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.

The second would contain entries of the form:

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.

These YPs are not in conflict with the network name support described in the first half of this RFC since they map between ASSIGNED network names and numbers, not those allocated by the organizations themselves. That is, they document the NIC's decisions about allocating network numbers but do not automatically track any renaming performed by the new owners.

As a practical matter, we might want to create both of these domains to enable users on the Internet to experiment with centrally maintained support as well as the distributed version, or might want to implement only the allocated number to name mapping and request organizations to convert their allocated network names to the network names described in the distributed model.

6.3. Operational improvements

We could imagine that all conversion routines using these YPs might be instructed to use "YP.<local-domain>" followed by "YP." as a search list. Thus, if the organization ISI.EDU wished to define locally meaningful TCP-PORT, it would define the domains:

   <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.

We could add another level of indirection in the YP lookup, defining the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the YP tree, rather than being the YP tree directly. This would enable entries of the form:

   IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.

to splice in YPs from other origins or existing spaces.

Another possibility would be to shorten the RDATA section of the RRs which map back and forth by deleting the origin. This could be done either by allowing the domain name in the RDATA portion to not identify a real domain name, or by defining a new RR which used a simple text string rather than a domain name.

Thus, we might replace

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.

with

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTR     0.0.0.4.
   ARPANET.        PTR     0.0.0.10.

or

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTT     "0.0.0.4"
   ARPANET.        PTT     "0.0.0.10"

where PTT is a new type whose RDATA section is a text string.