central database containing name-to-address correspondence for all
   the pertinent network entities, such as hosts.

   In the case of the old ARPANET host names, a central database is
   duplicated in each individual host.  The originating module of an
   application process would query the local name service (e.g., make a
   system call) to obtain network address for the destination host. With
   the proliferation of networks and an accelerating increase in the
   number of hosts participating in networking, the ever growing size,
   update frequency, and the dissemination of the central database makes
   this approach unmanageable.

   The hierarchical structure of the Internet naming convention supports
   decentralization of naming authority and distribution of name service
   capability.  It readily accommodates growth of the naming universe.
   It allows an arbitrary number of hierarchical layers.  The addition
   of a new domain adds little complexity to an existing Internet
   system.

   The name service at each domain is assumed to be provided by one or
   more name servers.  There are two models for how a name server
   completes its work, these might be called "iterative" and
   "recursive".

      For an iterative name server there may be two kinds of responses.
      The first kind of response is a destination address.  The second
      kind of response is the address of another name server.  If the
      response is a destination address, then the query is satisfied. If
      the response is the address of another name server, then the query
      must be repeated using that name server, and so on until a
      destination address is obtained.

      For a recursive name server there is only one kind of response --
      a destination address.  This puts an obligation on the name server
      to actually make the call on another name server if it can't
      answer the query itself.

   It is noted that looping can be avoided since the names presented for
   translation can only be of finite concatenation.  However, care
   should be taken in employing mechanisms such as a pointer to the next
   simple name for resolution.

   We believe that some name servers will be recursive, but we don't
   believe that all will be.  This means that the caller must be



 


RFC 819                                                     August 1982;


   prepared for either type of server.  Further discussion and examples
   of name service is given in Appendix C.

   The basic name service at each domain is the translation of simple
   names to addresses for all of its children.  However, if only this
   basic name service is provided, the use of complete (or fully
   qualified) names would be required.  Such requirement can be
   unreasonable in practice.  Thus, we propose the use of partial names
   in the context in which their uniqueness is preserved.  By
   construction, naming uniqueness is preserved within the domain of a
   common ancestry. Thus, a partially qualified name is constructed by
   omitting from the complete name ancestors common to the communicating
   parties. When a partially qualified name leaves its context of
   uniqueness it must be additionally qualified.

   The use of partially qualified names places a requirement on the
   Internet name service.  To satisfy this requirement, the name service
   at each domain must be capable of, in addition to the basic service,
   resolving simple names for all of its ancestors (including itself)
   and their children.  In Appendix B, the required distinction among
   simple names for such resolution is addressed.

6.  Naming Authority

   Associated with each domain there must be a naming authority to
   assign simple names and ensure proper distinction among simple names.

   Note that if the use of partially qualified names is allowed in a
   sub-domain, the uniqueness of simple names inside that sub-domain is
   insufficient to avoid ambiguity with names outside the subdomain.
   Appendix B discusses simple name assignment in a sub-domain that
   would allow the use of partially qualified names without ambiguity.

   Administratively, associated with each domain there is a single
   person (or office) called the registrar.  The registrar of the naming
   universe specifies the top-level set of domains and designates a
   registrar for each of these domains.  The registrar for any given
   domain maintains the naming authority for that domain.

7.  Network-Oriented Applications

   For user applications such as file transfer and terminal access, the
   remote host needs to be named.  To be compatible with ARPANET naming
   convention, a host can be treated as an endpoint domain.

   Many operating systems or programming language run-time environments
   provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.) for