Name Space
Click on the red underlined text to get to the source
... make changes visible to the Internet at large. Organizations
also wanted some local structure on the name space.
...
... RFC-819, RFC-830]. The proposals varied, but a
common thread was the idea of a hierarchical name space, with the
hierarchy roughly corresponding to organizational structure, and names
using "." as the character to mark the boundary between hierarchy
...
... The primary goal is a consistent name space which will be used
for referring to resources. In order to avoid the problems
caused by ad hoc encodings ...
... will become more and more expensive and difficult, and hence
should be avoided. The same principle holds for the structure
of the name space, and in particular mechanisms for creating
and deleting names; these should also be distributed.
...
... Because we want the name space to be useful in dissimilar
networks and applications, we provide the ability to use the
...
... networks and applications, we provide the ability to use the
same name space with different protocol families or
management. For example, host ...
... RESOURCE RECORDS, which are
specifications for a tree structured name space and data
associated with the names. Conceptually, each node and leaf
...
... name server is said to be an AUTHORITY for
these parts of the name space. Authoritative information is
organized into units called ZONEs, and these zones can be
automatically distributed to the name servers which provide
...
... Name space specifications and terminology ...
... tree structure or rules for selecting labels; its goal is to
be as general as possible, so that it can be used to build arbitrary
applications. In particular, the system was designed so that the name
space did not have to be organized along the lines of network
boundaries, name servers, etc. The rationale for this is not that the
...
... did not have to be organized along the lines of network
boundaries, name servers, etc. The rationale for this is not that the
name space should have no implied semantics, but rather that the choice
of implied semantics ...
...
However, there are some guidelines that apply to the "normal" parts of
the name space used for hosts, mailboxes, etc., that will make the name
space ...
... name space used for hosts, mailboxes, etc., that will make the name
space more uniform, provide for growth, and minimize problems as
software is converted from the older host table. The political
...
... Example name space ...
... is used in many examples in this RFC. Note that the tree is a very
small subset of the actual name space.
...
... database is partitioned in two ways: by class, and by "cuts"
made in the name space between nodes.
...
... data format for existing types or a desire for a
separately managed version of the existing name space.
...
...
Within a class, "cuts" in the name space can be made between any two
adjacent nodes. After all cuts are made, each group ...
... adjacent nodes. After all cuts are made, each group of connected name
space is a separate zone. The zone is said to be authoritative for all
names in the connected region. Note that the "cuts" in the name space
...
... group of connected name
space is a separate zone. The zone is said to be authoritative for all
names in the connected region. Note that the "cuts" in the name space
may be in different places for different classes, the name servers may
...
...
It would be possible, though not particularly useful, to partition the
name space so that each domain name was in a separate zone or so that
all nodes ...
... internal partitions to achieve nested delegations of name space control.
In some cases, such divisions are made purely to make database
...
... Internet Name Domains", RFC-799, COMSAT, September 1981. Suggests introduction of a hierarchy in place of a flat name space for the Internet. ...