rfc819.txt

RFC 的详细文档！

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]