As per Relevance of the word destination, we have this rfc below:
Network Working Group Zaw-Sing Su (SRI
Request for Comments: 819 Jon Postel (ISI
August 1982
The Domain Naming Convention for Internet User
1.
For many years, the naming convention "@" has served
ARPANET user community for its mail system, and the
"" has been used for other applications such as file
(FTP) and terminal access (Telnet). With the advent of
interconnection, this naming convention needs to be generalized
accommodate internetworking. A decision has recently been reached
replace the simple name field, "", by a composite name field
"" [2]. This note is an attempt to clarify this
naming convention, the Internet Naming Convention, and to explore
implications of its adoption for Internet name service and
applications
The following example illustrates the changes in naming convention
ARPANET Convention: Fred@
Internet Convention: Fred@F.ISI.
The intent is that the Internet names be used to form
tree-structured administrative dependent, rather than a
topology dependent, hierarchy. The left-to-right string of
components proceeds from the most specific to the most general,
is, the root of the tree, the administrative universe, is on
right
The name service for realizing the Internet naming convention
assumed to be application independent. It is not a part of
particular application, but rather an independent name service
different user applications
2. The Structural
The Internet naming convention is based on the domain concept.
name of a domain consists of a concatenation of one or more <
names>. A domain can be considered as a region of jurisdiction
name assignment and of responsibility for name-to-
translation. The set of domains forms a hierarchy
Using a graph theory representation, this hierarchy may be modeled
a directed graph. A directed graph consists of a set of nodes and
Su & Postel [Page 1]
RFC 819 August 1982;
collection of arcs, where arcs are identified by ordered pairs
distinct nodes [1]. Each node of the graph represents a domain.
ordered pair (B, A), an arc from B to A, indicates that B is
subdomain of domain A, and B is a simple name unique within A.
will refer to B as a child of A, and A a parent of B. The
graph that best describes the naming hierarchy is called
"in-tree", which is a rooted tree with all arcs directed towards
root (Figure 1). The root of the tree represents the naming universe
ancestor of all domains. Endpoints (or leaves) of the tree are
lowest-level domains
/ | \
/ | \ U -- Naming
^ ^ ^ I -- Intermediate
| | | E -- Endpoint
I E
/ \ |
^ ^ ^
| | |
E E
/ | \
^ ^ ^
| | |
E E
Figure 1
The In-Tree Model for Domain
The simple name of a child in this model is necessarily unique
its parent domain. Since the simple name of the child's parent
unique within the child's grandparent domain, the child can
uniquely named in its grandparent domain by the concatenation of
simple name followed by its parent's simple name
For example, if the simple name of a child is "C1" then no
child of the same parent may be named "C1". Further, if
parent of this child is named "P1", then "P1" is a unique
name in the child's grandparent domain. Thus, the
C1.P1 is unique in C1's grandparent domain
Similarly, each element of the hierarchy is uniquely named in
universe by its complete name, the concatenation of its simple
and those for the domains along the trail leading to the
universe
The hierarchical structure of the Internet naming convention
decentralization of naming authority and distribution of name
capability. We assume a naming authority and a name
Su & Postel [Page 2]
RFC 819 August 1982;
associated with each domain. In Sections 5 and 6 respectively
name service and the naming authority are discussed
Within an endpoint domain, unique names are assigned to
representing user mailboxes. User mailboxes may be viewed
children of their respective domains
In reality, anomalies may exist violating the in-tree model of
hierarchy. Overlapping domains imply multiple parentage, i.e.,
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
as a member of the USC domain (Figure 2). Such a
constitutes an anomaly to the rule of one-connectivity between
two points of a tree. The common child and the sub-tree below
become descendants of both parent domains
/ | \
/ . \
. .
. . | \
USC | \
\ | .
\ | .
Figure 2
Anomaly in the In-Tree
Some issues resulting from multiple parentage are addressed
Appendix B. The general implications of multiple parentage are
subject for further investigation
3. Advantage of Absolute
Absolute naming implies that the (complete) names are assigned
respect to a universal reference point. The advantage of
naming is that a name thus assigned can be universally
with respect to the universal reference point. The Internet
convention provides absolute naming with the naming universe as
universal reference point
For relative naming, an entity is named depending upon the
of the naming entity relative to that of the named entity. A set
hosts running the "unix" operating system exchange mail using
method called "uucp". The naming convention employed by uucp is
example of relative naming. The mail recipient is typically named
a source route identifying a chain of locally known hosts linking
Su & Postel [Page 3]
RFC 819 August 1982;
sender's host to the recipient's. A destination name can be,
example
"alpha!beta!gamma!john",
where "alpha" is presumably known to the originating host, "beta"
known to "alpha", and so on
The uucp mail system has demonstrated many of the problems
to relative naming. When the host names are only
interpretable, routing optimization becomes impossible. A
message may have to traverse the reverse route to the original
in order to be forwarded to other parties
Furthermore, if a message is forwarded by one of the
recipients or passed on as the text of another message, the frame
reference of the relative source route can be completely lost.
relative naming schemes have severe problems for many of the
that we depend upon in the ARPA Internet community
4.
To allow interoperation with a different naming convention, the
assigned by a foreign naming convention need to be accommodated
Given the autonomous nature of domains, a foreign naming
may be incorporated as a domain anywhere in the hierarchy.
the naming universe, the name service for a domain is provided
that domain. Thus, a foreign naming convention can be independent
the Internet naming convention. What is implied here is that
standard convention for naming needs to be imposed to
interoperations among heterogeneous naming environments
For example
There might be a naming convention, say, in the FOO world
something like "%%". Communications with
entity in that environment can be achieved from the
community by simply appending ".FOO" on the end of the name
that foreign convention
John%ISI-Tops20-7%California.
Another example
One way of accommodating the "uucp world" described in the
section is to declare it as a foreign system. Thus, a
"alpha!beta!gamma!john
Su & Postel [Page 4]
RFC 819 August 1982;
might be known in the Internet community
"alpha!beta!gamma!john.UUCP".
Communicating with a complex subdomain is another case which
be treated as interoperation. A complex subdomain is a
with complex internal naming structure presumably unknown to
outside world (or the outside world does not care to be
with its complexity).
For the mail system application, the names embedded in the
text are often used by the destination for such purpose as to
to the original message. Thus, the embedded names may need to
converted for the benefit of the name server in the
environment
Conversion of names on the boundary between heterogeneous
environments is a complex subject. The following example
some of the involved issues
For example
A message is sent from the Internet community to the
environment. It may bear the "From" and "To" fields as
From: Fred@F.ISI.
To: John%ISI-Tops20-7%California.
where "FOO" is a domain independent of the Internet
environment. The interface on the boundary of the
environments may be represented by a software module. We
assume this interface to be an entity of the Internet
as well as an entity of the FOO community. For the benefit
the FOO environment, the "From" and "To" fields need to
modified upon the message's arrival at the boundary. One
view naming as a separate layer of protocol, and
conversion as a protocol translation. The matter
complicated when the message is sent to more than
destination within different naming environments; or
message is destined within an environment not sharing
with the originating naming environment
While the general subject concerning conversion is beyond the
of this note, a few questions are raised in Appendix D
Su & Postel [Page 5]
RFC 819 August 1982;
5. Name
Name service is a network service providing name-to-
translation. Such service may be achieved in a number of ways.
a simple networking environment, it can be accomplished with a
central database containing name-to-address correspondence for
the pertinent network entities, such as hosts
In the case of the old ARPANET host names, a central database
duplicated in each individual host. The originating module of
application process would query the local name service (e.g., make
system call) to obtain network address for the destination host.
the proliferation of networks and an accelerating increase in
number of hosts participating in networking, the ever growing size
update frequency, and the dissemination of the central database
this approach unmanageable
The hierarchical structure of the Internet naming convention
decentralization of naming authority and distribution of name
capability. It readily accommodates growth of the naming universe
It allows an arbitrary number of hierarchical layers. The
of a new domain adds little complexity to an existing
system
The name service at each domain is assumed to be provided by one
more name servers. There are two models for how a name
completes its work, these might be called "iterative"
"recursive".
For an iterative name server there may be two kinds of responses
The first kind of response is a destination address. The
kind of response is the address of another name server. If
response is a destination address, then the query is satisfied.
the response is the address of another name server, then the
must be repeated using that name server, and so on until
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
to actually make the call on another name server if it can'
answer the query itself
It is noted that looping can be avoided since the names presented
translation can only be of finite concatenation. However,
should be taken in employing mechanisms such as a pointer to the
simple name for resolution
We believe that some name servers will be recursive, but we don'
believe that all will be. This means that the caller must
Su & Postel [Page 6]
RFC 819 August 1982;
prepared for either type of server. Further discussion and
of name service is given in Appendix C
The basic name service at each domain is the translation of
names to addresses for all of its children. However, if only
basic name service is provided, the use of complete (or
qualified) names would be required. Such requirement can
unreasonable in practice. Thus, we propose the use of partial
in the context in which their uniqueness is preserved.
construction, naming uniqueness is preserved within the domain of
common ancestry. Thus, a partially qualified name is constructed
omitting from the complete name ancestors common to the
parties. When a partially qualified name leaves its context
uniqueness it must be additionally qualified
The use of partially qualified names places a requirement on
Internet name service. To satisfy this requirement, the name
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
simple names for such resolution is addressed
6. Naming
Associated with each domain there must be a naming authority
assign simple names and ensure proper distinction among simple names
Note that if the use of partially qualified names is allowed in
sub-domain, the uniqueness of simple names inside that sub-domain
insufficient to avoid ambiguity with names outside the subdomain
Appendix B discusses simple name assignment in a sub-domain
would allow the use of partially qualified names without ambiguity
Administratively, associated with each domain there is a
person (or office) called the registrar. The registrar of the
universe specifies the top-level set of domains and designates
registrar for each of these domains. The registrar for any
domain maintains the naming authority for that domain
7. Network-Oriented
For user applications such as file transfer and terminal access,
remote host needs to be named. To be compatible with ARPANET
convention, a host can be treated as an endpoint domain
Many operating systems or programming language run-time
provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.)
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
Su & Postel [Page 7]
RFC 819 August 1982;
function or call is developed for translating a host name to
address. Indeed, several systems on the ARPANET already have
facilities for translating an ARPANET host name into an
address based on internal tables
We recommend that this provision of a standard function or call
translating names to addresses be extended to accept names
Internet convention. This will promote a consistent interface to
users of programs involving internetwork activities. The
facility for translating Internet names to Internet addresses
include all the mechanisms available on the host, such as checking
local table or cache of recently checked names, or consulting a
server via the Internet
8. Mail
Relaying is a feature adopted by more and more mail systems
Relaying facilitates, among other things, interoperations
heterogeneous mail systems. The term "relay" is used to describe
situation where a message is routed via one or more
points between the sender and the recipient. The mail relays
normally specified explicitly as relay points in the instructions
message delivery. Usually, each of the intermediate relays
responsibility for the relayed message [3].
A point should be made on the basic difference between
relaying and the uucp naming system. The difference is
although mail relaying with absolute naming can also be
as a form of source routing, the names of each intermediate
and that of the destination are universally interpretable,
the host names along a source route of the uucp convention
relative and thus only locally interpretable
The Internet naming convention explicitly allows
among heterogeneous systems. This implies that the originator of
communication may name a destination which resides in a
system. The probability is that the destination network address
not be comprehensible to the transport system of the originator
Thus, an implicit relaying mechanism is called for at the
between the domains. The function of this implicit relay is the
as the explicit relay
Su & Postel [Page 8]
RFC 819 August 1982;
9.
The Actual
The initial set of top-level names include
This represents the set of organizations involved in
Internet system through the authority of the U.S.
Advanced Research Projects Agency. This includes all
research and development hosts on the ARPANET and hosts
many other nets as well. But note very carefully that
top-level domain "ARPA" does not map one-to-one with
ARPANET -- domains are administrative, not topological
In the transition from the ARPANET naming convention to
Internet naming convention, a host name may be used as a
name for an endpoint domain. Thus, if "USC-ISIF" is an
host name, then "USC-ISIF.ARPA" is the name of an Internet domain
10.
A hierarchical naming convention based on the domain concept has
adopted by the Internet community. It is an absolute
convention defined along administrative rather than
boundaries. This naming convention is adaptive for
with other naming conventions. Thus, no standard convention needs
be imposed for interoperations among heterogeneous
environments
This Internet naming convention allows distributed name service
naming authority functions at each domain. We have specified
functions required at each domain. Also discussed are
on network-oriented applications, mail systems, and
aspects of this convention
Su & Postel [Page 9]
RFC 819 August 1982;
APPENDIX
The BNF
We present here a rather detailed "BNF" definition of the
form for a computer mail "mailbox" composed of a "local-part" and
"domain" (separated by an at sign). Clearly, the domain can be
separately in other network-oriented applications
::= "@"
::= |
::= |
::= """ """
::= "\" | "\" | |
::= | "\"
::= | "."
::= |
::=
::= |
::= |
::= | | "-"
:: = "#" | "[" "]"
::= |
::= "." "." "."
::= one, two, or three digits representing a decimal
value in the range 0 through 255
::= any one of the 52 alphabetic characters A through Z in
case and a through z in lower
::= any one of the 128 ASCII characters except or
::= any one of the ten digits 0 through 9
Su & Postel [Page 10]
RFC 819 August 1982;
::= any one of the 128 ASCII characters except CR, LF, quote ("),
or backslash (\)
::= any one of the 128 ASCII characters (no exceptions
::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@",
""", and the control characters (ASCII codes 0 through 31
and 127)
Note that the backslash, "\", is a quote character, which is used
indicate that the next character is to be used literally (instead
its normal interpretation). For example, "Joe\,Smith" could be
to indicate a single nine character user field with comma being
fourth character of the field
The simple names that make up a domain may contain both upper
lower case letters (as well as digits and hyphen), but these
are not case sensitive
Hosts are generally known by names. Sometimes a host is not known
the translation function and communication is blocked. To
this barrier two forms of addresses are also allowed for
"names". One form is a decimal integer prefixed by a pound sign, "#".
Another form, called "dotted decimal", is four small decimal
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
transport systems.)
Su & Postel [Page 11]
RFC 819 August 1982;
APPENDIX
An Aside on the Assignment of Simple
In the following example, there are two naming hierarchies joining
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
assumed to have multiple parentage as shown
/ \
/ \
J
/ \
N
/ \ / \
R P D
/ \ | \ \
S Q C (X)
\ / \ \
B K
/
Figure 3
Illustration of Requirements for the Distinction of Simple
Suppose someone at A tries to initiate communication with
H. The fully qualified destination name would
H.G.F.E.L.
Omitting common ancestors, the partially qualified name for
destination would
H.G.
To permit the case of partially qualified names, name server at
needs to resolve the simple name F, i.e., F needs to be distinct
all the other simple names in its database
To enable the name server of a domain to resolve simple names,
simple name for a child needs to be assigned distinct from those
all of its ancestors and their immediate children. However,
distinction would not be sufficient to allow simple name
at lower-level domains because lower-level domains could
multiple parentage below the level of this domain
In the example above, let us assume that a name is to be
Su & Postel [Page 12]
RFC 819 August 1982;
to a new domain X by D. To allow name server at D to
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
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
one domain to the naming universe) must be distinct, e.g., N
be distinct from E for B or A to properly resolve simple names
No universal uniqueness of simple names is called for, e.g.,
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
is to the requirement of naming uniqueness
To satisfy the required distinction of simple names for
resolution at all levels, a naming authority needs to ensure
simple name to be assigned distinct from those in the name
databases at the endpoint naming domains within its domain. As
example, for D to assign a simple name for X, it would need
consult databases at A and K. It is, however, acceptable to
simple names under domain A identical with those under K. Failure
such distinct assignment of simple names by naming authority of
domain would jeopardize the capability of simple name resolution
entities within the subtree under that domain
Su & Postel [Page 13]
RFC 819 August 1982;
APPENDIX
Further Discussion of Name Service and Name
The name service on a system should appear to the programmer of
application program simply as a system call or library subroutine
Within that call or subroutine there may be several types of
for resolving the name string into an address
First, a local table may be consulted. This table may be
complete table and may be updated frequently, or it may simply
a cache of the few latest name to address mappings
determined
Second, a call may be made to a name server to resolve the
into a destination address
Third, a call may be made to a name server to resolve the
into a relay address
Whenever a name server is called it may be a recursive server or
interactive server
If the server is recursive, the caller won't be able to tell
the server itself had the information to resolve the query
called another server recursively (except perhaps for the time
takes).
If the server is iterative, the caller must be prepared for
the answer to its query, or a response indicating that it
call on a different server
It should be noted that the main name service discussed in this
is simply a name string to address service. For some
there may be other services needed
For example, even within the Internet there are several
or protocols for actually transferring mail. One need is
determine which mail procedures a destination host can use
Another need is to determine the name of a relay host if
source and destination hosts do not have a common mail procedure
These more specialized services must be specific to
application since the answers may be application dependent,
the basic name to address translation is application independent
Su & Postel [Page 14]
RFC 819 August 1982;
APPENDIX
Further Discussion of Interoperability and Protocol
The translation of protocols from one system to another is
quite difficult. Following are some questions that stem
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
coincide with the boundary of different mail systems. Should
conversion of naming be independent of the application system
The boundary between different addressing environments may or
not coincide with that of different naming environments
application systems. Some generic approach appears to
necessary
If the conversion of naming is to be independent of
application system, some form of interaction appears
between the interface module of naming conversion with
application level functions, such as the parsing and
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;
An address is a numerical identifier for the topological
of the named entity
A name is an alphanumeric identifier associated with the
entity. For unique identification, a name needs to be unique
the context in which the name is used. A name can be mapped to
address
complete (fully qualified)
A complete name is a concatenation of simple names
the hierarchical relation of the named with respect to the
universe, that is it is the concatenation of the simple names
the domain structure tree nodes starting with its own name
ending with the top level node name. It is a unique name in
naming universe
partially qualified
A partially qualified name is an abbreviation of the complete
omitting simple names of the common ancestors of the
parties
simple
A simple name is an alphanumeric identifier unique only within
parent domain
A domain defines a region of jurisdiction for name assignment
of responsibility for name-to-address translation
naming
Naming universe is the ancestor of all network entities
naming
A networking environment employing a specific naming convention
Su & Postel [Page 16]
RFC 819 August 1982;
name
Name service is a network service for name-to-address mapping
name
A name server is a network mechanism (e.g., a process)
the function of name service
naming
Naming authority is an administrative entity having the
for assigning simple names and responsibility for resolving
conflict
parallel
A network entity may have one or more hierarchical relations
respect to the naming universe. Such multiple relations
parallel relations to each other
multiple
A network entity has multiple parentage when it is assigned
simple name by more than one naming domain
Su & Postel [Page 17]
RFC 819 August 1982;
[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
Messages", RFC-822, Department of Electrical Engineering,
of Delaware, August 1982.
Su & Postel [Page 18]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
