As per Relevance of the word resource, we have this rfc below:
Network Working Group K.
Request for Comments: 2276 MIT/
Category: Informational January 1998
Architectural Principles of Uniform Resource Name
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document addresses the issues of the discovery of URN (
Resource Name) resolver services that in turn will directly
URNs into URLs (Uniform Resource Locators) and URCs (Uniform
Characteristics). The document falls into three major parts,
assumptions underlying the work, the guidelines in order to be
viable Resolver Discovery Service or RDS, and a framework
designing RDSs. The guidelines fall into three principle areas
evolvability, usability, and security and privacy. An RDS that
compliant with the framework will not necessarily be compliant
the guidelines. Compliance with the guidelines will need to
validated separately
Table of
1. Introduction..................................................2
2. Assumptions...................................................5
3. Guidelines....................................................7
3.1 Evolution.....................................................7
3.2 Usability....................................................10
3.2.1 The Publisher................................................11
3.2.2 The Client...................................................12
3.2.3 The Management...............................................13
3.3 Security and Privacy.........................................14
4. The Framework................................................18
5. Acknowledgements.............................................23
6. References...................................................23
7. Author's Address.............................................23
8. Full Copyright Statement.....................................24
Sollins Informational [Page 1]
RFC 2276 Uniform Resource Name Resolution January 1998
1.
The purpose of this document is to lay out the engineering
for what we will call here a Resolver Discovery Service (RDS),
service to help in the learning about URN (Uniform Resource Name
resolvers. The term "resolver" is used in this document to
a service that translates URNs to URLs (Uniform Resource Locators)
URCs (Uniform Resource Characteristics). Some resolvers may
direct access to resources as well. An RDS helps in finding
resolver to contact for further resolution. It is worth noting
some RDS designs may also incorporate resolver functionality.
function of URN resolution is a component of the realization of
information infrastructure. In the case of this work,
infrastructure is to be available, "in the Internet" or globally,
hence the solutions to the problems we are addressing must
globally scalable. In this document, we are focussing
on the design of RDS schemes
The Uniform Resource Identifier Working Group defined a
architecture, as demonstrated in a series of three RFCs 1736 [1],
1737 [2], and 1738 [3]. Although several further documents
needed to complete the description of that architecture,
incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics. By location
we mean fully-qualified Domain Names or IP addresses,
extended with TCP ports and/or local identifiers, such as pathnames
Names may provide the ability to distinguish one resource
another, by distinguishing their "names". Names may help to
access to a resource by including "location" information.
addition, names may have other semantic or mnemonic information
either helps human users remember or figure out the names,
includes other semantic information about the resource being named
The URI working group concluded that there was need for persistent
globally unique identifiers, distinct from location or other
information; these were called URNs. These "names" provide identity
in that if two of them are "the same" (under some simple rule
canonicalization), they identify the same resource. Furthermore,
group decided that these "names" were generally to be for machine
rather than human, consumption. Finally, with these guidelines
RDS's, this group has recognized the value of the separation of
assignment management from name resolution management
In contrast to URNs, one can imagine a variety human-friendly
(HFN) schemes supporting different suites of applications and
communities. These will need to provide mappings to URNs in
or looser couplings, depending on the namespace. It is these
that will be mnemonic, content-full, and perhaps mutable, to
changes in use and semantics. They may provide nicknaming and
Sollins Informational [Page 2]
RFC 2276 Uniform Resource Name Resolution January 1998
aliasing, relative or short names, context sensitive names
descriptive names, etc. Their definition is not part of this effort
but will clearly play an important role in the long run
URNs as described in RFC 1737 are defined globally; they
ubiquitous in that a URN anywhere in any context identifies the
resource. Given this requirement on URNs, one must ask about
implication for an RDS. Does ubiquity imply a guarantee of
resolution everywhere? Does ubiquity imply resolution to the
information about resolution everywhere? In both cases the answer
probably not. One cannot make global, systemic guarantees, except
an expense beyond reason. In addition there may be policy as well
technical reasons for not resolving in the same way everywhere.
is quite possible that the resolution of a URN to an instance of
resource may reach different instances or copies under
conditions. Thus, although a URN anywhere refers to the
resource, in some environments under some conditions, and
different times, due to either the vagaries of network conditions
policy controls a URN may sometimes be resolvable and other times
places not. Ubiquitous resolution cannot be assumed simply
naming is ubiquitous. On the other hand wide deployment and
will be an important feature of any RDS design
Within the URI community there has been a concept used
that for lack of a better term we will call a _hint_. A hint
something that helps in the resolution of a URN; in theory we
URNs to hints as an interim stage in accessing a resource.
practice, an RDS may map a URN directly into the resource itself
it chooses to. It is very likely that there will be hints that
applicable to large sets of URNs, for example, a hint that
that all URNs with a certain prefix or suffix can be resolved by
particular resolver. A hint may also have meta-
associated with it, such as an expiration time or certification
authenticity. We expect that these will stay with a hint rather
being managed elsewhere. We will assume in all further discussion
hints that they include any necessary meta-information as well as
hint information itself. Examples of hints are: 1) the URN of
resolver service that may further resolve the URN, 2) the address
such a service, 3) a location at which the resource was
found. The defining feature of hints is that they are only hints
they may be out of date, temporarily invalid, or only
within a specific locality. They do not provide a guarantee
access, but they probably will help in the resolution process.
whatever means available, a set of hints may be discovered.
combination of software and human choice will determine which
will be tried and in what order
Sollins Informational [Page 3]
RFC 2276 Uniform Resource Name Resolution January 1998
We must assume that most resolutions of URNs will be provided by
use of locally stored hints, because maintaining a database
globally available, completely up-to-date location information
infeasible for performance reasons. There are a number
circumstances in which one can imagine that hints become invalid
either because a resource has moved or because a different
resolver service has taken over the responsibility for resolution
the URN. Hints may be found in a variety of places. It is
assumed that a well engineered system will maintain or cache a set
hints for each URN at each location where that URN is found.
may have been acquired from the owner of the resources,
recommendation of the resource, or one of many other sources.
addition, for those situations in which those hints found
fail, a well engineered system will provide a fall-back mechanism
discovering further hints. It is this fall-back mechanism, an RDS
that is being addressed in this document. As with all hints,
can never be a guarantee that access to a resource will be
to all clients, even if the resource is accessible to some. However
an RDS is expected to work with reasonably high reliability, and
hence, may result in increased response time
The remainder of this document falls into three sections. The
identifies several sets of assumptions underlying this work.
are three general assumptions
* URNs are persistent
* URN assignment can be delegated
* Decisions can be made independently, enabling isolation
decisions of one's peers
The next section lays out three central principles Resolver
Service design. For each of these, we have identified a number
more specific guidelines that further define and refine the
principle. This section is probably the most critical of
document, because one must hold any proposed RDS scheme up
these principles and corollary guidelines to learn whether or not
is adequate. The three central principles can be summarized as
1) An RDS must allow for evolution and evolvability
2) Usability of an RDS with regard to each of the sets
constituents involved in the identification and location
resources is paramount
3) It is centrally important that the security and privacy
of all constituents be feasibly supported, to the
possible
Each of the three major subsections of the guidelines section
with a summary list of the more detailed guidelines identified
Sollins Informational [Page 4]
RFC 2276 Uniform Resource Name Resolution January 1998
that section
The final section of the document lays out a framework for such RDSs
The purpose of this last section is to bound the search space for
schemes. The RDS designer should be aware that meeting
guidelines is of primary importance; it is possible to meet
without conforming to the framework. As will be discussed further
this last section, designing within the framework does not
compliance, so compliance evaluation must also be part of the
of evaluation of a scheme
2.
Based on previous internet drafts and discussion in both the URN
and on the URN WG mailing list, three major areas of assumptions
apparent: longevity, delegation, and independence. Each will
discussed separately
The URN requirements [2] state that a URN is to be a "
identifier". It is probably the case that nothing will last forever
but in the time frame of resources, users of those resources, and
systems to support the resources, the identifier should be
to be persistent or have a longer lifetime than those other entities
There are two assumptions that are implied by longevity of URNs
mobility and evolution. Mobility will occur because resources
move from one machine to another, owners of resources may move
organizations, or the organizations themselves may merge, partition
or otherwise transforms themselves. The Internet is
evolving; protocols are being revised, new ones created,
security policies and mechanisms evolve as well. These are
examples. In general, we must assume that almost any piece of
supporting infrastructure of URN resolution will evolve. In order
deal with both the mobility and evolution assumptions that
from the assumption of longevity, we must assume that users and
applications can remain independent of these mutating details of
supporting infrastructure
The second assumption is that naming and resolution authorities
delegate some of their authority or responsibility; in both cases
the delegation of such authority is the only known method of
for the kind of scaling expected. It is important to note that
significant feature of this work is the potential to separate
assignment, the job of labelling a resource with a URN, from
resolution, the job of discovering the resource given the URN.
both cases, we expect multi-tiered delegation. There may be
schemes that merge these two sets of responsibilities and
relationships; by doing so, they bind together or overload
distinctly different activities, thus probably impeding growth
Sollins Informational [Page 5]
RFC 2276 Uniform Resource Name Resolution January 1998
The third assumption is independence or isolation of one
from another and, at least to some extent, from its parent. When
authority delegates some of its rights and responsibilities
another authority, the delegatee can operate in that
independently of its peers and within bounds specified by
delegation, independently of the delegator. This isolation
critically important in order to allow for independence of policy
mechanism
This third assumption has several corollaries. First, we assume
the publisher of a resource can choose resolver services
independently of choices made by others. At any given time,
owner of a namespace may choose a particular URN resolver service
that delegated namespace. Such a URN resolver service may be
the RDS service model, and only identified or located by the
service. Second, it must be possible to make a choice among
services. The existence of multiple RDS services may arise from
evolution of an RDS service, or development of new ones. Although
any given time there is likely to be only one or a small set of
services, the number is likely to increase during a transition
from one architecture to another. Thus, it must be assumed
clients can make a choice among a probably very small set of RDSs
Third, there must be independence in the choice about levels
models of security and authenticity required. This choice may
made by the owner of a naming subspace, in controlling who can
hints in that subspace. A naming authority may delegate this
to the owners of the resources named by the names it has assigned
There may be limitations on this freedom of choice in order to
other participants to have the level of security and
they require, for example, in order to maintain the integrity of
RDS infrastructure as a whole. Fourth, there is an assumption
independence of choice of the rule of canonicalization of URNs
a namespace, limited by any restrictions or constraints that may
been set by its parent namespace. This is a choice held by
authorities over their own subnamespaces. Rules for
will be discussed further in the framework section below. Thus
there are assumptions of independence and isolation to allow
delegated, independent authority in a variety of domains
Sollins Informational [Page 6]
RFC 2276 Uniform Resource Name Resolution January 1998
The modularity assumptions of delegation and isolation
independence of decision and implementation, leading to
decentralization that provides a certain degree of safety from
of service. Based on these these assumptions in conjunction
that of longevity and those for URLs and URNs as detailed in
1736 and 1737, we can now turn to the guidelines for an RDS
3.
The guidelines applying to an RDS center around three
design principles in the areas of evolvability, usability,
security and privacy. At its core the function of an RDS is
provide hints for accessing a resource given a URN for it.
hints may range in applicability from local to global, and
short-lived to long-lived. They also may vary in their degree
verifiable authenticity. While it may be neither feasible
necessary that initial implementations support every guideline,
implementation must support evolution to systems that do support
guidelines more fully
It is important to note that there are requirements, not
specifically to an RDS that must also be met. A whole URN
will consist of names in namespaces, the resolution information
them, and the mapping from names in the namespaces to
information (or hints). URNs themselves must meet the
of RFC 1737. In addition, namespaces themselves must meet
requirements as described by the URN Working Group [4]. Although
these requirements and guidelines are not described here, they
be supported to provide an acceptable system
Each section below begins with a summary of the points made in
section. There is some degree of overlap among the areas, such as
allowing for the evolution of security mechanisms, etc., and
issues may be addressed in more than one section. It is
important to recognize that conformance with the guidelines
often be subjective. As with many IETF guidelines and requirements
many of these are not quantifiable and hence conformance is
judgment call and a matter of degree. Lastly, the reader may
that some of them are those of general applicability to
systems and some are specific to URN resolution. Those of
applicability are included for completeness and are not
as such
3.1
The issues in the area of the first principle, that of evolvability
are
Sollins Informational [Page 7]
RFC 2276 Uniform Resource Name Resolution January 1998
1.1) An RDS must be able to support scaling in at least
dimensions: the number of resources for which URNs will
required, the number of publishers and users of
resources, and the complexity of the delegation,
authority for resolution grows and possibly
delegation in naming authority
1.2) A hint resolution environment must support evolution
mechanisms, specifically for
* a growing set of URN schemes
* new kinds local URN resolver services
* new authentication schemes
* alternative RDS schemes active simultaneously
1.3) An RDS must allow the development and deployment
administrative control mechanisms to manage human
with respect to limited resources
One of the lessons of the Internet that we must incorporate into
development of mechanisms for resolving URNs is that we must
prepared for change. Such changes may happen slowly enough to
considered evolutionary modifications of existing services,
dramatically enough to be considered revolutionary. They
permeate the Internet universe bit by bit, living side by side
earlier services or they may take the Internet by storm, causing
apparent complete transformation over a short period of time.
are several directions in which we can predict the need
evolution. At the very least, the community and the
proposed should be prepared for these
First, scaling is a primary issue in conjunction with evolution.
number of users, both human and electronic, as well as the number
resources will continue to grow exponentially for the near term,
least. Hence the number of URNs will also increase similarly.
addition, with growth in sheer numbers is likely to come growth
the delegation of both naming authority and resolution authority
These facts mean that an RDS design must be prepared to
increasing numbers of requests for inclusion, update and resolution
in a set of RDS servers perhaps inter-related in more complex ways
This is not to say that there will necessarily be more updates
resolutions per URN; we cannot predict that at this time. But,
so, the infrastructure may become more complex due to delegation
which may (as can be seen in Section 4 on the framework) lead to
complex rules for rewriting or extracting terms for
resolution. Any design is likely to perform less well above some
of limits, so it is worth considering the growth limitations of
design alternative
Sollins Informational [Page 8]
RFC 2276 Uniform Resource Name Resolution January 1998
Second, we expect there to be additions and changes to
mechanisms. The community already understands that there must be
capacity for new URN schemes, as described in [4]. A URN scheme
define a set of URNs that meet the URN requirements [2], but may
further constraints on the internal structure of the URN.
intention is that URN schemes can be free to specify parts of the
that are left opaque in the larger picture. In fact, a URN
may choose to make public or keep private the algorithms for any
"opaque" part of the URN. In any case, we must be prepared for
growing number of URN schemes
Often in conjunction with a new URN scheme, but
independently of any particular URN scheme, new kinds of
services may evolve. For example, one can imagine a
resolver service based on the particular structure of ISBNs
improves the efficiency of finding documents given their ISBNs
Alternatively, one can also imagine a general purpose
service that trades performance for generality; although it
only average performance resolving ISBNs, it makes up for
weakness by understanding all existing URN schemes, so that
clients can use the same service to resolve URNs regardless of
scheme. In this context, there will always be room for
of services, through improved performance, better adaptability to
URN schemes, or lower cost, for example. New models for
resolution will evolve and we must be prepared to allow for
participation in the overall resolution of URNs
If we begin with one overall plan for URN resolution, into which
enhancements described above may fit, we must also be prepared for
evolution in the authentication schemes that will be
either useful or necessary in the future. There is no
globally accepted authentication scheme, and there may never be one
Even if one does exist at some point in time, we must always
prepared to move on to newer and better schemes, as the old
become too easily spoofed or guessed
In terms of mechanism, although we may develop and deploy a
RDS scheme initially, we must be prepared for that top level model
evolve. Thus, if the RDS model supports an apparently
(from a policy standpoint) scheme for inserting and
authoritative information, over time we must be prepared to evolve
a different model, perhaps one that has a more distributed model
authority and authenticity. If the model has no core but rather
cascaded partial discovery of information, we may find that
becomes unmanageable with an increase in scaling. Whatever
model, we must be prepared for it to evolve with changes in scaling
performance, and policy constraints such as security and cost
Sollins Informational [Page 9]
RFC 2276 Uniform Resource Name Resolution January 1998
The third evolutionary issue is even more mechanical than the others
At any point in time, the community is likely to be supporting
compromise position with respect to resolution. We will probably
operating in a situation balanced between feasibility and the ideal
perhaps with policy controls used to help stabilize use of
service. Ideally, the service would be providing exactly what
customers wanted and they in turn would not request more support
they need, but it seems extremely unlikely. Since we will
always be in a situation in which some service provision
will be in short supply, some form of policy controls will
be necessary. Some policy controls may be realized as
within the servers or in the details of protocols, while others
only be realized externally to the system. For example, suppose
entries are being submitted in such volume that the hint servers
using up their excess capacity and need more disk space.
suggestions for policy control are pricing and administrative.
technology changes and the balance of which resources are in
supply changes, the mechanisms and policies for controlling their
must evolve as well
3.2
To summarize, the usability guidelines fall into three areas based
participation in hint management and discovery
2.1) The
2.1.1) URN to hint resolution must be correct and
with very high probability
2.1.2) Publishers must be able to select and move among
resolver services to locate their resources
2.1.3) Publishers must be able to arrange for multiple
points for their location information
2.1.4) Publishers should be able to provide hints
varying lifetimes
2.1.5) It must be relatively easy for publishers to
to the management and observe their hint information
well as any security constraints they need for
hints
2.2) The
2.2.1) The interface to the RDS must be simple, effective
and efficient
2.2.2) The client and client applications must be able
understand the information stored in and provided
the RDS easily, in order to be able to make
choices
2.3) The
2.3.1) The management of hints must be as unobtrusive
possible, avoiding using too many network resources
Sollins Informational [Page 10]
RFC 2276 Uniform Resource Name Resolution January 1998
2.3.2) The management of hints must allow for
controls that encourage certain sorts of
deemed necessary to meet other requirements
2.3.3) The configuration and verification of configuration
individual RDS servers must be simple enough not
discourage configuration and verification
Usability can be evaluated from three distinct perspectives: those
a publisher wishing to make a piece of information public, those of
client requesting URN resolution, and those of the provider
manager of resolution information. We will separately address
usability issues from each of these three perspectives. It
important to recognize that these may be sitautions in
interests of some of the participants (for exampel a use and
publisher) may be in conflict; some resolution will be needed
It is worth noting that there are two additional sorts
participants in the whole naming process, as discussed in the URN WG
They are the naming authorities which choose and assign names,
the authors who include URNs in their resources. These two are
relevant to the design of an RDS and hence are not discussed
here
3.2.1 The
The publisher must be able to make URNs known to potential customers
From the perspective of a publisher, it is of primary importance
URNs be correctly and efficiently resolvable by potential
with very high probability. Publishers stand to gain from long-
URNs, since they increase the chance that references continue
point to their published resources
The publisher must also be able to choose easily among a variety
potential services that might translate URNs to location information
In order to allow for this mobility among resolvers, the
architecture must support such transitions, within policy
bounds. It is worth noting that although multiple listing
are available in telephone books, they are generally accompanied by
fee. There is nothing preventing there being fees collected
similar sorts of services with respect to URNs
The publisher must be able to arrange for multiple access points to
published resource. For this to be useful, resolver services
be prepared to provide different resolution or hint information
different clients, based on a variety of information
location and the various access privileges the client might have.
is important to note that this may have serious implications
caching this information. For example, companies might arrange
Sollins Informational [Page 11]
RFC 2276 Uniform Resource Name Resolution January 1998
locally replicated copies of popular resources, and would like
provide access to the local copies only for their own employees
This is distinct from access control on the resource as a whole,
may be applied differently to different copies
The publisher should be able to provide both long and short
location information about accessing the resource. Long
information is likely to be such information as the long term
of a resource itself or the location or identity of a
service with which the publisher has a long term relationship.
can imagine that the arrangement with such a long
"authoritative" resolver service might be a guarantee of reliability
resiliency to failure, and atomic updates. Shorter term
is useful for short term changes in services or to avoid short
congestion or failure problems. For example, if the
repository of the resource is temporarily inaccessible, the
might be made available from another repository. This short
information can be viewed as temporary refinements of the longer
information, and as such should be more easily and quickly
available, but may be less reliable. Some RDS designs may
distinguish between these two extremes
Lastly, the publishers will be the source of much hint
that will be stored and served by the manager of the infrastructure
Despite the fact that many publishers will not understand the
of the RDS mechanism, it must be easy and straightforward for them
install hint information. This means that in general any one
wishes to publish and to whom the privilege of resolution has
extended through delegation, can do so. The publisher must be
not only to express hints, but also to verify that what is
served by the manager is correct. Furthermore, to the extent
there are security constraints on hint information, the
must be able to both express them and verify compliance with
easily
3.2.2 The
From the perspective of the client, simplicity and usability
paramount. Of critical importance to serving clients effectively
that there be an efficient protocol through which the client
acquire hint information. Since resolving the name is only the
step on the way to getting access to a resource, the amount of
spent on it must be minimized
Furthermore, it will be important to be able to build simple
standard interfaces to the RDS so that both the client
applications on the client's behalf can interpret hints
subsequently make informed choices. The client, perhaps with
Sollins Informational [Page 12]
RFC 2276 Uniform Resource Name Resolution January 1998
assistance of the application, must be able to specify
and priorities and then apply them. If the ordering of hints is
partial, the client may become
involved in the choice and interpretation of them and hence they
be understandable to that client. On the other hand, in general
should be possible to configure default preferences, with
preferences viewed as overriding any defaults
From the client's perspective, although URNs will provide
functionality, the client is most likely to interact directly
with human friendly names (HFNs). As in direct human
(not computer mediated), the sharing of names will be on a small
private, or domain specific scale. HFNs will be the sorts
references and names that are easy to remember, type, choose among
assign, etc. There will also need to be a number of mechanisms
mapping HFNs to URNs. Such services as "yellow pages" or "
tools" fall into this category. Although we are mentioning
here, it is important to recognize that HFNs and the mappings
HFNs to URNs is and must remain a separate functionality from an RDS
Hence, although HFNs will be critical to clients, they do not
into the domain of this document
3.2.3 The
Finally, we must address the usability concerns with respect to
management of the hint infrastructure itself. What we are
"management" is a service that is distinct from publishing; it is
core of an RDS. It involves the storage and provision of hints
the clients, so that they can find published resources. It
provides security with respect to name resolution to the extent
there is a commitment for provision of such security; this
addressed in Section 3.3 below
The management of hints must be as unobtrusive as possible. First
its infrastructure (hint storage servers and distribution protocols
must have as little impact as possible on other network activities
It must be remembered that this is an auxiliary activity and
remain in the background
Second, in order to make hint management feasible, there may need
be a system for administrative incentives and disincentives such
pricing or legal restrictions. Recovering the cost of running
system is only one reason for levying charges. The introduction
payments often has an impact on social behavior. It may be
to discourage certain forms of behavior that when out of control
serious negative impact on the whole community. At the same time
any administrative policies should encourage behavior that
Sollins Informational [Page 13]
RFC 2276 Uniform Resource Name Resolution January 1998
the community as a whole. Thus, for example, a small one-time
for authoritatively storing a hint might encourage conservative
of hints. If we assume that there is a fixed cost for managing
hint, then the broader its applicability across the URN space,
more cost effective it is. That is, when one hint can serve for
whole collection of URNs, there will be an incentive to submit
general hint over a large number of more specific hints.
policies can be instituted to discourage the frequent changing
hints. In these ways and others, behavior benefitting the
as a whole can be encouraged
Lastly, symmetric to issues of usability for publishers, it must
be simple for the management to configure the mapping of URNs
hints. It must be easy both to understand the configuration and
verify that configuration is correct. With respect to management
this issue may have an impact not only on the information itself
also on how it is partitioned among network servers
collaboratively provide the management service or RDS. For example
it should be straightforward to bring up a server and verify that
data it is managing is correct. Although this is not a guideline,
is worth nothing that since we are discussing a global and
growing service, encouraging volunteer participants suggests that,
with the DNS, such volunteers can feel confident about the
they are providing and its benefit to both themselves and the rest
the community
3.3 Security and
In summary, security and privacy guidelines can be identified as
degree of protection from threats. The guidelines that fall
this third principle, that of security, are all stated in terms
possibilities or options for users of the service to require
utilize. Hence they address the availability of functionality,
not for the use of it. We recognize that all security is a matter
degree and compromise. These may not satisfy all
customers, and there is no intention here to prevent the building
more secure servers with more secure protocols to suit their needs
These are intended to satisfy the needs of the general public
3.1) It must be possible to create authoritative versions of
hint with access-to-modification privileges controlled
3.2) It must be possible to determine the identity of servers
avoid contact with unauthenticated servers
3.3) It must be possible to reduce the threat of denial
service by broad distribution of information across servers
3.4) It must be possible within the bounds of
policy criteria to provide at least some degree of
for traffic
Sollins Informational [Page 14]
RFC 2276 Uniform Resource Name Resolution January 1998
3.5) It must be possible for publishers to keep private
information such as an overall picture of the resources
are publishing and the identity of their clients
3.6) It must be possible for publishers to be able to
access to the resolution of the URNs for the resources
publish, if they wish
When one discusses security, one of the primary issues is
enumeration of the threats being considered for mitigation.
tradeoffs often include cost in money and computational
communications resources, ease of use, likelihood of use,
effectiveness of the mechanisms proposed. With this in mind, let
consider a set of threats
Voydock and Kent [5] provide a useful catalog of potential threats
Of these the passive threats to privacy or confidentiality and
active threats to authenticity and integrity are probably the
important to consider here. To the extent that spurious
causes threats to the privacy, authenticity, or integrity
respect to information within servers managing data, it is
important. Denial of service is probably the most difficult of
areas of threats both to detect and to prevent, and we will
set it aside for the present as well, although it will be seen
solutions to other problems will also mitigate some of the
of denial of service. Furthermore, because this is intended to
provide a global service to meet the needs of a variety
communities, the engineering tradeoffs will be different
different clients. Hence the guidelines are stated in terms of, "
must be possible..." It is important to note that the information
concern here is hint information, which by nature is not
to be correct or up-to-date; therefore, it is unlikely to be
putting too much expense into the correctness of hints, because
is no guarantee that they are still correct anyway. The exact
of degree of privacy, authenticity, and integrity must be
by the needs of the client and the availability of services from
server
To avoid confusion it is valuable to highlight the meanings of
that have different meanings in other contexts. In this case,
term "authoritative" as it is used here connotes the taking of
action or stamp of approval by a principal (again in the
sense) that has the right to perform such an act of approval. It
no implication of correctness of information, but only perhaps
implication of who claimed it to be correct. In contrast, the
is often also used simply to refer to a primary copy of a piece
information for which there may also be secondary or cached
available. In this discussion of security we use the former meaning
although it may also be important to be able to learn about whether
Sollins Informational [Page 15]
RFC 2276 Uniform Resource Name Resolution January 1998
piece of information is from a primary source or not and request
it be primary. This second meaning arises elsewhere in the
and is so noted there
It is also important to distinguish various possible meanings
"access control". There are two areas in which distinctions can
made. First, there is the question of the kind of access
that is being addressed, for example, in terms of hints whether it
read access, read and modify access, or read with verification
authenticity. Second, there is the question of to what access
being controlled. In the context of naming it might be the
themselves (not the case for URNs), the mapping of URNs to hints (
business of an RDS), the mapping of URNs to addresses (not
business of an RDS as will be discussed below in terms of privacy),
or the resource itself (unrelated to naming or name resolution
all). We attempt to be clear about what is meant when using "
control".
There is one further issue to address at this point, the
between mechanism and policy. In general, a policy is realized
means of a set of mechanisms. In the case of an RDS there may
policies internal to the RDS that it needs to have supported in
to do its business as it sees fit. Since, in general it is in
business of storing and distributing information, most of
security policies may have to do with maintaining its own integrity
and are rather limited. Beyond that, to the degree possible,
should impose no policy on its customers, the publishers and users
It is they that may have policies that they would like supported
the RDS. To that end, an RDS should provide a spectrum of "tools"
mechanisms that the customers can cause to be deployed on
behalf to realize policies. An RDS may not provide all that
needed by a customer. A customer may have different
within his or her administrative bounds than outside. Thus, "it
be possible..." captures the idea that the RDS must
provide the tools to implement policies as needed by the customers
The first approach to URN resolution is to discover local hints.
order for hints to be discovered locally, they will need to be
widely distributed as possible to what is considered to be local
every locale. The drawback of such wide distribution is the
distribution of updates, causing network traffic problems or
in delivering updates. An alternative model would concentrate
information in servers, thus requiring that update information
be distributed to these servers. In such a model the
points are the sources of the information and the
network among them. Attackers on the integrity of the
stored in a server may come in the form of masquerading as the
or the server of the information. Wide replication of
Sollins Informational [Page 16]
RFC 2276 Uniform Resource Name Resolution January 1998
among servers increases the difficult of masquerading at all
locations of the information as well as reducing the threat of
service. These lead us to three identifiable guidelines for
security model
* ACCESS CONTROL ON HINTS: It must be possible to create
authoritative version of each hint with change control limited
to those principals with the right to modify it. The choice of
those principals are or whether they are unlimited must be made
the publisher of a hint
* SERVER AUTHENTICITY: Servers and clients must be able to learn
identity of the servers with which they communicate. This will
a matter of degree and it is possible that there will be
trustworthy, but less accessible servers, supported by a
cluster of less authenticatable servers that are more
available. In the worst case, if the client receives what
to be unvalidated information, the client should assume that
hint may be inaccurate and confirmation of the data might be
from more reliable but less accessible sources
* SERVER DISTRIBUTION: Broad availability will provide resistance
denial of service. It is only to the extent that the services
available that they provide any degree of trustworthiness.
addition, the distribution of services will reduce vulnerability
the whole community, by reducing the trust put in any
server. This must be mitigated by the fact that to the
trust is based on a linked set of servers, if any one fails,
whole chain of trust fails; the more elements there are in such
chain, the more vulnerable it may become
Privacy can be a double-edged sword. For example, on one hand,
organization may consider it critically important that
competitors not be able to read its traffic. On the other hand,
may also consider it important to be able to monitor exactly what
employees are transmitting to and from whom, for a variety of
such as reducing the probability that its employees are giving
selling the company's secrets to verifying that employees are
using company resources for private endeavor. Thus, although
are likely to be needs for privacy and confidentiality, what
are, who controls them and how, and by what mechanisms vary
enough that it is difficult to say anything concrete about them here
The privacy of publishers is much easier to address. Since they
trying to publish something, in general privacy is probably
desired. However, publishers do have information that they
like to keep private: information about who their clients are,
information about what names exist in their namespace.
Sollins Informational [Page 17]
RFC 2276 Uniform Resource Name Resolution January 1998
information about who their clients are may be difficult to
depending on the implementation of the resolution system.
example, if the resolution information relating to a given
is widely replicated, the hits to _each_ replicated copy would
to be recorded. Of course, determining if a specific client
requesting a given name can be approached from the other direction
by watching the client as we saw above
There are likely to be some publishers publishing for a
audience. To the extent they want to restrict access to a resource
that is the responsibility of the repository providing
restricting access to the resource. If they wish to keep the
and hints for a resource private, a public RDS may be inadequate
their needs. In general, it is intended for those who want
to find their resources in an unconstrained fashion
The final privacy issue for publishers has to do with access
over URN resolution. This issue is dependent on the
of the publisher's authoritative (in the sense of "primary)
resolver server. URN resolver servers can be designed to
proof of identity in order to be issued resolution information;
the client does not have permission to access the URN requested,
service denies that such a URN exists. An encrypted protocol
also be used so that both the request and the response are obscured
Encryption is possible in this case because the identity of the
recipient is known (i.e. the URN server). Thus, access control
URN resolution can and should be provided by resolver servers
than an RDS
4. The
With these assumptions and guidelines in mind, we conclude with
general framework within which RDS designs may fall. As
earlier, although this framework is put forth as a suggested
for RDS designers, compliance with it will in no way
compliance with the guidelines. Such an evaluation must be
separately. All such lack of compliance should be
documented
The design of the framework is based on the syntax of a URN
documented in RFC-2141 [6]. This is
URN::
where URN: is a prefix on all URNs, NID is the namespace identifier
and NSS is the namespace specific string. The prefix identifies
URN as such. The NID determines the general syntax for all
within its namespace. The NSS is probably partitioned into a set
Sollins Informational [Page 18]
RFC 2276 Uniform Resource Name Resolution January 1998
delegated and subdelegated namespaces, and this is possibly
in further syntax specifications. In more complex environments,
delegated namespace will be permitted to choose the syntax of
variable part of the namespace that has been delegated to it.
simpler namespaces, the syntax will be restricted completely by
parent namespace. For example, although the DNS does not meet
the requirements for URNs, it has a completely restricted syntax
such that any further structuring must be done only by adding
refinements to the left, maintaining the high order to low order
right to left structure. A delegated syntax might be one in which
host is named by the DNS, but to the right of that and separated
an "@" is a string whose internal ordering is defined by the
system on the host, which may be defined high order to low order
left to right. Of course, much more complex and nested
should be possible, especially given the need to
namespaces. In order to resolve URNs, rules will be needed for
reasons. One is simply to canonicalize those namespaces that do
fall into a straightforward (probably right to left or left to right
ordering of the components of a URN, as determined by the
naming authorities involved. It is also possible that rules will
needed in order to derive from URNs the names of RDS servers to
used in stages
Sollins Informational [Page 19]
RFC 2276 Uniform Resource Name Resolution January 1998
URN:
|
|
|
|
+-------------------+
|Global NID registry
+-------------------+
|
|
|
(return rule or URN resolver service reference
|
+----------------------------------+
| |
+->(apply rule to determine RDS server) |
| | |
| | |
| | |
| +----------+ |
| |RDS server| +-----------------+
| +----------+ |
| | |
| | | (set of choices
| | +----+----------(...)--------+
| (rule) | |
| | | |
| | | |
+------+ | |
v
+----------+ +----------+
|URN | |URN |
|resolver | |resolver |
|service | |service |
+----------+ +----------+
Figure 1: An RDS
The NID defines a top level syntax. This syntax will
whether the NID alone or in conjunction with some extraction from
NSS (for the top level naming authority name) is to be used
identify the first level server to be contacted. At each stage
the lookup either a new rule for generating the strings used in
another lookup (the strings being the identity of another RDS
and possibly a string to be resolved if it is different than
original URN) or a reference outside the RDS to a URN
service, sidestepping any further use of the RDS scheme. Figure 1
Sollins Informational [Page 20]
RFC 2276 Uniform Resource Name Resolution January 1998
depicts this process
There are several points worth noting about the RDS framework
First, it leaves open the determination of the protocols,
organization, distribution and replication needed to support
particular RDS scheme. Second, it leaves open the location of
computations engendered by the rules. Third, it leaves open
possibility that partitioning (distribution) of the RDS database
not be on the same boundaries as the name delegation. This may
radical to some, but if the information is stored in balanced B-
for example, the partitioning may not be along those naming
delegation boundaries (see [7]). Lastly, it leaves open access
the Global NID Registry. Is this distributed to every client,
managed in widely distributed servers? It is important to note
it is the intention here that a single RDS scheme is likely
support names from many or all naming schemes, as embodied in
NIDs
One concept that has not been addressed in Figure 1 is that there
be more than one RDS available at any given time, in order to
for evolution to new schemes. Thus, the picture should probably
more like Figure 2.
Sollins Informational [Page 21]
RFC 2276 Uniform Resource Name Resolution January 1998
URN::
|
|
+-----------+-------(...)-------+
| |
| |
| |
v
+---------------------+ +---------------------+
|Global NID registry 1| |Global NID registry N
+---------------------+ +---------------------+
. .
. .
. .
Figure 2: More than one co-existing RDS
If we are to support more than one co-existing RDS scheme, there
need to be coordination among them with respect to storage
propagation of information and modifications. The issue is
generally it should be assumed that all information should
available through any operational RDS scheme. One cannot
potential publishers to submit updates to more than one RDS scheme
Hence there will need to be a straightforward mapping of
from one to the other of these schemes. It is possible that
transformation will only go in one direction, because a newer
service is replacing an older one, which is not kept up to date,
order to encourage transfer to the newer one. Thus, at some point
updates may be made only to the newer one and not be made
to the older one, as is often done with library catalogs
This framework is presented in order to suggest to RDS
designers a direction in which to start designing. It should
obvious to the reader that adherence to this framework will in no
guarantee compliance with the guidelines or even the
described in Sections 2 and 3. These must be reviewed
as part of the design process. There is no single correct
that will conform to these guidelines. Furthermore, it is
that preliminary proposals may not meet all the guidelines,
should be expected to itemized and justify any lack of compliance
Sollins Informational [Page 22]
RFC 2276 Uniform Resource Name Resolution January 1998
5.
Foremost acknowledgment for this document goes to Lewis Girod, as
co-author on a preliminary URN requirements document and for
insightful comments on this version of the document. Thanks also
to Ron Daniel especially for his many comments on my writing.
addition, I recognize the contributors to a previous URN
document, the "Knoxville" group. There are too many of you
acknowledge here individually, but thank you. Finally, I must
the contributors to the URN working group and mailing list (urn
ietf@bunyip.com), for your animated discussions on these and
topics
6.
[1] Kunze, J., "Functional Recommendations for Internet
Locators", RFC 1736, February 1995.
[2] Sollins, K., and L. Masinter, "Functional Requirements
Uniform Resource Names", RFC 1738, December 1994.
[3] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Locators (URL)", RFC 1738, December 1994.
[4] URN Working Group, "Namespace Identifier Requirements for
Services," Work in Progress
[5] Voydock, V. L., and Kent, S. T., "Security Mechanisms in High
Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 1983,
pp. 135-171.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Slottow, E.G., "Engineering a Global Resolution Service," MIT
LCS-TR712, June, 1997. Currently available
.
7. Author's
Karen
MIT Laboratory for Computer
545 Technology Sq
Cambridge, MA 02139
Phone: +1 617 253 6006
EMail: sollins@lcs.mit.
Sollins Informational [Page 23]
RFC 2276 Uniform Resource Name Resolution January 1998
8. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Sollins Informational [Page 24]
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
