1045 lines
34 KiB
Plaintext
1045 lines
34 KiB
Plaintext
|
||
|
||
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]
|
||
|