Return to rfc819.lpr CVS log

Up to [CSRG BSD Unix] / 43BSD / usr.lib / sendmail / doc

Annotation of 43BSD/usr.lib/sendmail/doc/rfc819.lpr, revision 1.1

1.1     ! root        1: 
        !             2: 
        !             3: Network Working Group                                  Zaw-Sing Su (SRI)
        !             4: Request for Comments: 819                               Jon Postel (ISI)
        !             5:                                                              August 1982
        !             6: 
        !             7: 
        !             8: 
        !             9:       The Domain Naming Convention for Internet User Applications
        !            10: 
        !            11: 
        !            12: 
        !            13: 
        !            14: 1.  Introduction
        !            15: 
        !            16:    For many years, the naming convention "<user>@<host>" has served the
        !            17:    ARPANET user community for its mail system, and the substring
        !            18:    "<host>" has been used for other applications such as file transfer
        !            19:    (FTP) and terminal access (Telnet).  With the advent of network
        !            20:    interconnection, this naming convention needs to be generalized to
        !            21:    accommodate internetworking.  A decision has recently been reached to
        !            22:    replace the simple name field, "<host>", by a composite name field,
        !            23:    "<domain>" [2].  This note is an attempt to clarify this generalized
        !            24:    naming convention, the Internet Naming Convention, and to explore the
        !            25:    implications of its adoption for Internet name service and user
        !            26:    applications.
        !            27: 
        !            28:    The following example illustrates the changes in naming convention:
        !            29: 
        !            30:       ARPANET Convention:   Fred@ISIF
        !            31:       Internet Convention:  [email protected]
        !            32: 
        !            33:    The intent is that the Internet names be used to form a
        !            34:    tree-structured administrative dependent, rather than a strictly
        !            35:    topology dependent, hierarchy.  The left-to-right string of name
        !            36:    components proceeds from the most specific to the most general, that
        !            37:    is, the root of the tree, the administrative universe, is on the
        !            38:    right.
        !            39: 
        !            40:    The name service for realizing the Internet naming convention is
        !            41:    assumed to be application independent.  It is not a part of any
        !            42:    particular application, but rather an independent name service serves
        !            43:    different user applications.
        !            44: 
        !            45: 2.  The Structural Model
        !            46: 
        !            47:    The Internet naming convention is based on the domain concept.  The
        !            48:    name of a domain consists of a concatenation of one or more <simple
        !            49:    names>.  A domain can be considered as a region of jurisdiction for
        !            50:    name assignment and of responsibility for name-to-address
        !            51:    translation.  The set of domains forms a hierarchy.
        !            52: 
        !            53:    Using a graph theory representation, this hierarchy may be modeled as
        !            54:    a directed graph.  A directed graph consists of a set of nodes and a
        !            55: 
        !            56: 
        !            57: Su & Postel                                                     [Page 1]
        !            58: 
        !            59: 
        !            60: 
        !            61: RFC 819                                                     August 1982;
        !            62: 
        !            63: 
        !            64:    collection of arcs, where arcs are identified by ordered pairs of
        !            65:    distinct nodes [1].  Each node of the graph represents a domain.  An
        !            66:    ordered pair (B, A), an arc from B to A, indicates that B is a
        !            67:    subdomain of domain A, and B is a simple name unique within A.  We
        !            68:    will refer to B as a child of A, and A a parent of B.  The directed
        !            69:    graph that best describes the naming hierarchy is called an
        !            70:    "in-tree", which is a rooted tree with all arcs directed towards the
        !            71:    root (Figure 1). The root of the tree represents the naming universe,
        !            72:    ancestor of all domains.  Endpoints (or leaves) of the tree are the
        !            73:    lowest-level domains.
        !            74: 
        !            75:                          U
        !            76:                        / | \
        !            77:                      /   |   \          U -- Naming Universe
        !            78:                     ^    ^    ^         I -- Intermediate Domain
        !            79:                     |    |    |         E -- Endpoint Domain
        !            80:                     I    E    I
        !            81:                   /   \       |
        !            82:                  ^     ^      ^
        !            83:                  |     |      |
        !            84:                  E     E      I
        !            85:                             / | \
        !            86:                            ^  ^  ^
        !            87:                            |  |  |
        !            88:                            E  E  E
        !            89: 
        !            90:                                 Figure 1
        !            91:                  The In-Tree Model for Domain Hierarchy
        !            92: 
        !            93:    The simple name of a child in this model is necessarily unique within
        !            94:    its parent domain.  Since the simple name of the child's parent is
        !            95:    unique within the child's grandparent domain, the child can be
        !            96:    uniquely named in its grandparent domain by the concatenation of its
        !            97:    simple name followed by its parent's simple name.
        !            98: 
        !            99:       For example, if the simple name of a child is "C1" then no other
        !           100:       child of the same parent may be named "C1".  Further, if the
        !           101:       parent of this child is named "P1", then "P1" is a unique simple
        !           102:       name in the child's grandparent domain.  Thus, the concatenation
        !           103:       C1.P1 is unique in C1's grandparent domain.
        !           104: 
        !           105:    Similarly, each element of the hierarchy is uniquely named in the
        !           106:    universe by its complete name, the concatenation of its simple name
        !           107:    and those for the domains along the trail leading to the naming
        !           108:    universe.
        !           109: 
        !           110:    The hierarchical structure of the Internet naming convention supports
        !           111:    decentralization of naming authority and distribution of name service
        !           112:    capability.  We assume a naming authority and a name server
        !           113: 
        !           114: 
        !           115: Su & Postel                                                     [Page 2]
        !           116: 
        !           117: 
        !           118: 
        !           119: RFC 819                                                     August 1982;
        !           120: 
        !           121: 
        !           122:    associated with each domain.  In Sections 5 and 6 respectively the
        !           123:    name service and the naming authority are discussed.
        !           124: 
        !           125:    Within an endpoint domain, unique names are assigned to <user>
        !           126:    representing user mailboxes.  User mailboxes may be viewed as
        !           127:    children of their respective domains.
        !           128: 
        !           129:    In reality, anomalies may exist violating the in-tree model of naming
        !           130:    hierarchy.  Overlapping domains imply multiple parentage, i.e., an
        !           131:    entity of the naming hierarchy being a child of more than one domain.
        !           132:    It is conceivable that ISI can be a member of the ARPA domain as well
        !           133:    as a member of the USC domain (Figure 2).  Such a relation
        !           134:    constitutes an anomaly to the rule of one-connectivity between any
        !           135:    two points of a tree.  The common child and the sub-tree below it
        !           136:    become descendants of both parent domains.
        !           137: 
        !           138:                                  U
        !           139:                                / | \
        !           140:                              /   .   \
        !           141:                            .     .   ARPA
        !           142:                          .       .     | \
        !           143:                                 USC    |   \
        !           144:                                    \   |     .
        !           145:                                      \ |       .
        !           146:                                       ISI
        !           147: 
        !           148:                                 Figure 2
        !           149:                       Anomaly in the In-Tree Model
        !           150: 
        !           151:    Some issues resulting from multiple parentage are addressed in
        !           152:    Appendix B.  The general implications of multiple parentage are a
        !           153:    subject for further investigation.
        !           154: 
        !           155: 3.  Advantage of Absolute Naming
        !           156: 
        !           157:    Absolute naming implies that the (complete) names are assigned with
        !           158:    respect to a universal reference point.  The advantage of absolute
        !           159:    naming is that a name thus assigned can be universally interpreted
        !           160:    with respect to the universal reference point.  The Internet naming
        !           161:    convention provides absolute naming with the naming universe as its
        !           162:    universal reference point.
        !           163: 
        !           164:    For relative naming, an entity is named depending upon the position
        !           165:    of the naming entity relative to that of the named entity.  A set of
        !           166:    hosts running the "unix" operating system exchange mail using a
        !           167:    method called "uucp".  The naming convention employed by uucp is an
        !           168:    example of relative naming.  The mail recipient is typically named by
        !           169:    a source route identifying a chain of locally known hosts linking the
        !           170: 
        !           171: 
        !           172: 
        !           173: Su & Postel                                                     [Page 3]
        !           174: 
        !           175: 
        !           176: 
        !           177: RFC 819                                                     August 1982;
        !           178: 
        !           179: 
        !           180:    sender's host to the recipient's.  A destination name can be, for
        !           181:    example,
        !           182: 
        !           183:       "alpha!beta!gamma!john",
        !           184: 
        !           185:    where "alpha" is presumably known to the originating host, "beta" is
        !           186:    known to "alpha", and so on.
        !           187: 
        !           188:    The uucp mail system has demonstrated many of the problems inherent
        !           189:    to relative naming.  When the host names are only locally
        !           190:    interpretable, routing optimization becomes impossible.  A reply
        !           191:    message may have to traverse the reverse route to the original sender
        !           192:    in order to be forwarded to other parties.
        !           193: 
        !           194:    Furthermore, if a message is forwarded by one of the original
        !           195:    recipients or passed on as the text of another message, the frame of
        !           196:    reference of the relative source route can be completely lost.  Such
        !           197:    relative naming schemes have severe problems for many of the uses
        !           198:    that we depend upon in the ARPA Internet community.
        !           199: 
        !           200: 4.  Interoperability
        !           201: 
        !           202:    To allow interoperation with a different naming convention, the names
        !           203:    assigned by a foreign naming convention need to be accommodated.
        !           204:    Given the autonomous nature of domains, a foreign naming environment
        !           205:    may be incorporated as a domain anywhere in the hierarchy.  Within
        !           206:    the naming universe, the name service for a domain is provided within
        !           207:    that domain.  Thus, a foreign naming convention can be independent of
        !           208:    the Internet naming convention.  What is implied here is that no
        !           209:    standard convention for naming needs to be imposed to allow
        !           210:    interoperations among heterogeneous naming environments.
        !           211: 
        !           212:       For example:
        !           213: 
        !           214:          There might be a naming convention, say, in the FOO world,
        !           215:          something like "<user>%<host>%<area>".  Communications with an
        !           216:          entity in that environment can be achieved from the Internet
        !           217:          community by simply appending ".FOO" on the end of the name in
        !           218:          that foreign convention.
        !           219: 
        !           220:             John%ISI-Tops20-7%California.FOO
        !           221: 
        !           222:       Another example:
        !           223: 
        !           224:          One way of accommodating the "uucp world" described in the last
        !           225:          section is to declare it as a foreign system.  Thus, a uucp
        !           226:          name
        !           227: 
        !           228:             "alpha!beta!gamma!john"
        !           229: 
        !           230: 
        !           231: Su & Postel                                                     [Page 4]
        !           232: 
        !           233: 
        !           234: 
        !           235: RFC 819                                                     August 1982;
        !           236: 
        !           237: 
        !           238:          might be known in the Internet community as
        !           239: 
        !           240:             "alpha!beta!gamma!john.UUCP".
        !           241: 
        !           242:       Communicating with a complex subdomain is another case which can
        !           243:       be treated as interoperation.  A complex subdomain is a domain
        !           244:       with complex internal naming structure presumably unknown to the
        !           245:       outside world (or the outside world does not care to be concerned
        !           246:       with its complexity).
        !           247: 
        !           248:    For the mail system application, the names embedded in the message
        !           249:    text are often used by the destination for such purpose as to reply
        !           250:    to the original message.  Thus, the embedded names may need to be
        !           251:    converted for the benefit of the name server in the destination
        !           252:    environment.
        !           253: 
        !           254:    Conversion of names on the boundary between heterogeneous naming
        !           255:    environments is a complex subject.  The following example illustrates
        !           256:    some of the involved issues.
        !           257: 
        !           258:       For example:
        !           259: 
        !           260:          A message is sent from the Internet community to the FOO
        !           261:          environment.  It may bear the "From" and "To" fields as:
        !           262: 
        !           263:             From: [email protected]
        !           264:             To:   John%ISI-Tops20-7%California.FOO
        !           265: 
        !           266:          where "FOO" is a domain independent of the Internet naming
        !           267:          environment.  The interface on the boundary of the two
        !           268:          environments may be represented by a software module.  We may
        !           269:          assume this interface to be an entity of the Internet community
        !           270:          as well as an entity of the FOO community.  For the benefit of
        !           271:          the FOO environment, the "From" and "To" fields need to be
        !           272:          modified upon the message's arrival at the boundary. One may
        !           273:          view naming as a separate layer of protocol, and treat
        !           274:          conversion as a protocol translation.  The matter is
        !           275:          complicated when the message is sent to more than one
        !           276:          destination within different naming environments; or the
        !           277:          message is destined within an environment not sharing boundary
        !           278:          with the originating naming environment.
        !           279: 
        !           280:    While the general subject concerning conversion is beyond the scope
        !           281:    of this note, a few questions are raised in Appendix D.
        !           282: 
        !           283: 
        !           284: 
        !           285: 
        !           286: 
        !           287: 
        !           288: 
        !           289: Su & Postel                                                     [Page 5]
        !           290: 
        !           291: 
        !           292: 
        !           293: RFC 819                                                     August 1982;
        !           294: 
        !           295: 
        !           296: 5.  Name Service
        !           297: 
        !           298:    Name service is a network service providing name-to-address
        !           299:    translation.  Such service may be achieved in a number of ways.  For
        !           300:    a simple networking environment, it can be accomplished with a single
        !           301:    central database containing name-to-address correspondence for all
        !           302:    the pertinent network entities, such as hosts.
        !           303: 
        !           304:    In the case of the old ARPANET host names, a central database is
        !           305:    duplicated in each individual host.  The originating module of an
        !           306:    application process would query the local name service (e.g., make a
        !           307:    system call) to obtain network address for the destination host. With
        !           308:    the proliferation of networks and an accelerating increase in the
        !           309:    number of hosts participating in networking, the ever growing size,
        !           310:    update frequency, and the dissemination of the central database makes
        !           311:    this approach unmanageable.
        !           312: 
        !           313:    The hierarchical structure of the Internet naming convention supports
        !           314:    decentralization of naming authority and distribution of name service
        !           315:    capability.  It readily accommodates growth of the naming universe.
        !           316:    It allows an arbitrary number of hierarchical layers.  The addition
        !           317:    of a new domain adds little complexity to an existing Internet
        !           318:    system.
        !           319: 
        !           320:    The name service at each domain is assumed to be provided by one or
        !           321:    more name servers.  There are two models for how a name server
        !           322:    completes its work, these might be called "iterative" and
        !           323:    "recursive".
        !           324: 
        !           325:       For an iterative name server there may be two kinds of responses.
        !           326:       The first kind of response is a destination address.  The second
        !           327:       kind of response is the address of another name server.  If the
        !           328:       response is a destination address, then the query is satisfied. If
        !           329:       the response is the address of another name server, then the query
        !           330:       must be repeated using that name server, and so on until a
        !           331:       destination address is obtained.
        !           332: 
        !           333:       For a recursive name server there is only one kind of response --
        !           334:       a destination address.  This puts an obligation on the name server
        !           335:       to actually make the call on another name server if it can't
        !           336:       answer the query itself.
        !           337: 
        !           338:    It is noted that looping can be avoided since the names presented for
        !           339:    translation can only be of finite concatenation.  However, care
        !           340:    should be taken in employing mechanisms such as a pointer to the next
        !           341:    simple name for resolution.
        !           342: 
        !           343:    We believe that some name servers will be recursive, but we don't
        !           344:    believe that all will be.  This means that the caller must be
        !           345: 
        !           346: 
        !           347: Su & Postel                                                     [Page 6]
        !           348: 
        !           349: 
        !           350: 
        !           351: RFC 819                                                     August 1982;
        !           352: 
        !           353: 
        !           354:    prepared for either type of server.  Further discussion and examples
        !           355:    of name service is given in Appendix C.
        !           356: 
        !           357:    The basic name service at each domain is the translation of simple
        !           358:    names to addresses for all of its children.  However, if only this
        !           359:    basic name service is provided, the use of complete (or fully
        !           360:    qualified) names would be required.  Such requirement can be
        !           361:    unreasonable in practice.  Thus, we propose the use of partial names
        !           362:    in the context in which their uniqueness is preserved.  By
        !           363:    construction, naming uniqueness is preserved within the domain of a
        !           364:    common ancestry. Thus, a partially qualified name is constructed by
        !           365:    omitting from the complete name ancestors common to the communicating
        !           366:    parties. When a partially qualified name leaves its context of
        !           367:    uniqueness it must be additionally qualified.
        !           368: 
        !           369:    The use of partially qualified names places a requirement on the
        !           370:    Internet name service.  To satisfy this requirement, the name service
        !           371:    at each domain must be capable of, in addition to the basic service,
        !           372:    resolving simple names for all of its ancestors (including itself)
        !           373:    and their children.  In Appendix B, the required distinction among
        !           374:    simple names for such resolution is addressed.
        !           375: 
        !           376: 6.  Naming Authority
        !           377: 
        !           378:    Associated with each domain there must be a naming authority to
        !           379:    assign simple names and ensure proper distinction among simple names.
        !           380: 
        !           381:    Note that if the use of partially qualified names is allowed in a
        !           382:    sub-domain, the uniqueness of simple names inside that sub-domain is
        !           383:    insufficient to avoid ambiguity with names outside the subdomain.
        !           384:    Appendix B discusses simple name assignment in a sub-domain that
        !           385:    would allow the use of partially qualified names without ambiguity.
        !           386: 
        !           387:    Administratively, associated with each domain there is a single
        !           388:    person (or office) called the registrar.  The registrar of the naming
        !           389:    universe specifies the top-level set of domains and designates a
        !           390:    registrar for each of these domains.  The registrar for any given
        !           391:    domain maintains the naming authority for that domain.
        !           392: 
        !           393: 7.  Network-Oriented Applications
        !           394: 
        !           395:    For user applications such as file transfer and terminal access, the
        !           396:    remote host needs to be named.  To be compatible with ARPANET naming
        !           397:    convention, a host can be treated as an endpoint domain.
        !           398: 
        !           399:    Many operating systems or programming language run-time environments
        !           400:    provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.) for
        !           401:    standard services (e.g., time-of-day, account-of-logged-in-user,
        !           402:    convert-number-to-string).  It is likely to be very helpful if such a
        !           403: 
        !           404: 
        !           405: Su & Postel                                                     [Page 7]
        !           406: 
        !           407: 
        !           408: 
        !           409: RFC 819                                                     August 1982;
        !           410: 
        !           411: 
        !           412:    function or call is developed for translating a host name to an
        !           413:    address.  Indeed, several systems on the ARPANET already have such
        !           414:    facilities for translating an ARPANET host name into an ARPANET
        !           415:    address based on internal tables.
        !           416: 
        !           417:    We recommend that this provision of a standard function or call for
        !           418:    translating names to addresses be extended to accept names of
        !           419:    Internet convention.  This will promote a consistent interface to the
        !           420:    users of programs involving internetwork activities.  The standard
        !           421:    facility for translating Internet names to Internet addresses should
        !           422:    include all the mechanisms available on the host, such as checking a
        !           423:    local table or cache of recently checked names, or consulting a name
        !           424:    server via the Internet.
        !           425: 
        !           426: 8.  Mail Relaying
        !           427: 
        !           428:    Relaying is a feature adopted by more and more mail systems.
        !           429:    Relaying facilitates, among other things, interoperations between
        !           430:    heterogeneous mail systems.  The term "relay" is used to describe the
        !           431:    situation where a message is routed via one or more intermediate
        !           432:    points between the sender and the recipient.  The mail relays are
        !           433:    normally specified explicitly as relay points in the instructions for
        !           434:    message delivery. Usually, each of the intermediate relays assume
        !           435:    responsibility for the relayed message [3].
        !           436: 
        !           437:       A point should be made on the basic difference between mail
        !           438:       relaying and the uucp naming system.  The difference is that
        !           439:       although mail relaying with absolute naming can also be considered
        !           440:       as a form of source routing, the names of each intermediate points
        !           441:       and that of the destination are universally interpretable, while
        !           442:       the host names along a source route of the uucp convention is
        !           443:       relative and thus only locally interpretable.
        !           444: 
        !           445:    The Internet naming convention explicitly allows interoperations
        !           446:    among heterogeneous systems.  This implies that the originator of a
        !           447:    communication may name a destination which resides in a foreign
        !           448:    system.  The probability is that the destination network address may
        !           449:    not be comprehensible to the transport system of the originator.
        !           450:    Thus, an implicit relaying mechanism is called for at the boundary
        !           451:    between the domains.  The function of this implicit relay is the same
        !           452:    as the explicit relay.
        !           453: 
        !           454: 
        !           455: 
        !           456: 
        !           457: 
        !           458: 
        !           459: 
        !           460: 
        !           461: 
        !           462: 
        !           463: Su & Postel                                                     [Page 8]
        !           464: 
        !           465: 
        !           466: 
        !           467: RFC 819                                                     August 1982;
        !           468: 
        !           469: 
        !           470: 9.  Implementation
        !           471: 
        !           472:    The Actual Domains
        !           473: 
        !           474:       The initial set of top-level names include:
        !           475: 
        !           476:          ARPA
        !           477: 
        !           478:             This represents the set of organizations involved in the
        !           479:             Internet system through the authority of the U.S. Defense
        !           480:             Advanced Research Projects Agency.  This includes all the
        !           481:             research and development hosts on the ARPANET and hosts on
        !           482:             many other nets as well.  But note very carefully that the
        !           483:             top-level domain "ARPA" does not map one-to-one with the
        !           484:             ARPANET -- domains are administrative, not topological.
        !           485: 
        !           486:    Transition
        !           487: 
        !           488:       In the transition from the ARPANET naming convention to the
        !           489:       Internet naming convention, a host name may be used as a simple
        !           490:       name for an endpoint domain.  Thus, if "USC-ISIF" is an ARPANET
        !           491:       host name, then "USC-ISIF.ARPA" is the name of an Internet domain.
        !           492: 
        !           493: 10.  Summary
        !           494: 
        !           495:    A hierarchical naming convention based on the domain concept has been
        !           496:    adopted by the Internet community.  It is an absolute naming
        !           497:    convention defined along administrative rather than topological
        !           498:    boundaries.  This naming convention is adaptive for interoperations
        !           499:    with other naming conventions.  Thus, no standard convention needs to
        !           500:    be imposed for interoperations among heterogeneous naming
        !           501:    environments.
        !           502: 
        !           503:    This Internet naming convention allows distributed name service and
        !           504:    naming authority functions at each domain.  We have specified these
        !           505:    functions required at each domain.  Also discussed are implications
        !           506:    on network-oriented applications, mail systems, and administrative
        !           507:    aspects of this convention.
        !           508: 
        !           509: 
        !           510: 
        !           511: 
        !           512: 
        !           513: 
        !           514: 
        !           515: 
        !           516: 
        !           517: 
        !           518: 
        !           519: 
        !           520: 
        !           521: Su & Postel                                                     [Page 9]
        !           522: 
        !           523: 
        !           524: 
        !           525: RFC 819                                                     August 1982;
        !           526: 
        !           527: 
        !           528: APPENDIX A
        !           529: 
        !           530:    The BNF Specification
        !           531: 
        !           532:    We present here a rather detailed "BNF" definition of the allowed
        !           533:    form for a computer mail "mailbox" composed of a "local-part" and a
        !           534:    "domain" (separated by an at sign).  Clearly, the domain can be used
        !           535:    separately in other network-oriented applications.
        !           536: 
        !           537:    <mailbox> ::= <local-part> "@" <domain>
        !           538: 
        !           539:    <local-part> ::= <string> | <quoted-string>
        !           540: 
        !           541:    <string> ::= <char> | <char> <string>
        !           542: 
        !           543:    <quoted-string> ::=  """ <qtext> """
        !           544: 
        !           545:    <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
        !           546: 
        !           547:    <char> ::= <c> | "\" <x>
        !           548: 
        !           549:    <domain> ::= <naming-domain> | <naming-domain> "." <domain>
        !           550: 
        !           551:    <naming-domain> ::=  <simple-name> | <address>
        !           552: 
        !           553:    <simple-name> ::= <a> <ldh-str> <let-dig>
        !           554: 
        !           555:    <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
        !           556: 
        !           557:    <let-dig> ::= <a> | <d>
        !           558: 
        !           559:    <let-dig-hyp> ::= <a> | <d> | "-"
        !           560: 
        !           561:    <address> :: =  "#" <number> | "[" <dotnum> "]"
        !           562: 
        !           563:    <number> ::= <d> | <d> <number>
        !           564: 
        !           565:    <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
        !           566: 
        !           567:    <snum> ::= one, two, or three digits representing a decimal integer
        !           568:    value in the range 0 through 255
        !           569: 
        !           570:    <a> ::= any one of the 52 alphabetic characters A through Z in upper
        !           571:    case and a through z in lower case
        !           572: 
        !           573:    <c> ::= any one of the 128 ASCII characters except <s> or <SP>
        !           574: 
        !           575:    <d> ::= any one of the ten digits 0 through 9
        !           576: 
        !           577: 
        !           578: 
        !           579: Su & Postel                                                    [Page 10]
        !           580: 
        !           581: 
        !           582: 
        !           583: RFC 819                                                     August 1982;
        !           584: 
        !           585: 
        !           586:    <q> ::= any one of the 128 ASCII characters except CR, LF, quote ("),
        !           587:    or backslash (\)
        !           588: 
        !           589:    <x> ::= any one of the 128 ASCII characters (no exceptions)
        !           590: 
        !           591:    <s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@",
        !           592:    """, and the control characters (ASCII codes 0 through 31 inclusive
        !           593:    and 127)
        !           594: 
        !           595:    Note that the backslash, "\", is a quote character, which is used to
        !           596:    indicate that the next character is to be used literally (instead of
        !           597:    its normal interpretation).  For example, "Joe\,Smith" could be used
        !           598:    to indicate a single nine character user field with comma being the
        !           599:    fourth character of the field.
        !           600: 
        !           601:    The simple names that make up a domain may contain both upper and
        !           602:    lower case letters (as well as digits and hyphen), but these names
        !           603:    are not case sensitive.
        !           604: 
        !           605:    Hosts are generally known by names.  Sometimes a host is not known to
        !           606:    the translation function and communication is blocked.  To bypass
        !           607:    this barrier two forms of addresses are also allowed for host
        !           608:    "names". One form is a decimal integer prefixed by a pound sign, "#".
        !           609:    Another form, called "dotted decimal", is four small decimal integers
        !           610:    separated by dots and enclosed by brackets, e.g., "[123.255.37.2]",
        !           611:    which indicates a 32-bit ARPA Internet Address in four 8-bit fields.
        !           612:    (Of course, these numeric address forms are specific to the Internet,
        !           613:    other forms may have to be provided if this problem arises in other
        !           614:    transport systems.)
        !           615: 
        !           616: 
        !           617: 
        !           618: 
        !           619: 
        !           620: 
        !           621: 
        !           622: 
        !           623: 
        !           624: 
        !           625: 
        !           626: 
        !           627: 
        !           628: 
        !           629: 
        !           630: 
        !           631: 
        !           632: 
        !           633: 
        !           634: 
        !           635: 
        !           636: 
        !           637: Su & Postel                                                    [Page 11]
        !           638: 
        !           639: 
        !           640: 
        !           641: RFC 819                                                     August 1982;
        !           642: 
        !           643: 
        !           644: APPENDIX B
        !           645: 
        !           646:    An Aside on the Assignment of Simple Names
        !           647: 
        !           648:    In the following example, there are two naming hierarchies joining at
        !           649:    the naming universe 'U'.  One consists of domains (S, R, N, J, P, Q,
        !           650:    B, A); and the other (L, E, F, G, H, D, C, K, B, A). Domain B is
        !           651:    assumed to have multiple parentage as shown.
        !           652: 
        !           653:                                 U
        !           654:                               /   \
        !           655:                             /       \
        !           656:                           J           L
        !           657:                         /               \
        !           658:                       N                   E
        !           659:                     /   \               /   \
        !           660:                   R       P           D       F
        !           661:                 /           \         | \      \
        !           662:               S               Q       C  (X)     G
        !           663:                                 \   /   \          \
        !           664:                                   B       K          H
        !           665:                                 /
        !           666:                               A
        !           667: 
        !           668:                                 Figure 3
        !           669:     Illustration of Requirements for the Distinction of Simple Names
        !           670: 
        !           671:    Suppose someone at A tries to initiate communication with destination
        !           672:    H.  The fully qualified destination name would be
        !           673: 
        !           674:       H.G.F.E.L.U
        !           675: 
        !           676:    Omitting common ancestors, the partially qualified name for the
        !           677:    destination would be
        !           678: 
        !           679:       H.G.F
        !           680: 
        !           681:    To permit the case of partially qualified names, name server at A
        !           682:    needs to resolve the simple name F, i.e., F needs to be distinct from
        !           683:    all the other simple names in its database.
        !           684: 
        !           685:    To enable the name server of a domain to resolve simple names, a
        !           686:    simple name for a child needs to be assigned distinct from those of
        !           687:    all of its ancestors and their immediate children.  However, such
        !           688:    distinction would not be sufficient to allow simple name resolution
        !           689:    at lower-level domains because lower-level domains could have
        !           690:    multiple parentage below the level of this domain.
        !           691: 
        !           692:       In the example above, let us assume that a name is to be assigned
        !           693: 
        !           694: 
        !           695: Su & Postel                                                    [Page 12]
        !           696: 
        !           697: 
        !           698: 
        !           699: RFC 819                                                     August 1982;
        !           700: 
        !           701: 
        !           702:       to a new domain X by D.  To allow name server at D to resolve
        !           703:       simple names, the name for X must be distinct from L, E, D, C, F,
        !           704:       and J.  However, allowing A to resolve simple names, X needs to be
        !           705:       also distinct from A, B, K, as well as from Q, P, N, and R.
        !           706: 
        !           707:    The following observations can be made.
        !           708: 
        !           709:       Simple names along parallel trails (distinct trails leading from
        !           710:       one domain to the naming universe) must be distinct, e.g., N must
        !           711:       be distinct from E for B or A to properly resolve simple names.
        !           712: 
        !           713:       No universal uniqueness of simple names is called for, e.g., the
        !           714:       simple name S does not have to be distinct from that of E, F, G,
        !           715:       H, D, C, K, Q, B, or A.
        !           716: 
        !           717:       The lower the level at which a domain occurs, the more immune it
        !           718:       is to the requirement of naming uniqueness.
        !           719: 
        !           720:    To satisfy the required distinction of simple names for proper
        !           721:    resolution at all levels, a naming authority needs to ensure the
        !           722:    simple name to be assigned distinct from those in the name server
        !           723:    databases at the endpoint naming domains within its domain.  As an
        !           724:    example, for D to assign a simple name for X, it would need to
        !           725:    consult databases at A and K.  It is, however, acceptable to have
        !           726:    simple names under domain A identical with those under K.  Failure of
        !           727:    such distinct assignment of simple names by naming authority of one
        !           728:    domain would jeopardize the capability of simple name resolution for
        !           729:    entities within the subtree under that domain.
        !           730: 
        !           731: 
        !           732: 
        !           733: 
        !           734: 
        !           735: 
        !           736: 
        !           737: 
        !           738: 
        !           739: 
        !           740: 
        !           741: 
        !           742: 
        !           743: 
        !           744: 
        !           745: 
        !           746: 
        !           747: 
        !           748: 
        !           749: 
        !           750: 
        !           751: 
        !           752: 
        !           753: Su & Postel                                                    [Page 13]
        !           754: 
        !           755: 
        !           756: 
        !           757: RFC 819                                                     August 1982;
        !           758: 
        !           759: 
        !           760: APPENDIX C
        !           761: 
        !           762:    Further Discussion of Name Service and Name Servers
        !           763: 
        !           764:    The name service on a system should appear to the programmer of an
        !           765:    application program simply as a system call or library subroutine.
        !           766:    Within that call or subroutine there may be several types of methods
        !           767:    for resolving the name string into an address.
        !           768: 
        !           769:       First, a local table may be consulted.  This table may be a
        !           770:       complete table and may be updated frequently, or it may simply be
        !           771:       a cache of the few latest name to address mappings recently
        !           772:       determined.
        !           773: 
        !           774:       Second, a call may be made to a name server to resolve the string
        !           775:       into a destination address.
        !           776: 
        !           777:       Third, a call may be made to a name server to resolve the string
        !           778:       into a relay address.
        !           779: 
        !           780:    Whenever a name server is called it may be a recursive server or an
        !           781:    interactive server.
        !           782: 
        !           783:       If the server is recursive, the caller won't be able to tell if
        !           784:       the server itself had the information to resolve the query or
        !           785:       called another server recursively (except perhaps for the time it
        !           786:       takes).
        !           787: 
        !           788:       If the server is iterative, the caller must be prepared for either
        !           789:       the answer to its query, or a response indicating that it should
        !           790:       call on a different server.
        !           791: 
        !           792:    It should be noted that the main name service discussed in this memo
        !           793:    is simply a name string to address service.  For some applications
        !           794:    there may be other services needed.
        !           795: 
        !           796:       For example, even within the Internet there are several procedures
        !           797:       or protocols for actually transferring mail.  One need is to
        !           798:       determine which mail procedures a destination host can use.
        !           799:       Another need is to determine the name of a relay host if the
        !           800:       source and destination hosts do not have a common mail procedure.
        !           801:       These more specialized services must be specific to each
        !           802:       application since the answers may be application dependent, but
        !           803:       the basic name to address translation is application independent.
        !           804: 
        !           805: 
        !           806: 
        !           807: 
        !           808: 
        !           809: 
        !           810: 
        !           811: Su & Postel                                                    [Page 14]
        !           812: 
        !           813: 
        !           814: 
        !           815: RFC 819                                                     August 1982;
        !           816: 
        !           817: 
        !           818: APPENDIX D
        !           819: 
        !           820:    Further Discussion of Interoperability and Protocol Translations
        !           821: 
        !           822:    The translation of protocols from one system to another is often
        !           823:    quite difficult.  Following are some questions that stem from
        !           824:    considering the translations of addresses between mail systems:
        !           825: 
        !           826:       What is the impact of different addressing environments (i.e.,
        !           827:       environments of different address formats)?
        !           828: 
        !           829:       It is noted that the boundary of naming environment may or may not
        !           830:       coincide with the boundary of different mail systems. Should the
        !           831:       conversion of naming be independent of the application system?
        !           832: 
        !           833:       The boundary between different addressing environments may or may
        !           834:       not coincide with that of different naming environments or
        !           835:       application systems.  Some generic approach appears to be
        !           836:       necessary.
        !           837: 
        !           838:       If the conversion of naming is to be independent of the
        !           839:       application system, some form of interaction appears necessary
        !           840:       between the interface module of naming conversion with some
        !           841:       application level functions, such as the parsing and modification
        !           842:       of message text.
        !           843: 
        !           844:       To accommodate encryption, conversion may not be desirable at all.
        !           845:       What then can be an alternative to conversion?
        !           846: 
        !           847: 
        !           848: 
        !           849: 
        !           850: 
        !           851: 
        !           852: 
        !           853: 
        !           854: 
        !           855: 
        !           856: 
        !           857: 
        !           858: 
        !           859: 
        !           860: 
        !           861: 
        !           862: 
        !           863: 
        !           864: 
        !           865: 
        !           866: 
        !           867: 
        !           868: 
        !           869: Su & Postel                                                    [Page 15]
        !           870: 
        !           871: 
        !           872: 
        !           873: RFC 819                                                     August 1982;
        !           874: 
        !           875: 
        !           876: GLOSSARY
        !           877: 
        !           878:    address
        !           879: 
        !           880:       An address is a numerical identifier for the topological location
        !           881:       of the named entity.
        !           882: 
        !           883:    name
        !           884: 
        !           885:       A name is an alphanumeric identifier associated with the named
        !           886:       entity.  For unique identification, a name needs to be unique in
        !           887:       the context in which the name is used.  A name can be mapped to an
        !           888:       address.
        !           889: 
        !           890:    complete (fully qualified) name
        !           891: 
        !           892:       A complete name is a concatenation of simple names representing
        !           893:       the hierarchical relation of the named with respect to the naming
        !           894:       universe, that is it is the concatenation of the simple names of
        !           895:       the domain structure tree nodes starting with its own name and
        !           896:       ending with the top level node name.  It is a unique name in the
        !           897:       naming universe.
        !           898: 
        !           899:    partially qualified name
        !           900: 
        !           901:       A partially qualified name is an abbreviation of the complete name
        !           902:       omitting simple names of the common ancestors of the communicating
        !           903:       parties.
        !           904: 
        !           905:    simple name
        !           906: 
        !           907:       A simple name is an alphanumeric identifier unique only within its
        !           908:       parent domain.
        !           909: 
        !           910:    domain
        !           911: 
        !           912:       A domain defines a region of jurisdiction for name assignment and
        !           913:       of responsibility for name-to-address translation.
        !           914: 
        !           915:    naming universe
        !           916: 
        !           917:       Naming universe is the ancestor of all network entities.
        !           918: 
        !           919:    naming environment
        !           920: 
        !           921:       A networking environment employing a specific naming convention.
        !           922: 
        !           923: 
        !           924: 
        !           925: 
        !           926: 
        !           927: Su & Postel                                                    [Page 16]
        !           928: 
        !           929: 
        !           930: 
        !           931: RFC 819                                                     August 1982;
        !           932: 
        !           933: 
        !           934:    name service
        !           935: 
        !           936:       Name service is a network service for name-to-address mapping.
        !           937: 
        !           938:    name server
        !           939: 
        !           940:       A name server is a network mechanism (e.g., a process) realizing
        !           941:       the function of name service.
        !           942: 
        !           943:    naming authority
        !           944: 
        !           945:       Naming authority is an administrative entity having the authority
        !           946:       for assigning simple names and responsibility for resolving naming
        !           947:       conflict.
        !           948: 
        !           949:    parallel relations
        !           950: 
        !           951:       A network entity may have one or more hierarchical relations with
        !           952:       respect to the naming universe.  Such multiple relations are
        !           953:       parallel relations to each other.
        !           954: 
        !           955:    multiple parentage
        !           956: 
        !           957:       A network entity has multiple parentage when it is assigned a
        !           958:       simple name by more than one naming domain.
        !           959: 
        !           960: 
        !           961: 
        !           962: 
        !           963: 
        !           964: 
        !           965: 
        !           966: 
        !           967: 
        !           968: 
        !           969: 
        !           970: 
        !           971: 
        !           972: 
        !           973: 
        !           974: 
        !           975: 
        !           976: 
        !           977: 
        !           978: 
        !           979: 
        !           980: 
        !           981: 
        !           982: 
        !           983: 
        !           984: 
        !           985: Su & Postel                                                    [Page 17]
        !           986: 
        !           987: 
        !           988: 
        !           989: RFC 819                                                     August 1982;
        !           990: 
        !           991: 
        !           992: REFERENCES
        !           993: 
        !           994:    [1]  F. Harary, "Graph Theory", Addison-Wesley, Reading,
        !           995:    Massachusetts, 1969.
        !           996: 
        !           997:    [2]  J. Postel, "Computer Mail Meeting Notes", RFC-805,
        !           998:    USC/Information Sciences Institute, 8 February 1982.
        !           999: 
        !          1000:    [3]  J. Postel, "Simple Mail Transfer Protocol", RFC-821,
        !          1001:    USC/Information Sciences Institute, August 1982.
        !          1002: 
        !          1003:    [4]  D. Crocker, "Standard for the Format of ARPA Internet Text
        !          1004:    Messages", RFC-822, Department of Electrical Engineering, University
        !          1005:    of Delaware, August 1982.
        !          1006: 
        !          1007: 
        !          1008: 
        !          1009: 
        !          1010: 
        !          1011: 
        !          1012: 
        !          1013: 
        !          1014: 
        !          1015: 
        !          1016: 
        !          1017: 
        !          1018: 
        !          1019: 
        !          1020: 
        !          1021: 
        !          1022: 
        !          1023: 
        !          1024: 
        !          1025: 
        !          1026: 
        !          1027: 
        !          1028: 
        !          1029: 
        !          1030: 
        !          1031: 
        !          1032: 
        !          1033: 
        !          1034: 
        !          1035: 
        !          1036: 
        !          1037: 
        !          1038: 
        !          1039: 
        !          1040: 
        !          1041: 
        !          1042: 
        !          1043: Su & Postel                                                    [Page 18]
        !          1044: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.