    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:  Fred@F.ISI.ARPA

       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: Fred@F.ISI.ARPA
                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]

    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
       standard services (e.g., time-of-day, account-of-logged-in-user,
       convert-number-to-string).  It is likely to be very helpful if such a

    Su & Postel                                                     [Page 7]

    RFC 819                                                     August 1982;

       function or call is developed for translating a host name to an
       address.  Indeed, several systems on the ARPANET already have such
       facilities for translating an ARPANET host name into an ARPANET
       address based on internal tables.

       We recommend that this provision of a standard function or call for
       translating names to addresses be extended to accept names of
       Internet convention.  This will promote a consistent interface to the
       users of programs involving internetwork activities.  The standard
       facility for translating Internet names to Internet addresses should
       include all the mechanisms available on the host, such as checking a
       local table or cache of recently checked names, or consulting a name
       server via the Internet.

    8.  Mail Relaying

       Relaying is a feature adopted by more and more mail systems.
       Relaying facilitates, among other things, interoperations between
       heterogeneous mail systems.  The term "relay" is used to describe the
       situation where a message is routed via one or more intermediate
       points between the sender and the recipient.  The mail relays are
       normally specified explicitly as relay points in the instructions for
       message delivery. Usually, each of the intermediate relays assume
       responsibility for the relayed message [3].

          A point should be made on the basic difference between mail
          relaying and the uucp naming system.  The difference is that
          although mail relaying with absolute naming can also be considered
          as a form of source routing, the names of each intermediate points
          and that of the destination are universally interpretable, while
          the host names along a source route of the uucp convention is
          relative and thus only locally interpretable.

       The Internet naming convention explicitly allows interoperations
       among heterogeneous systems.  This implies that the originator of a
       communication may name a destination which resides in a foreign
       system.  The probability is that the destination network address may
       not be comprehensible to the transport system of the originator.
       Thus, an implicit relaying mechanism is called for at the boundary
       between the domains.  The function of this implicit relay is the same
       as the explicit relay.

    Su & Postel                                                     [Page 8]

    RFC 819                                                     August 1982;

    9.  Implementation

       The Actual Domains

          The initial set of top-level names include:

             ARPA

                This represents the set of organizations involved in the
                Internet system through the authority of the U.S. Defense
                Advanced Research Projects Agency.  This includes all the
                research and development hosts on the ARPANET and hosts on
                many other nets as well.  But note very carefully that the
                top-level domain "ARPA" does not map one-to-one with the
                ARPANET -- domains are administrative, not topological.

       Transition

          In the transition from the ARPANET naming convention to the
          Internet naming convention, a host name may be used as a simple
          name for an endpoint domain.  Thus, if "USC-ISIF" is an ARPANET
          host name, then "USC-ISIF.ARPA" is the name of an Internet domain.

    10.  Summary

       A hierarchical naming convention based on the domain concept has been
       adopted by the Internet community.  It is an absolute naming
       convention defined along administrative rather than topological
       boundaries.  This naming convention is adaptive for interoperations
       with other naming conventions.  Thus, no standard convention needs to
       be imposed for interoperations among heterogeneous naming
       environments.

       This Internet naming convention allows distributed name service and
       naming authority functions at each domain.  We have specified these
       functions required at each domain.  Also discussed are implications
       on network-oriented applications, mail systems, and administrative
       aspects of this convention.

    Su & Postel                                                     [Page 9]

    RFC 819                                                     August 1982;

    APPENDIX A

       The BNF Specification

       We present here a rather detailed "BNF" definition of the allowed
       form for a computer mail "mailbox" composed of a "local-part" and a
       "domain" (separated by an at sign).  Clearly, the domain can be used
       separately in other network-oriented applications.

       <mailbox> ::= <local-part> "@" <domain>

       <local-part> ::= <string> | <quoted-string>

       <string> ::= <char> | <char> <string>

       <quoted-string> ::=  """ <qtext> """

       <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>

       <char> ::= <c> | "\" <x>

       <domain> ::= <naming-domain> | <naming-domain> "." <domain>

       <naming-domain> ::=  <simple-name> | <address>

       <simple-name> ::= <a> <ldh-str> <let-dig>

       <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

       <let-dig> ::= <a> | <d>

       <let-dig-hyp> ::= <a> | <d> | "-"

       <address> :: =  "#" <number> | "[" <dotnum> "]"

       <number> ::= <d> | <d> <number>

       <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>

       <snum> ::= one, two, or three digits representing a decimal integer
       value in the range 0 through 255

       <a> ::= any one of the 52 alphabetic characters A through Z in upper
       case and a through z in lower case

       <c> ::= any one of the 128 ASCII characters except <s> or <SP>

       <d> ::= any one of the ten digits 0 through 9

    Su & Postel                                                    [Page 10]

    RFC 819                                                     August 1982;

       <q> ::= any one of the 128 ASCII characters except CR, LF, quote ("),
       or backslash (\)

       <x> ::= any one of the 128 ASCII characters (no exceptions)

       <s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@",
       """, and the control characters (ASCII codes 0 through 31 inclusive
       and 127)

       Note that the backslash, "\", is a quote character, which is used to
       indicate that the next character is to be used literally (instead of
       its normal interpretation).  For example, "Joe\,Smith" could be used
       to indicate a single nine character user field with comma being the
       fourth character of the field.

       The simple names that make up a domain may contain both upper and
       lower case letters (as well as digits and hyphen), but these names
       are not case sensitive.

       Hosts are generally known by names.  Sometimes a host is not known to
       the translation function and communication is blocked.  To bypass
       this barrier two forms of addresses are also allowed for host
       "names". One form is a decimal integer prefixed by a pound sign, "#".
       Another form, called "dotted decimal", is four small decimal integers
       separated by dots and enclosed by brackets, e.g., "[123.255.37.2]",
       which indicates a 32-bit ARPA Internet Address in four 8-bit fields.
       (Of course, these numeric address forms are specific to the Internet,
       other forms may have to be provided if this problem arises in other
       transport systems.)

    Su & Postel                                                    [Page 11]

    RFC 819                                                     August 1982;

    APPENDIX B

       An Aside on the Assignment of Simple Names

       In the following example, there are two naming hierarchies joining at
       the naming universe 'U'.  One consists of domains (S, R, N, J, P, Q,
       B, A); and the other (L, E, F, G, H, D, C, K, B, A). Domain B is
       assumed to have multiple parentage as shown.

                                    U
                                  /   \
                                /       \
                              J           L
                            /               \
                          N                   E
                        /   \               /   \
                      R       P           D       F
                    /           \         | \      \
                  S               Q       C  (X)     G
                                    \   /   \          \
                                      B       K          H
                                    /
                                  A

                                    Figure 3
        Illustration of Requirements for the Distinction of Simple Names

       Suppose someone at A tries to initiate communication with destination
       H.  The fully qualified destination name would be

          H.G.F.E.L.U

       Omitting common ancestors, the partially qualified name for the
       destination would be

          H.G.F

       To permit the case of partially qualified names, name server at A
       needs to resolve the simple name F, i.e., F needs to be distinct from
       all the other simple names in its database.

       To enable the name server of a domain to resolve simple names, a
       simple name for a child needs to be assigned distinct from those of
       all of its ancestors and their immediate children.  However, such
       distinction would not be sufficient to allow simple name resolution
       at lower-level domains because lower-level domains could have
       multiple parentage below the level of this domain.

          In the example above, let us assume that a name is to be assigned

    Su & Postel                                                    [Page 12]

    RFC 819                                                     August 1982;

          to a new domain X by D.  To allow name server at D to resolve
          simple names, the name for X must be distinct from L, E, D, C, F,
          and J.  However, allowing A to resolve simple names, X needs to be
          also distinct from A, B, K, as well as from Q, P, N, and R.

       The following observations can be made.

          Simple names along parallel trails (distinct trails leading from
          one domain to the naming universe) must be distinct, e.g., N must
          be distinct from E for B or A to properly resolve simple names.

          No universal uniqueness of simple names is called for, e.g., the
          simple name S does not have to be distinct from that of E, F, G,
          H, D, C, K, Q, B, or A.

          The lower the level at which a domain occurs, the more immune it
          is to the requirement of naming uniqueness.

       To satisfy the required distinction of simple names for proper
       resolution at all levels, a naming authority needs to ensure the
       simple name to be assigned distinct from those in the name server
       databases at the endpoint naming domains within its domain.  As an
       example, for D to assign a simple name for X, it would need to
       consult databases at A and K.  It is, however, acceptable to have
       simple names under domain A identical with those under K.  Failure of
       such distinct assignment of simple names by naming authority of one
       domain would jeopardize the capability of simple name resolution for
       entities within the subtree under that domain.

    Su & Postel                                                    [Page 13]

    RFC 819                                                     August 1982;

    APPENDIX C

       Further Discussion of Name Service and Name Servers

       The name service on a system should appear to the programmer of an
       application program simply as a system call or library subroutine.
       Within that call or subroutine there may be several types of methods
       for resolving the name string into an address.

          First, a local table may be consulted.  This table may be a
          complete table and may be updated frequently, or it may simply be
          a cache of the few latest name to address mappings recently
          determined.

          Second, a call may be made to a name server to resolve the string
          into a destination address.

          Third, a call may be made to a name server to resolve the string
          into a relay address.

       Whenever a name server is called it may be a recursive server or an
       interactive server.

          If the server is recursive, the caller won't be able to tell if
          the server itself had the information to resolve the query or
          called another server recursively (except perhaps for the time it
          takes).

          If the server is iterative, the caller must be prepared for either
          the answer to its query, or a response indicating that it should
          call on a different server.

       It should be noted that the main name service discussed in this memo
       is simply a name string to address service.  For some applications
       there may be other services needed.

          For example, even within the Internet there are several procedures
          or protocols for actually transferring mail.  One need is to
          determine which mail procedures a destination host can use.
          Another need is to determine the name of a relay host if the
          source and destination hosts do not have a common mail procedure.
          These more specialized services must be specific to each
          application since the answers may be application dependent, but
          the basic name to address translation is application independent.

    Su & Postel                                                    [Page 14]

    RFC 819                                                     August 1982;

    APPENDIX D

       Further Discussion of Interoperability and Protocol Translations

       The translation of protocols from one system to another is often
       quite difficult.  Following are some questions that stem from
       considering the translations of addresses between mail systems:

          What is the impact of different addressing environments (i.e.,
          environments of different address formats)?

          It is noted that the boundary of naming environment may or may not
          coincide with the boundary of different mail systems. Should the
          conversion of naming be independent of the application system?

          The boundary between different addressing environments may or may
          not coincide with that of different naming environments or
          application systems.  Some generic approach appears to be
          necessary.

          If the conversion of naming is to be independent of the
          application system, some form of interaction appears necessary
          between the interface module of naming conversion with some
          application level functions, such as the parsing and modification
          of message text.

          To accommodate encryption, conversion may not be desirable at all.
          What then can be an alternative to conversion?

    Su & Postel                                                    [Page 15]

    RFC 819                                                     August 1982;

    GLOSSARY

       address

          An address is a numerical identifier for the topological location
          of the named entity.

       name

          A name is an alphanumeric identifier associated with the named
          entity.  For unique identification, a name needs to be unique in
          the context in which the name is used.  A name can be mapped to an
          address.

       complete (fully qualified) name

          A complete name is a concatenation of simple names representing
          the hierarchical relation of the named with respect to the naming
          universe, that is it is the concatenation of the simple names of
          the domain structure tree nodes starting with its own name and
          ending with the top level node name.  It is a unique name in the
          naming universe.

       partially qualified name

          A partially qualified name is an abbreviation of the complete name
          omitting simple names of the common ancestors of the communicating
          parties.

       simple name

          A simple name is an alphanumeric identifier unique only within its
          parent domain.

       domain

          A domain defines a region of jurisdiction for name assignment and
          of responsibility for name-to-address translation.

       naming universe

          Naming universe is the ancestor of all network entities.

       naming environment

          A networking environment employing a specific naming convention.

    Su & Postel                                                    [Page 16]

    RFC 819                                                     August 1982;

       name service

          Name service is a network service for name-to-address mapping.

       name server

          A name server is a network mechanism (e.g., a process) realizing
          the function of name service.

       naming authority

          Naming authority is an administrative entity having the authority
          for assigning simple names and responsibility for resolving naming
          conflict.

       parallel relations

          A network entity may have one or more hierarchical relations with
          respect to the naming universe.  Such multiple relations are
          parallel relations to each other.

       multiple parentage

          A network entity has multiple parentage when it is assigned a
          simple name by more than one naming domain.

    Su & Postel                                                    [Page 17]

    RFC 819                                                     August 1982;

    REFERENCES

       [1]  F. Harary, "Graph Theory", Addison-Wesley, Reading,
       Massachusetts, 1969.

       [2]  J. Postel, "Computer Mail Meeting Notes", RFC-805,
       USC/Information Sciences Institute, 8 February 1982.

       [3]  J. Postel, "Simple Mail Transfer Protocol", RFC-821,
       USC/Information Sciences Institute, August 1982.

       [4]  D. Crocker, "Standard for the Format of ARPA Internet Text
       Messages", RFC-822, Department of Electrical Engineering, University
       of Delaware, August 1982.

    Su & Postel                                                    [Page 18]