domain, then polls that DNS with a request for further resolution.  When
polled, a DNS resolves the next right-most simple domain name.  Upon
successful resolution, an intermediate DNS may have a choice of either
returning the resulting address or forwarding the request to the next
DNS for continuing resolution.
When a intermediate DNS receives a reply from the next DNS, it must
respond to the request it has received.  To simplify the domain name
service protocol, an intermediate DNS is not allowed to act as a hub for
further polling.


2.3  Application Interface

     Addressing for destination endpoint domain is in general not
sufficient for the source application process to establish direct
communication with the destination application process.  In order to
establish direct communication, further addressing may be necessary.
Addressing beyond destination endpoin domain may be necessary when the
addressing of application process cannot be derived from the address of
the endpoint domain.  To provide such derivation capability permanent
binding and universal binding convention, such as TCP port number
assignment, may be necessary.

                                   3
 
RFC 830                                                       October 1982

     Beyond addressing, negotiation for resource availability and
compatibility is often found necessary.  The application interface
provides a "what-can-you-do-for-me" negotiation capability between the
source and destination endpoint domains.  Such negotiation mechanisms
provided in this design include those for the availability and
compatibility of transport service, e.g., TCP or UDP, and application
service, e.g., SMTP for mail transport.  The availability of such
negotiation service may allow dynamic binding and variations in system
design.

     The application interface offers an integrated service for various
"what-can-you-do-for-me" negotiation capabilities.

2.4  Example

     Let us assume that a request is made at ISID for remote file
transfer using NIFTP to SRI-TSC.  The domain name for ISID is
D.ISI.USC.ARPA,* and TSC.SRI.ARPA for SRI-TSC.  The hierarchical
relationship between these two domains is as depicted in Figure 3 below.
The NIFTP process (an application process) at ISID forwards the domain
name TSC.SRI.ARPA" to the local AIP in domain D for name service.  The
AIP forwards the fully qualified domain name, "TSC.SRI.ARPA", to its co-
located DNS for domain resolution.

     ARPA, the right-most simple name, is assumed to designate a top-
level domain.  The DNS of D recognizes this simple name, resolves it
into the address of the ARPA domain DNS, and forwards the request to
that DNS with a pointer pointing to the next domain "SRI".  The ARPA DNS
recognizes "SRI" as one of its subdomains, resolves the address of the
subdomain's DNS.  It has a choice at this point whether to return this
address to the source endpoint DNS or to forward the request to the DNS
of SRI.

                                         naming
                                        universe
                                      /          \
                               --- ARPA (DNS)
                             /       |
                           /        SRI (DNS)
                         /           |  \
                       USC (DNS)        TSC (DNS/AIP)
                        |                |
                        |          [TCP/FTP/RFT]
                       ISI (DNS)
                        |
                        D (DNS/AIP)
                      /   \
        [TCP/NIFTP/RFT]   [TCP/FTP/RFT]
                    |
                  user

--------------------
* Domain names used in the examples are for illustration purposes only.
The assignment of domain names is beyond the scope of this writeup.

                                   4
 
RFC 830                                                       October 1982


If it returns the address, the source endpoint DNS at D, would continue
polling by forwarding the request to the SRI DNS.  When the DNS of SRI
detects TSC as the last domain in the concatenation, it resolves the
address for the DNS at TSC, and returns it to the source DNS at domain
D.  Upon receiving a successful domain resolution, the source DNS returns
the obtained address to its associated AIP.

     Since the destination AIP is co-located at this address, the source
AIP is able to forward a request with the service designation
"TCP/NIFTP/RFT" for "what-can-you-do-for-me" negotiation.  Realizing
that within TSC there is no NIFTP but FTP provided for remote file
transfer, the destination AIP would respond accordingly.  Since ISID
also offers FTP service, the "what-can-you-do-for-me" negotiation may