rfc819.txt

RFC 相关的技术文档

Network Working Group                                  Zaw-Sing Su (SRI)
Request for Comments: 819                               Jon Postel (ISI)
                                                             August 1982



      The Domain Naming Convention for Internet User Applications




1.  Introduction

   For many years, the naming convention "<user>@<host>" has served the
   ARPANET user community for its mail system, and the substring
   "<host>" has been used for other applications such as file transfer
   (FTP) and terminal access (Telnet).  With the advent of network
   interconnection, this naming convention needs to be generalized to
   accommodate internetworking.  A decision has recently been reached to
   replace the simple name field, "<host>", by a composite name field,
   "<domain>" [2].  This note is an attempt to clarify this generalized
   naming convention, the Internet Naming Convention, and to explore the
   implications of its adoption for Internet name service and user
   applications.

   The following example illustrates the changes in naming convention:

      ARPANET Convention:   Fred@ISIF
      Internet Convention:  [e-mail]

   The intent is that the Internet names be used to form a
   tree-structured administrative dependent, rather than a strictly
   topology dependent, hierarchy.  The left-to-right string of name
   components proceeds from the most specific to the most general, that
   is, the root of the tree, the administrative universe, is on the
   right.

   The name service for realizing the Internet naming convention is
   assumed to be application independent.  It is not a part of any
   particular application, but rather an independent name service serves
   different user applications.

2.  The Structural Model

   The Internet naming convention is based on the domain concept.  The
   name of a domain consists of a concatenation of one or more <simple
   names>.  A domain can be considered as a region of jurisdiction for
   name assignment and of responsibility for name-to-address
   translation.  The set of domains forms a hierarchy.

   Using a graph theory representation, this hierarchy may be modeled as
   a directed graph.  A directed graph consists of a set of nodes and a


Su & Postel                                                     [Page 1]



RFC 819                                                     August 1982;


   collection of arcs, where arcs are identified by ordered pairs of
   distinct nodes [1].  Each node of the graph represents a domain.  An
   ordered pair (B, A), an arc from B to A, indicates that B is a
   subdomain of domain A, and B is a simple name unique within A.  We
   will refer to B as a child of A, and A a parent of B.  The directed
   graph that best describes the naming hierarchy is called an
   "in-tree", which is a rooted tree with all arcs directed towards the
   root (Figure 1). The root of the tree represents the naming universe,
   ancestor of all domains.  Endpoints (or leaves) of the tree are the
   lowest-level domains.

                         U
                       / | \
                     /   |   \          U -- Naming Universe
                    ^    ^    ^         I -- Intermediate Domain
                    |    |    |         E -- Endpoint Domain
                    I    E    I
                  /   \       |
                 ^     ^      ^
                 |     |      |
                 E     E      I
                            / | \
                           ^  ^  ^
                           |  |  |
                           E  E  E

                                Figure 1
                 The In-Tree Model for Domain Hierarchy

   The simple name of a child in this model is necessarily unique within
   its parent domain.  Since the simple name of the child's parent is
   unique within the child's grandparent domain, the child can be
   uniquely named in its grandparent domain by the concatenation of its
   simple name followed by its parent's simple name.

      For example, if the simple name of a child is "C1" then no other
      child of the same parent may be named "C1".  Further, if the
      parent of this child is named "P1", then "P1" is a unique simple
      name in the child's grandparent domain.  Thus, the concatenation
      C1.P1 is unique in C1's grandparent domain.

   Similarly, each element of the hierarchy is uniquely named in the
   universe by its complete name, the concatenation of its simple name
   and those for the domains along the trail leading to the naming
   universe.

   The hierarchical structure of the Internet naming convention supports
   decentralization of naming authority and distribution of name service
   capability.  We assume a naming authority and a name server


Su & Postel                                                     [Page 2]



RFC 819                                                     August 1982;


   associated with each domain.  In Sections 5 and 6 respectively the
   name service and the naming authority are discussed.

   Within an endpoint domain, unique names are assigned to <user>
   representing user mailboxes.  User mailboxes may be viewed as
   children of their respective domains.

   In reality, anomalies may exist violating the in-tree model of naming
   hierarchy.  Overlapping domains imply multiple parentage, i.e., an
   entity of the naming hierarchy being a child of more than one domain.
   It is conceivable that ISI can be a member of the ARPA domain as well
   as a member of the USC domain (Figure 2).  Such a relation
   constitutes an anomaly to the rule of one-connectivity between any
   two points of a tree.  The common child and the sub-tree below it
   become descendants of both parent domains.

                                 U
                               / | \
                             /   .   \
                           .     .   ARPA
                         .       .     | \
                                USC    |   \
                                   \   |     .
                                     \ |       .
                                      ISI

                                Figure 2
                      Anomaly in the In-Tree Model

   Some issues resulting from multiple parentage are addressed in
   Appendix B.  The general implications of multiple parentage are a
   subject for further investigation.

3.  Advantage of Absolute Naming

   Absolute naming implies that the (complete) names are assigned with
   respect to a universal reference point.  The advantage of absolute
   naming is that a name thus assigned can be universally interpreted
   with respect to the universal reference point.  The Internet naming
   convention provides absolute naming with the naming universe as its
   universal reference point.

   For relative naming, an entity is named depending upon the position
   of the naming entity relative to that of the named entity.  A set of
   hosts running the "unix" operating system exchange mail using a
   method called "uucp".  The naming convention employed by uucp is an
   example of relative naming.  The mail recipient is typically named by
   a source route identifying a chain of locally known hosts linking the



Su & Postel                                                     [Page 3]



RFC 819                                                     August 1982;


   sender's host to the recipient's.  A destination name can be, for
   example,

      "alpha!beta!gamma!john",

   where "alpha" is presumably known to the originating host, "beta" is
   known to "alpha", and so on.

   The uucp mail system has demonstrated many of the problems inherent
   to relative naming.  When the host names are only locally
   interpretable, routing optimization becomes impossible.  A reply
   message may have to traverse the reverse route to the original sender
   in order to be forwarded to other parties.

   Furthermore, if a message is forwarded by one of the original
   recipients or passed on as the text of another message, the frame of
   reference of the relative source route can be completely lost.  Such
   relative naming schemes have severe problems for many of the uses
   that we depend upon in the ARPA Internet community.

4.  Interoperability

   To allow interoperation with a different naming convention, the names
   assigned by a foreign naming convention need to be accommodated.
   Given the autonomous nature of domains, a foreign naming environment
   may be incorporated as a domain anywhere in the hierarchy.  Within
   the naming universe, the name service for a domain is provided within
   that domain.  Thus, a foreign naming convention can be independent of
   the Internet naming convention.  What is implied here is that no
   standard convention for naming needs to be imposed to allow
   interoperations among heterogeneous naming environments.

      For example:

         There might be a naming convention, say, in the FOO world,
         something like "<user>%<host>%<area>".  Communications with an
         entity in that environment can be achieved from the Internet
         community by simply appending ".FOO" on the end of the name in
         that foreign convention.

            John%ISI-Tops20-7%California.FOO

      Another example:

         One way of accommodating the "uucp world" described in the last
         section is to declare it as a foreign system.  Thus, a uucp
         name

            "alpha!beta!gamma!john"


Su & Postel                                                     [Page 4]



RFC 819                                                     August 1982;


         might be known in the Internet community as

            "alpha!beta!gamma!john.UUCP".

      Communicating with a complex subdomain is another case which can
      be treated as interoperation.  A complex subdomain is a domain
      with complex internal naming structure presumably unknown to the
      outside world (or the outside world does not care to be concerned
      with its complexity).

   For the mail system application, the names embedded in the message
   text are often used by the destination for such purpose as to reply
   to the original message.  Thus, the embedded names may need to be
   converted for the benefit of the name server in the destination
   environment.

   Conversion of names on the boundary between heterogeneous naming
   environments is a complex subject.  The following example illustrates
   some of the involved issues.

      For example:

         A message is sent from the Internet community to the FOO
         environment.  It may bear the "From" and "To" fields as:

            From: [e-mail]
            To:   John%ISI-Tops20-7%California.FOO

         where "FOO" is a domain independent of the Internet naming
         environment.  The interface on the boundary of the two
         environments may be represented by a software module.  We may
         assume this interface to be an entity of the Internet community
         as well as an entity of the FOO community.  For the benefit of
         the FOO environment, the "From" and "To" fields need to be
         modified upon the message's arrival at the boundary. One may
         view naming as a separate layer of protocol, and treat
         conversion as a protocol translation.  The matter is
         complicated when the message is sent to more than one
         destination within different naming environments; or the
         message is destined within an environment not sharing boundary
         with the originating naming environment.

   While the general subject concerning conversion is beyond the scope
   of this note, a few questions are raised in Appendix D.







Su & Postel                                                     [Page 5]



RFC 819                                                     August 1982;


5.  Name Service

   Name service is a network service providing name-to-address
   translation.  Such service may be achieved in a number of ways.  For
   a simple networking environment, it can be accomplished with a single
   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


Su & Postel                                                     [Page 6]