draft-ietf-urn-req-frame-00.txt   draft-ietf-urn-req-frame-01.txt 
Internet Draft Karen R. Sollins Internet Draft Karen R. Sollins
draft-ietf-urn-req-frame-00.txt MIT/LCS draft-ietf-urn-req-frame-01.txt MIT/LCS
Expires May 26, 1997 November 26, 1996 Expires September 28, 1997 March 28, 1997
Requirements and a Framework for URN Resolution Systems Requirements and a Framework for URN Resolution Systems
Status of this draft Status of this draft
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at line 29 skipping to change at line 29
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract: Abstract:
This document addresses the issues of the discovery of local URN This document addresses the issues of the discovery of local URN
resolution services that in turn will directly translate URNs into resolver services that in turn will directly translate URNs into
URLs and URCs. The document falls into three major parts, the URLs and URCs. The document falls into three major parts, the
assumptions underlying the work, the requirements in order to be a assumptions underlying the work, the requirements in order to be a
viable URN-resolution-service discovery service or UDS, and a viable Resolver Discovery Service or RDS to help in finding URN
framework for designing UDSs. The requirements fall into three major resolvers, and a framework for designing RDSs. The requirements fall
areas: evolvability, usability, and security and privacy. A UDS that into three major areas: evolvability, usability, and security and
is compliant with the framework will not necessarily be compliant with privacy. An RDS that is compliant with the framework will not
the requirements. Compliance with the requirements will need to be necessarily be compliant with the requirements. Compliance with the
validated separately. requirements will need to be validated separately.
1. Introduction 1. Introduction
The purpose of this document is to lay out the engineering criteria for The purpose of this document is to lay out the engineering criteria
what we will call here a URN-resolution-service discovery service (UDS). for what we will call here a Resolver Discovery Service (RDS), a
__________ service to help in the learning about URN resolvers. This is a
component of the realization of an information infrastructure. In the
Acknowledgments case of this work, that infrastructure is to be available, "in the
Internet" or globally, and hence the solutions to the problems we are
Foremost acknowledgment for this document goes to Lewis Girod, as my addressing must globally scalable. In this work, we are focussing
co-author on a previous URN requirements document and for his insightful specifically on naming of resources and resolution of those names to
comments on this version of the document. In addition, I recognize the the exclusion of other problems such as typing, resource access and
contributors to a previous URN framework document, the "Knoxville"
group. There are too many of you to acknowledge here individually, but
thank you. Finally, I must thank the contributors to the URN working
group mailing list (urn-ietf@bunyip.com), for their animated discussions
on these and related topics.
URN Resolution Requirements Page 1
This is a component of the realization of an information infrastructure.
In the case of this work, that infrastructure is to be available, "in
the Internet" or globally, and hence the solutions to the problems we
are addressing must globally scalable. In this work, we are focussing
specifically on naming of resources and resolution of those names to the
exclusion of other problems such as typing, resource access and
availability, security of the resources, etc. Those are all important availability, security of the resources, etc. Those are all important
problems, but not part of this effort. problems, but not part of this effort.
The Uniform Resource Identifier Working Group defined a naming The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736[RFC1736], architecture, as demonstrated in a series of three RFCs 1736[RFC1736],
- 1 -
1737{RFC1737}, and 1738[RFC1738]. Although several further documents 1737{RFC1737}, and 1738[RFC1738]. Although several further documents
are needed to complete the description of that architecture, it are needed to complete the description of that architecture, it
incorporates three core functions often associated with "naming": incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics. Names may provide identification, location, and mnemonics or semantics. By location, we
the ability to distinguish one resource from another, by distinguishing mean full-qualified Domain Names or IP addresses. Names may provide
their "names". Names may help to provide access to a resource by the ability to distinguish one resource from another, by
including "location" information. Lastly, names may have other semantic distinguishing their "names". Names may help to provide access to a
or mnemonic information that either helps human users remember or figure resource by including "location" information. Lastly, names may have
out the names, or include other semantic information about the resource other semantic or mnemonic information that either helps human users
being named. The URI working group concluded that there was need for remember or figure out the names, or include other semantic
persistent, globally unique identifiers, distinct from location or other information about the resource being named. The URI working group
semantic information; these "names" provide identity, in that if two of concluded that there was need for persistent, globally unique
them are "the same" (under some simple rule of canonicalization), they identifiers, distinct from location or other semantic information;
identify the same resource. Furthermore, the group decided that these these "names" provide identity, in that if two of them are "the same"
"names" were generally to be for machine, rather than human consumption. (under some simple rule of canonicalization), they identify the same
One can imagine a variety human-friendly naming (HFN) schemes supporting resource. Furthermore, the group decided that these "names" were
different suites of applications and user communities. These will need generally to be for machine, rather than human consumption. One can
to provide mappings to URNs in tighter or looser couplings, depending on imagine a variety human-friendly naming (HFN) schemes supporting
the namespace. It is these that will be mnemonic, content-full, and different suites of applications and user communities. These will
perhaps mutable, to track changes in use and semantics. They may need to provide mappings to URNs in tighter or looser couplings,
provide nicknaming and other aliasing, relative or short names, context depending on the namespace. It is these that will be mnemonic,
sensitive names, descriptive names, etc. The URI naming architecture as content-full, and perhaps mutable, to track changes in use and
described in the introductions to RFCs 1736 and 1737 lays out three semantics. They may provide nicknaming and other aliasing, relative
sorts of components to the naming architecture: identifiers called or short names, context sensitive names, descriptive names, etc. The
Uniform Resource Names (URNs), locators called Uniform Resource Locators URI naming architecture as described in the introductions to RFCs 1736
(URLs) and semantic meta-information called Uniform Resource and 1737 lays out three sorts of components to the naming
Characteristics (URCs). This document focusses on part of the problem architecture: identifiers called Uniform Resource Names (URNs),
of the translation from URN to URL and/or URC. locators called Uniform Resource Locators (URLs) and semantic
meta-information called Uniform Resource Characteristics (URCs). This
document focusses on part of the problem of the translation from URN
to URL and/or URC.
Within the URI community there has been a concept used frequently that Within the URI community there has been a concept used frequently that
for lack of a better term we will call a _hint_. A hint is something for lack of a better term we will call a _hint_. A hint is something
that helps in the resolution of a URN. Examples of hints are: 1) the that helps in the resolution of a URN; we map URNs to hints as an
name of a resolution service that may further resolve the URN, 2) the interim stage in accessing a resource. A hint may also have
address of such a service, 3) a location at which the resource was meta-information associated with it, such as an expiration_time or
previously found. The defining feature of hints is that they are only certification of authenticity. We expect that these will stay with a
hints; they may be out of date, temporarily invalid, or only applicable hint rather than being managed elsewhere. We will assume in all
within a specific locality. They do not provide a guarantee of access, further discussion of hints that they include any necessary
but they probably will help in the resolution process. Wemust assume meta-information as well as the hint information itself. Examples of
that most resolutions of URNs will be provided by the use of locally hints are: 1) the name of a resolver service that may further resolve
stored hints, because maintaining a database of globally available, the URN, 2) the address of such a service, 3) a location at which the
completely up-to-date location information is infeasible for performance resource was previously found. The defining feature of hints is that
reasons. There are a number of circumstances in which one can imagine they are only hints; they may be out of date, temporarily invalid, or
that hints become invalid, either because a resource has moved or only applicable within a specific locality. They do not provide a
because a different URN resolution service has taken over the guarantee of access, but they probably will help in the resolution
process. We must assume that most resolutions of URNs will be
provided by the use of locally stored hints, because maintaining a
database of globally available, completely up-to-date location
information is infeasible for performance reasons. There are a number
of circumstances in which one can imagine that hints become invalid,
either because a resource has moved or because a different URN
resolver service has taken over the responsibility for resolution of
the URN. Hints may be found in a variety of places. It is generally
assumed that a well engineered system will maintain a set of hints for
URN Resolution Requirements Page 2 - 2 -
responsibility for resolution of the URN. Hints may be found in a each URN at each location where that URN is found. In addition, for
variety of places. It is generally assumed that a well engineered those situations in which those hints found locally fail, a
system will maintain a set of hints for each URN at each location where well-engineered system will provide a fall-back mechanism for
that URN is found. In addition, for those situations in which those discovering further hints. It is this fall-back mechanism, an RDS,
hints found locally fail, a well-engineered system will provide a that is being addressed in this document. As with all hints, there
fall-back mechanism for discovering further hints. It is this fall-back can never be a guarantee that access to a resource will be available
mechanism, a UDS, that is being addressed in this document. As with all to all clients, even if the resource is accessible to some. However,
hints, there can never be a guarantee that access to a resource will be an RDS is expected to work with reasonably high reliability, and,
available to all clients, even if the resource is accessible to some. hence, may result in increased response time.
However, a UDS is expected to work with reasonably high reliability,
and, hence, may result in increased response time. The remainder of The remainder of this document falls into three sections. The first
this document falls into three sections. The first identifies several identifies several sets of assumptions underlying this work. The next
sets of assumptions underlying this work. The next lays out the lays out the requirements for a Resolver Discovery Service. This
requirements for a URN-resolution-service discovery service. This
section is probably the most critical of the document, because it is section is probably the most critical of the document, because it is
this that provides the metric for whether or not a proposed scheme for a this that provides the metric for whether or not a proposed scheme for
UDS is adequate or not. For the reader short on time, each of the three a RDS is adequate or not. For the reader short on time, each of the
major subsections of the requirements section concludes with a summary three major subsections of the requirements section begins with a
list of the requirements identified in that section. The final section summary list of the requirements identified in that section. The
of the document lays out a framework for such UDSs. The purpose of this final section of the document lays out a framework for such RDSs. The
last section is to bound the search space for UDS schemes. One must be purpose of this last section is to bound the search space for RDS
careful not to assume that because a UDS scheme fits within the schemes. One must be careful not to assume that because an RDS scheme
framework that it necessarily meets the requirements. As will be fits within the framework that it necessarily meets the requirements.
discussed further in this last section, designing within the framework As will be discussed further in this last section, designing within
does not guarantee compliance, so compliance evaluation must also be the framework does not guarantee compliance, so compliance evaluation
part of the process of evaluation of a scheme. must also be part of the process of evaluation of a scheme.
2. Assumptions 2. Assumptions
Based on previous internet drafts and discussion in both the URN BOFs Based on previous internet drafts and discussion in both the URN BOFs
and on the URN WG mailing list, three major areas of assumptions are and on the URN WG mailing list, three major areas of assumptions are
apparent: longevity, delegation, and independence. Each will be apparent: longevity, delegation, and independence. Each will be
discussed separately. discussed separately.
The URN requirements state that a URN is to be a "persistent The URN requirements state that a URN is to be a "persistent
identifier". It is probably the case that nothing will last forever, identifier". It is probably the case that nothing will last forever,
but in the time frame of resources, users of those resources, and the but in the time frame of resources, users of those resources, and the
systems to support the resources, the identifier should be considered to systems to support the resources, the identifier should be considered to
be persistent or have a longer lifetime than those other entities. be persistent or have a longer lifetime than those other entities.
There are two assumptions that are implied by longevity of URNs: There are two assumptions that are implied by longevity of URNs:
mobility and evolution. "Mobility" assumes that. everything will move mobility and evolution. "Mobility" assumes that everything will move
over the life of a URN. For example, resources will move from one over the life of a URN. For example, resources will move from one
machine to another, because individual machines have a much shorter machine to another, because individual machines have a much shorter
lifetime than resources, generally measured in a number of years less lifetime than resources, generally measured in a number of years less
than a decade. Owners of resources may move and wish their resources to than a decade. Owners of resources may move and wish their resources to
follow them. The services themselves will move. "Evolutions" assumes follow them. The services themselves will move. "Evolution" assumes
that the supporting infrastructure will evolve. This may take the form that the supporting infrastructure will evolve. This may take the form
of entirely new transport protocols or new versions of existing of entirely new transport protocols or new versions of existing
protocols. Furthermore, services such as storage services may evolve; protocols. Furthermore, services such as storage services may evolve;
it is even possible that within a human lifetime the Unix file system it is even possible that within a human lifetime the Unix file system
model may no longer be in use! Clearly there will be evolution of and model may no longer be in use! Clearly there will be evolution of and
improvement in supporting authentication and security mechanisms. These improvement in supporting authentication and security mechanisms. These
are only examples. In general, we must assume that almost any piece of are only examples. In general, we must assume that almost any piece of
the supporting infrastructure of URN resolution will evolve. In order the supporting infrastructure of URN resolution will evolve. In order
to deal with both the mobility and evolution assumptions that derive to deal with both the mobility and evolution assumptions that derive
from the assumption of longevity, we must assume that users and their
URN Resolution Requirements Page 3 - 3 -
from the assumption of longevity, we must assume that users and their
applications can remain independent of these mutating details of the applications can remain independent of these mutating details of the
supporting infrastructure. supporting infrastructure.
The second and third assumptions are two forms of modularity, delegation The second and third assumptions are two forms of modularity: delegation
and isolation. The delegation assumption is that an entity may and isolation. The delegation assumption is that an entity may
partition and pass off some of its authority or responsibility. One of partition and pass off some of its authority or responsibility. One of
those responsibilities is for assigning URNs; practically speaking, those responsibilities is for assigning URNs; practically speaking,
there cannot be only a single authority for assigning URNs. We expect there cannot be only a single authority for assigning URNs. We expect
that there will be a multi-tiered naming authority delegation. that there will be a multi-tiered naming authority delegation.
Furthermore, it is difficult to imagine a non-partitioned and delegated Furthermore, it is difficult to imagine a non-partitioned and delegated
global UDS, meaning that hint discovery and resolution will be global RDS, meaning that hint discovery and resolution will be
partitioned and delegated. In some UDS schemes, the delegation of partitioned and delegated. In some RDS schemes, the delegation of
naming authority will form a basis for delegating the management and naming authority will form a basis for delegating the management and
dispensing of location information. dispensing of location information.
The third assumption is independence or isolation of one authority from The third assumption is independence or isolation of one authority from
another and, at least to some extent from its parent. Underlying much another and, at least to some extent from its parent. Underlying much
of the thinking and discussion in the URI and URN working groups has of the thinking and discussion in the URI and URN working groups has
been the assumption that when a component delegates authority to another been the assumption that when a component delegates authority to another
component, the delegatee can operate in that domain independently of its component, the delegatee can operate in that domain independently of its
peers and within bounds specified by the delegation, independently of peers and within bounds specified by the delegation, independently of
the delegator. This isolation is critically important in order to allow the delegator. This isolation is critically important in order to allow
for independence of policy and mechanism. for independence of policy and mechanism.
There are a number of more specific assumptions that fall under this There are a number of more specific assumptions that fall under this
rubric of isolation. First, we assume that the publisher of a resource rubric of isolation. First, we assume that the publisher of a resource
can choose resolution services, independently of choices made by others. can choose resolver services, independently of choices made by others.
At any given time, the owner of a namespace may choose a particular URN At any given time, the owner of a namespace may choose a particular URN
resolution service for that delegated namespace. Such a URN resolution resolver service for that delegated namespace. Such a URN resolver
service may be outside the UDS service model, and just identified or service may be outside the RDS service model, and just identified or
located by the UDS service. Second, it must be possible to make a located by the RDS service. Second, it must be possible to make a
choice among UDS services, perhaps based on different underlying choice among RDS services, perhaps based on different underlying
internal architectures. The reason that this is an assumption is that internal architectures. The reason that this is an assumption is that
there must be an evolutionary path through a sequence of core UDS there must be an evolutionary path through a sequence of core RDS
services. Although at any given time there is likely to be only one or services. Although at any given time there is likely to be only one or
a small set of such services, the number is likely to increase during a a small set of such services, the number is likely to increase during a
transition period from one architecture to another. Thus, it must be transition period from one architecture to another. Thus, it must be
assumed that clients can make a choice among a probably very small set assumed that clients can make a choice among a probably very small set
of UDSs. Third, there must be independence in the choice about levels of RDSs. Third, there must be independence in the choice about levels
and models of security and authenticity required. This choice may be and models of security and authenticity required. This choice may be
made by the owner of a naming subspace, in controlling who can modify made by the owner of a naming subspace, in controlling who can modify
hints in that subspace. A naming authority may delegate this choice to hints in that subspace. A naming authority may delegate this choice to
the owners of the resources named by the names it has assigned. There the owners of the resources named by the names it has assigned. There
may be limitations on this freedom of choice in order to allow other may be limitations on this freedom of choice in order to allow other
participants to have the level of security and authenticity they participants to have the level of security and authenticity they
require, for example, in order to maintain the integrity of the UDS require, for example, in order to maintain the integrity of the RDS
infrastructure as a whole. Fourth, there is an assumption of infrastructure as a whole. Fourth, there is an assumption of
independence of choice of the rule of canonicalization of URNs within a independence of choice of the rule of canonicalization of URNs within a
namespace, limited by any restrictions or constraints that may have been namespace, limited by any restrictions or constraints that may have been
set by its parent namespace. This is a choice held by naming set by its parent namespace. This is a choice held by naming
authorities over their own subnamespaces. Rules for canonicalization authorities over their own subnamespaces. Rules for canonicalization
will be discussed further in the framework section below. Thus, there will be discussed further in the framework section below. Thus, there
are assumptions of independence and isolation to allow for delegated, are assumptions of independence and isolation to allow for delegated,
independent authority in a variety of domains. independent authority in a variety of domains.
URN Resolution Requirements Page 4 - 4 -
The modularity assumptions of delegation and isolation imply The modularity assumptions of delegation and isolation imply
independence of decision and implementation, leading to a independence of decision and implementation, leading to a
decentralization that provides a certain degree of safety from denial of decentralization that provides a certain degree of safety from denial of
service. Based on these these assumptions in conjunction with that of service. Based on these these assumptions in conjunction with that of
longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737,
we can now turn to the requirements for a URN services delegation we can now turn to the requirements for a Resolver Discovery Service.
service.
3. Requirements 3. Requirements
The requirements applying to a URN-resolution-service discovery service The requirements applying to a Resolver Discovery Service or RDS
or UDS center around three important design goals: evolvability, center around three important design goals: evolvability, usability,
usability, and security and privacy. At its core the function of a UDS and security and privacy. At its core the function of an RDS is to
is to provide hints for accessing a resource given a URN for it. These provide hints for accessing a resource given a URN for it. These
hints may range in applicability from local to global, and from hints may range in applicability from local to global, and from
short-lived to long-lived. They also may vary in their degree of short-lived to long-lived. They also may vary in their degree of
verifiable authenticity. While it may be neither feasible nor necessary verifiable authenticity. While it may be neither feasible nor
that initial implementations support every requirement, every necessary that initial implementations support every requirement,
implementation must support evolution to systems that do support every every implementation must support evolution to systems that do support
requirement. every requirement.
It is also important to note that there are other requirements, not It is important to note that there are other requirements, not
applicable specifically to a UDS that must also be met. A whole URN applicable specifically to an RDS that must also be met. A whole URN
system will consist of namespaces, the resolution information for them, system will consist of namespaces, the resolution information for them,
and the mapping from names in the namespaces to resolution information and the mapping from names in the namespaces to resolution information
(or hints). URN schemes must meet the requirements of RFC 1737. (or hints). URN schemes must meet the requirements of RFC 1737.
Resolution information, to the extent it is expressed as URLs must meet Resolution information, to the extent it is expressed as URLs must meet
the requirements of RFC 1736. But this does not tell the whole story. the requirements of RFC 1736. But this does not tell the whole story.
Although the URN working group will identify several acceptable Although the URN working group will identify several acceptable
namespaces and the rules binding them, such as how delegation occurs, namespaces and the rules binding them, such as how delegation occurs,
how it is expressed in the names, how and to what extent binding to hint how it is expressed in the names, how and to what extent binding to hint
information will be constrained by the namespace, in the long run a information will be constrained by the namespace, in the long run a
document will be needed to guide the evaluation criteria for acceptance document will be needed to guide the evaluation criteria for acceptance
of new namespaces. These are not included in the list of requirements of new namespaces. These are not included in the list of requirements
below because they are not requirements for a UDS, but rather for naming below because they are not requirements for an RDS, but rather for naming
schemes themselves. schemes themselves.
Each section below begins with a summary of the points made and discussed
in the following discussion. It is worth noting here that there is
some degree of overlap in the areas of requirements, such as in
allowing for the evolution of security mechanisms, etc. Issues may
appear in more than one requirement. It is also important to
recognize that conformance with the requirements may often be
subjective. Most of these requirements are not quantifiable and hence
conformance is a judgment call and a matter of degree. Lastly, the
reader may find that some of the requirements are those of general
applicability to distributed systems and some are specific to URN
resolution. Those of general applicability are included for
completeness and are not distinguished as such.
3.1 Evolution 3.1 Evolution
The requirements in the area of evolvability are:
[R1] To support evolution of mechanisms, specifically for
{R1.1] a growing set of URN schemes;
- 5 -
[R1.2] new kinds local URN resolver services;
[R1.3] new authentication schemes;
[R1.4] alternative RDS schemes active simultaneously;
[R2] To support the separation of global identification from
location information.
[R3] To allow for the support the development and deployment of
administrative control mechanisms to manage human behavior
with respect to limited resources.
One of the lessons of the Internet that we must incorporate into the One of the lessons of the Internet that we must incorporate into the
development of mechanisms for resolving URNs is that we must be prepared development of mechanisms for resolving URNs is that we must be prepared
for change. Such changes may happen slowly enough to be considered for change. Such changes may happen slowly enough to be considered
evolutionary modifications of existing services or dramatically enough evolutionary modifications of existing services or dramatically enough
to be considered revolutionary. They may permeate the Internet universe to be considered revolutionary. They may permeate the Internet universe
bit by bit, living side by side with earlier services or they may take bit by bit, living side by side with earlier services or they may take
the Internet by storm, causing an apparent complete transformation over the Internet by storm, causing an apparent complete transformation over
a short period of time. There are several directions in which we can a short period of time. There are several directions in which we can
predict the need for evolution, even at this time, prior to the predict the need for evolution, even at this time, prior to the
deployment of any such service. At the very least, the community and deployment of any such service. At the very least, the community and
the mechanisms proposed should be prepared for these. the mechanisms proposed should be prepared for these.
First, we expect there to be additions and changes to the mechanisms. First, we expect there to be additions and changes to the mechanisms.
The community already understands that there must be a capacity for new The community already understands that there must be a capacity for new
URN schemes. A URN scheme will define a set of URNs that meet the URN URN schemes. A URN scheme will define a set of URNs that meet the URN
requirements[RFC1737], but may have further constraints on the internal requirements[RFC1737], but may have further constraints on the internal
URN Resolution Requirements Page 5
structure of the URN. The requirements document would allow for an structure of the URN. The requirements document would allow for an
overall plan in which URN schemes are free to specify parts of the URN overall plan in which URN schemes are free to specify parts of the URN
that are left opaque in the larger picture. In fact, a URN scheme may that are left opaque in the larger picture. In fact, a URN scheme may
choose to make public the algorithms for any such "opaque" part of the choose to make public the algorithms for any such "opaque" part of the
URN. For example, although it may be unnecessary to know the structure URN. For example, although it may be unnecessary to know the structure
of an ISBN, the algorithm for understanding the structure of an ISBN has of an ISBN, the algorithm for understanding the structure of an ISBN has
been made public. Other schemes may either choose not to make their been made public. Other schemes may either choose not to make their
algorithms public, or choose a scheme in which knowledge of the scheme algorithms public, or choose a scheme in which knowledge of the scheme
does not provide any significant semantics to the user. In any case, we does not provide any significant semantics to the user. In any case, we
must be prepared for a growing number of URN schemes. must be prepared for a growing number of URN schemes.
Often in conjunction with a new URN scheme, but possibly independently Often in conjunction with a new URN scheme, but possibly independently
of any particular URN scheme, new resolution services may evolve. For of any particular URN scheme, new kinds of resolver services may
example, one can imagine a specialized resolution service based on the evolve. For example, one can imagine a specialized resolver service
particular structure of ISBNs that improves the efficiency of finding based on the particular structure of ISBNs that improves the
documents given their ISBNs. Alternatively, one can also imagine a efficiency of finding documents given their ISBNs. Alternatively, one
general purpose resolution service that trades performance for can also imagine a general purpose resolver service that trades
generality; although it exhibits only average performance resolving performance for generality; although it exhibits only average
ISBNs, it makes up for this weakness by understanding all existing URN performance resolving ISBNs, it makes up for this weakness by
schemes, so that its clients can use the same service to resolve URNs understanding all existing URN schemes, so that its clients can use
regardless of naming scheme. In this context, there will always be room the same service to resolve URNs regardless of naming scheme. In this
for improvement of services, through improved performance, better context, there will always be room for improvement of services,
adaptability to new URN schemes, or lower cost. In any case, new models through improved performance, better adaptability to new URN schemes,
for URN resolution will evolve and we must be prepared to allow for or lower cost. In any case, new models for URN resolution will evolve
their participation in the overall resolution of URNs. and we must be prepared to allow for their participation in the
overall resolution of URNs.
If we begin with one overall plan for URN resolution, into which the If we begin with one overall plan for URN resolution, into which the
enhancements described above may fit, we must also be prepared for an enhancements described above may fit, we must also be prepared for an
- 6 -
evolution in the authentication schemes that will be considered either evolution in the authentication schemes that will be considered either
useful or necessary in the future. There is no single globally accepted useful or necessary in the future. There is no single globally accepted
authentication scheme, and there may never be one. Even if one does authentication scheme, and there may never be one. Even if one does
exist at some point in time, there will always be threats to it, and so exist at some point in time, there will always be threats to it, and so
we must always be prepared to move on to newer and better schemes, as we must always be prepared to move on to newer and better schemes, as
the old ones become too easily spoofed or guessed. the old ones become too easily spoofed or guessed.
Lastly, in terms of mechanism, although we may develop and deploy a Lastly, in terms of mechanism, although we may develop and deploy a
single UDS scheme initially, we must be prepared for that top level single RDS scheme initially, we must be prepared for that top level
model to evolve. Thus, if the UDS model supports an apparently model to evolve. Thus, if the RDS model supports an apparently
centralized (from a policy standpoint) scheme for inserting and centralized (from a policy standpoint) scheme for inserting and
modifying authoritative information, over time we must be prepared to modifying authoritative information, over time we must be prepared to
evolve to a different model, perhaps one that has a more distributed evolve to a different model, perhaps one that has a more distributed
model of authority and authenticity. If the model has no core but model of authority and authenticity. If the model has no core but
rather a cascaded partial discovery of information, we may find that rather a cascaded partial discovery of information, we may find that
this becomes unmanageable with an increase in scaling. Whatever the this becomes unmanageable with an increase in scaling. Whatever the
core of the model, we must be prepared for it to evolve with changes in core of the model, we must be prepared for it to evolve with changes in
scaling, performance, and policy constraints such as security and cost. scaling, performance, and policy constraints such as security and cost.
Second, in addition to the evolution of resolution mechanisms, we expect Second, in addition to the evolution of resolution mechanisms, we
that the community will follow an evolutionary path towards the expect that the community will follow an evolutionary path towards the
separation of semantics from identification. The URN requirements separation of location information from identification. The URN
document suggested this path as well, and there has been general requirements document suggested this path as well, and there has been
agreement in much of the community that such a separation is desirable. general agreement in much of the community that such a separation is
This is a problem that the public at large has generally not understood. desirable. This is a problem that the public at large has generally
Today we see the problem most clearly with the use of URLs for not understood. Today we see the problem most clearly with the use of
identification. When a web page moves, its URL becomes invalid. URLs for identification. When a web page moves, its URL becomes
invalid. Suppose such a URL is embedded in some page, stored in long
URN Resolution Requirements Page 6 term storage. There are three possible outcomes to this scenario.
One possibility is that the client is left high and dry with some
Suppose such a URL is embedded in some page, stored in long term message saying that the page cannot be found. Alternatively, a
storage. There are three possible outcomes to this scenario. One "forwarding pointer" may be left behind, in the form of an explicit
possibility is that the client is left high and dry with some message page requesting the client to click on a new URL. Although this will
saying that the page cannot be found. Alternatively, a "forwarding allow the client to find the intended page, the broken link cannot be
pointer" may be left behind, in the form of an explicit page requesting fixed because the URL is embedded in a file outside of the client's
the client to click on a new URL. Although this will allow the client control. A third alternative is that the target server supplies an
to find the intended page, the broken link cannot be fixed because the HTTP redirect so that the new page is provided for the client
URL is embedded in a file outside of the client's control. A third automatically. In this case, the client may not even realize that the
alternative is that the target server supplies an HTTP redirect so that URL is no longer correct. The real problem with both of these latter
the new page is provided for the client automatically. In this case, two situations is that they only work as long as the forwarding
the client may not even realize that the URL is no longer correct. The pointer can be found at the old URL. Location information, was
real problem with both of these latter two situations is that they only embedded in the identifier, and the resolution system was designed to
work as long as the forwarding pointer can be found at the old URL. depend on that location information being correct. There are few
Semantics, in this case location information, was embedded in the cases in which we can expect such information to remain valid for a
identifier, and the resolution system was designed to depend on the long time, but in many cases references need to have long lifespans.
semantics being correct. There are few cases in which we can expect Most documents are only useful while their references still function.
semantics of any sort to remain valid for a long time, but in many cases To the extent that an RDS scheme supports the separation of global
references need to have long lifespans. Most documents are only useful identification from location information it will be encouraging the
while their references still function. longer utility of the identities.
We expect the evolution to separation of semantics from identification
to move along at least three paths. The first will be to develop
temporary aliases to capture the semantics currently embedded in
identifiers. This will require additional translation, but it will
allow for the development of semantics-free URNs. Second, we expect
locally shared or private aliases to arise, again supported by a
translation mechanism and allowing for the long-term storage of global,
semantics-free URNs. Such an aliasing scheme may be used to permit
local aliases for named resources as well as to present these aliases to
users in lieu of the URNs themselves. Lastly, we expect there may be a
development of global aliases. These will be more user friendly "names"
that would be shared on a much larger scale, and might be defined in
some global registry. This may include trademarked names as well as
names in extremely common use. As with the other alias systems, a
facility for translation is needed. However, in this case, since the
system of aliases is of global scope, the translation facility will be
very slow if each time an alias is translated it needs to query a
centralized or even reasonably distributed global registry. In order to
achieve acceptable speeds, the translation facility will need to
maintain a local cache, possibly in cooperation with other nearby alias
caches. Clearly this is all postulation at present, but it is provided
here to demonstrate some of the scope of evolution for which we must be
prepared.
A third evolutionary requirement is even more mechanical than the A third evolutionary requirement is even more mechanical than the
others. At any point in time, the community is likely to be supporting others. At any point in time, the community is likely to be
a compromise position with respect to resolution. We will probably be supporting a compromise position with respect to resolution. We will
operating in a situation balanced between feasibility and the ideal, probably be operating in a situation balanced between feasibility and
perhaps with policy controls used to help stabilize the service. the ideal, perhaps with policy controls used to help stabilize the
Ideally, the service would be providing exactly what the customers
wanted and they in turn would not request more support than they need.
Since we will always be in a situation in which some service provision
resources will be in short supply, some form of policy controls will
always be necessary. For example, suppose hint entries are being
submitted in such volume that the hint servers are using up their excess
URN Resolution Requirements Page 7 - 7 -
capacity and need more disk space. An effective solution to this service. Ideally, the service would be providing exactly what the
problem would be a mechanism such as a pricing policy. This pricing customers wanted and they in turn would not request more support than
policy has the dual effect of both encouraging conservative use of they need. Since we will always be in a situation in which some
resources and collecting revenue for the improvement and maintenance of service provision resources will be in short supply, some form of
the system. As technology changes and the balance of which resources policy controls will always be necessary. Some policy controls may be
are in short supply changes, the mechanisms and policies for controlling realized as mechanisms within the servers or in the details of
their use must evolve as well. protocols, while others may only be realized externally to the system.
For example, suppose hint entries are being submitted in such volume
that the hint servers are using up their excess capacity and need more
disk space. An effective solution to this problem would be a
mechanism such as a pricing policy. This pricing policy has the dual
effect of both encouraging conservative use of resources and
collecting revenue for the improvement and maintenance of the system.
We can also imagine administrative policy controls with the force of
laws or other social pressures behind them, but with no technical
mechanism enforcing or enabling them. As technology changes and the
balance of which resources are in short supply changes, the mechanisms
and policies for controlling their use must evolve as well.
In summary, the requirements in the area of evolvability are: 3.2 Usability and Feature Set Requirements
* To support evolution of mechanisms, specifically for To summarize, the usability requirements fall into three areas based on
a) a growing set of URN schemes; participation in hint management and discovery:
b) new local URN resolution schemes;
c) new authentication schemes;
d) alternative UDS schemes active simultaneously;
* To support and encourage the evolution toward the separation of
global identification from short-lived, locally useful, or human
friendly semantics;
* To support the development and deployment of pricing models to
manage human behavior with respect to limited resources.
3.2 Usability and Feature Set Requirements * The publisher
[R4] URN to hint resolution must be correct and efficient with
very high probability;
[R5] Publishers must be able to select and move among URN
resolver services to locate their resources;
[R6] Publishers should be able to arrange for multiple access
points for their location information;
[R7] Publishers must be able to provide for both long-lived and
short-lived hints;
[R8] It must be relatively easy for publishers to specify to the
management and observer their hint information as well as
any security constraints they need for their hints.
* The client
[R9] The interface to the RDS must be simple, effective, and
efficient;
[R10] The client and client applications must be able to understand
the information stored in and provided by the RDS easily,
in order to be able to make informed choices.
* The management
[R11] The management of hints must be as unobtrusive as possible,
avoiding using too many network resources;
[R12] The management of hints should allow for administrative
controls that encourage certain sorts of behavior deemed
necessary to meet other requirements;
[R13] The configuration and verification of configuration of
individual RDS servers must be simple enough not to
discourage configuration and verification.
Usability can be evaluated from three distinct perspectives: those of a Usability can be evaluated from three distinct perspectives: those of a
publisher wishing to make a piece of information public, those of a publisher wishing to make a piece of information public, those of a
- 8 -
client requesting URN resolution, and those of the provider or manager client requesting URN resolution, and those of the provider or manager
of resolution information. We will separately address the usability of resolution information. We will separately address the usability
requirements from each of these three perspectives. requirements from each of these three perspectives.
It is worth noting that there are two additional sorts of participants It is worth noting that there are two additional sorts of participants
in the whole naming process, as discussed in the URN WG. They are the in the whole naming process, as discussed in the URN WG. They are the
naming authorities which choose and assign names, and the authors who naming authorities which choose and assign names, and the authors who
include URNs in their resources. These two are not relevant to the include URNs in their resources. These two are not relevant to the
design of a UDS and hence are not discussed further here. design of an RDS and hence are not discussed further here.
3.2.1 The Publisher 3.2.1 The Publisher
The publisher must be able to make URNs known to potential customers. The publisher must be able to make URNs known to potential customers.
From the perspective of a publisher, it is of primary importance that From the perspective of a publisher, it is of primary importance that
URNs be correctly and efficiently resolvable by potential clients. URNs be correctly and efficiently resolvable by potential clients with
Publishers also stand to gain from long-lived URNs, since they increase very high probability. Publishers also stand to gain from long-lived
the chance that references continue to point to their published URNs, since they increase the chance that references continue to point
resources. The publisher must also be able to choose easily among a to their published resources.
variety of potential services that might translate URNs to location
information. In order to allow for this mobility among resolution The publisher must also be able to choose easily among a variety of
services, the architecture for resolution services specified within the potential services that might translate URNs to location information.
IETF should not result in a scenario in which changing from one In order to allow for this mobility among resolver services, the
resolution service to another is an expensive operation. architecture for resolver services specified within the IETF should
not result in a scenario in which changing from one resolver service
to another is an expensive operation.
The publisher should be able to arrange for multiple access points to a The publisher should be able to arrange for multiple access points to a
published resource. For this to be useful, resolution services should published resource. For this to be useful, resolver services should
be prepared to provide different resolution or hint information to be prepared to provide different resolution or hint information to
different clients, based on a variety of information including location different clients, based on a variety of information including location
and the various access privileges the client might have. For example, and the various access privileges the client might have. For example,
companies might arrange for locally replicated copies of popular companies might arrange for locally replicated copies of popular
URN Resolution Requirements Page 8
resources, and would like to provide access to the local copies only for resources, and would like to provide access to the local copies only for
their own employees. This is distinct from access control on the their own employees. This is distinct from access control on the
resource as a whole, and may be applied differently to different copies. resource as a whole, and may be applied differently to different copies.
The publisher should be able to provide both long and short term The publisher should be able to provide both long and short term
information about accessing the resource. Long term information is location information about accessing the resource. Long term
likely to be such information as the long term location of the resource information is likely to be such information as the long term or the
or the location or identity of a resolution service with which the location or identity of a resolver service with which the publisher
publisher has a long term relationship. One can imagine that the has a long term relationship. One can imagine that the arrangement
arrangement with such a long term "authoritative" resolution service with such a long term "authoritative" resolver service might be a
might be a guarantee of reliability, resiliency to failure, and atomic guarantee of reliability, resiliency to failure, and atomic updates.
updates. Shorter term information is useful for short term changes in Shorter term information is useful for short term changes in services
services or to avoid short lived congestion or failure problems. For or to avoid short lived congestion or failure problems. For example,
example, if the actual repository of the resource is temporarily if the actual repository of the resource is temporarily inaccessible,
inaccessible, the resource might be made available from another the resource might be made available from another repository. This
repository. This short term information can be viewed as temporary short term information can be viewed as temporary refinements of the
refinements of the longer term information, and as such should be more longer term information, and as such should be more easily and quickly
easily and quickly made available, but may be less reliable. made available, but may be less reliable.
Lastly, the publishers will be the source of much hint information that Lastly, the publishers will be the source of much hint information that
will be stored and served by the manager of the infrastructure. Despite will be stored and served by the manager of the infrastructure. Despite
the fact that many publishers will not understand the details of the UDS the fact that many publishers will not understand the details of the RDS
mechanism, it must be easy and straightforward to install hint mechanism, it must be easy and straightforward to install hint
- 9 -
information. The publisher must be able not only to express hints, but information. The publisher must be able not only to express hints, but
also to verify that what is being served by the manager is correct. also to verify that what is being served by the manager is correct.
Furthermore, to the extent that there are security constraints on hint Furthermore, to the extent that there are security constraints on hint
information, the publisher must be able to both express them and verify information, the publisher must be able to both express them and verify
compliance to them easily. compliance with them easily.
3.2.2 The Client 3.2.2 The Client
From the perspective of the client, simplicity and usability are From the perspective of the client, simplicity and usability are
paramount. Of critical importance to serving clients effectively is paramount. Of critical importance to serving clients effectively is
that there be an efficient protocol through which the client can acquire that there be an efficient protocol through which the client can acquire
hint information. Since resolving the name is only the first step on hint information. Since resolving the name is only the first step on
the way to getting access to a resource, the amount of time spent on it the way to getting access to a resource, the amount of time spent on it
must be minimized. must be minimized.
Furthermore, it will be important to be able to build simple, standard Furthermore, it will be important to be able to build simple, standard
interfaces to the UDS so that both the client and applications on the interfaces to the RDS so that both the client and applications on the
client's behalf can interpret hints and subsequently make informed client's behalf can interpret hints and subsequently make informed
choices. The client, perhaps with the assistance of the application, choices. The client, perhaps with the assistance of the application,
must be able to specify preferences and priorities and then apply them. must be able to specify preferences and priorities and then apply them.
If the ordering of hints is only partial, the client may become directly If the ordering of hints is only partial, the client may become directly
involved in the choice and interpretation of them and hence they must be involved in the choice and interpretation of them and hence they must be
understandable to that client. On the other hand, in general it should understandable to that client. On the other hand, in general it should
be possible to configure default preferences, with individual be possible to configure default preferences, with individual
preferences viewed as overriding any defaults. preferences viewed as overriding any defaults.
From the client's perspective, although URNs will provide important From the client's perspective, although URNs will provide important
functionality, the client is most likely to interact directly only with functionality, the client is most likely to interact directly only with
human friendly names (HFNs). As in direct human interaction (not human friendly names (HFNs). As in direct human interaction (not
computer mediated), the sharing of names will be on a small,private, or computer mediated), the sharing of names will be on a small,private, or
domain specific scale. HFNs will be the sorts of references and names domain specific scale. HFNs will be the sorts of references and names
that are easy to remember, type, choose among, assign, etc. There will that are easy to remember, type, choose among, assign, etc. There will
URN Resolution Requirements Page 9
also need to be a number of mechanisms for mapping HFNs to URNs. Such also need to be a number of mechanisms for mapping HFNs to URNs. Such
services as "yellow pages" or "search tools" fall into this category. services as "yellow pages" or "search tools" fall into this category.
Although we are mentioning HFNs here, it is important to recognize that Although we are mentioning HFNs here, it is important to recognize that
HFNs and the mappings from HFNs to URNs is and must remain a separate HFNs and the mappings from HFNs to URNs is and must remain a separate
functionality from a UDS. Hence, although HFNs will be critical to functionality from an RDS. Hence, although HFNs will be critical to
clients, they do not fall into the domain of this document. clients, they do not fall into the domain of this document.
3.2.3 The Management 3.2.3 The Management
Finally, we must address the usability concerns with respect to the Finally, we must address the usability concerns with respect to the
management of the hint infrastructure itself. What we are terming management of the hint infrastructure itself. What we are terming
"management" is a service that is distinct from publishing; it is the "management" is a service that is distinct from publishing; it is the
core of a UDS. It involves the storage and provision of hints to the core of an RDS. It involves the storage and provision of hints to the
clients, so that they can find published resources. It also provides clients, so that they can find published resources. It also provides
security to the extent that there is a commitment for provision of such security to the extent that there is a commitment for provision of such
security; this is addressed below. security; this is addressed below.
The management of hints must be as unobtrusive as possible. First, its The management of hints must be as unobtrusive as possible. First, its
infrastructure (hint storage servers and distribution protocols) should infrastructure (hint storage servers and distribution protocols) should
have as little impact as possible on other network activities. It must have as little impact as possible on other network activities. It must
be remembered that this is an auxiliary activity and must remain in the be remembered that this is an auxiliary activity and must remain in the
background. background.
Second, in order to make hint management feasible, there will need to be - 10 -
a system for economic incentives and disincentives. Recovering the cost
of running the system is only one reason for levying charges. The Second, in order to make hint management feasible, there may need to
introduction of payments often has a beneficial impact on social be a system for administrative incentives and disincentives such as
behavior. It may be necessary to discourage certain forms of behavior pricing or legal restrictions. Recovering the cost of running the
that when out of control have serious negative impact on the whole system is only one reason for levying charges. The introduction of
community. At the same time, payment policies should encourage behavior payments often has a beneficial impact on social behavior. It may be
that benefits the community as a whole. Thus, for example, a small necessary to discourage certain forms of behavior that when out of
control have serious negative impact on the whole community. At the
same time, any administrative policies should encourage behavior that
benefits the community as a whole. Thus, for example, a small
one-time charge for authoritatively storing a hint will encourage one-time charge for authoritatively storing a hint will encourage
conservative use of hints. If we assume that there is a fixed cost for conservative use of hints. If we assume that there is a fixed cost
managing a hint, then the broader its applicability across the URN for managing a hint, then the broader its applicability across the URN
space, the more cost effective it is. That is, when one hint can serve space, the more cost effective it is. That is, when one hint can
for a whole collection of URNs, there will be an incentive to submit one serve for a whole collection of URNs, there will be an incentive to
general hint over a large number of more specific hints. Similar submit one general hint over a large number of more specific hints.
policies can be instituted to discourage the frequent changing of hints. Similar policies can be instituted to discourage the frequent changing
In these ways and others, cost effective behavior can be encouraged. of hints. In these ways and others, behavior benefitting the
community as a whole can be encouraged.
Lastly, symmetric to issues of usability for publishers, it must also be Lastly, symmetric to issues of usability for publishers, it must also
simple for the management to configure the mapping of URNs to hints. It be simple for the management to configure the mapping of URNs to
must be easy both to understand the configuration and to verify that hints. It must be easy both to understand the configuration and to
configuration is correct. With respect to management, this requirement verify that configuration is correct. With respect to management,
may have an impact not only on the information itself but also on how it this requirement may have an impact not only on the information itself
is partitioned among network servers that collaboratively provide the but also on how it is partitioned among network servers that
management service or UDS. For example, it should be straightforward to collaboratively provide the management service or RDS. For example,
bring up a server and verify that the data it is managing is correct. it should be straightforward to bring up a server and verify that the
Since we are discussing a global and probably growing service, data it is managing is correct. Although this is not a requirement,
encouraging volunteer participants requires that, as with the DNS, such it is worth nothing that since we are discussing a global and probably
volunteers can feel confident about the service they are providing and growing service, encouraging volunteer participants suggests that, as
its benefit to both themselves and the rest of the community. with the DNS, such volunteers can feel confident about the service
they are providing and its benefit to both themselves and the rest of
the community.
To summarize, the usability requirements fall into three areas based on 3.3 Security and Privacy Requirements
participation in hint management and discovery:
* The publisher SUMMARY: Security and privacy requirements can be identified as some
a) URN to hint resolution must be correct and efficient; degree of protection from threats. These requirements are all stated
b) Publishers must be able to select among URN resolution in terms of possibilities or options for users of the service to
services to locate their resources; require and utilize. Hence they are requirements for the availability
c) Publishers must be able to arrange for multiple access points of functionality, but not for the use of it. We recognize that all
for their location information; security is a matter of degree and compromise. These may not satisfy
d) Publishers must be able to provide for both long-lived and all potential customers, and there is no intention here to prevent
short-lived hints; them from building more secure servers with more secure protocols to
e) It must be relatively easy for publishers to install and suit their needs. These are intended to satisfy the needs of the
observer their hint information and any security constraints general public.
they need for their hints.
* The client
a) The interface to the UDS must be simple, effective, and
efficient;
b) The client and client applications must be able to understand
the information stored in and provided by the UDS, in order
to be able to make informed choices.
* The management
a) The management of hints must be as unobtrusive as possible,
avoiding using too many network resources;
b) A pricing scheme may be necessary to provide not only cost
recovery, but also social incentives and disincentives to
encourage certain sorts of behavior deemed necessary to meet
other requirements;
c) The configuration and verification of configuration of
individual UDS servers must be simple enough not to
discourage configuration and verification.
3.3 Security and Privacy Requirements [R14] It must be possible to create authoritative versions of a hint
with access-to-modification privileges controlled;
[R15] It must be possible to determine the identity of servers or avoid
contact with unauthenticated servers;
[R16] It must be possible to reduce the threat of denial of service
by broad distribution of information across servers.
Although much of the information we are discussing in this document - 11 -
might be considered "meta-information", there are some important [R17] It must be possible within the bounds of organization policy
security and privacy concerns that must be addressed by a service criteria to provide at least some degree of privacy for
supporting that information. By first considering the sorts of attacks traffic.
that are of concern, we can then focus on the security and privacy [R18] It must be possible for publishers to keep private certain
issues that are important. The reader will notice that integrity plays information such as an overall picture of the resources they are
less of a role here than might be expected. To the extent that servers publishing and the identity of their clients;
provide access control, the information they manage will have certain [R19] It must be possible for publishers to be able to restrict
integrity guarantees. Beyond that we must recognize that we are dealing access to the resolution of the URNs for the resources they
merely with hint information about the location of possibly interesting publish, if they wish.
resources. Therefore we believe that the benefit of providing integrity
guarantees beyond those provided by the servers themselves does not
outweigh the cost.
Because the majority of the activity will be the distribution of hint When one discusses security, one of the primary issues is an
information, the threats of concern are those affecting the maintenance enumeration of the threats being considered for mitigation. The
of correct information to distribute and the availability of the sources tradeoffs often include cost in money and computational and
of information. The first approach to URN resolution is to discover communications resources, ease of use, likelihood of use, and
local hints. By being local, they will be as widely distributed as effectiveness of the mechanisms proposed. With this in mind, let us
possible. The drawback of such wide distribution is the inability to consider a set of threats.
update them; therefore, they will become out of date with time. An
alternative or backup mechanism would concentrate hint information in A good place to begin is with the early work of Voydock and Kent
[VK83]. They identify unauthorized release of information as a
passive attack, and all three of unauthorized modification of
information, denial of service, and spurious association initiation as
active attacks. An intruder at any protocol layer can attack at any
of the links or computational elements (hosts, routers, etc.) at that
layer. Attacks at one layer can be achieved by subverting or
attacking the lower layers. An unauthorized release of information is
a violation of privacy or confidentiality. This may be achieved by a
release of the information itself. Additional passive threats are
from secondary information through traffic analysis or other
violations of transmission security, such as noticing lengths and/or
sources and destinations of traffic. Moving to the active threats,
unauthorized modification of information can be partitioned into
problems with authenticity, integrity and ordering. Denial of service
may take the form of discarding information before it reaches its
destination or some degree of delay in delivering information.
Finally, spurious association may occur when a previous legitimate
association initiation is played back or an initiation is made under
false identity. Security measures may take the form of either
detection or prevention of each of these threats. Within the scope of
this work, we must identify those threats that are both of concern and
that we expect to be able to mediate. Of these threats the prevention
of passive attacks is known to be a particularly difficult problem to
address in the general case.
Of these threats, the passive threats to privacy or confidentiality
and the active threats of authenticity and integrity are probably the
most important to consider here. To the extent that spurious
association causes threats to the privacy, authenticity, or integrity
with respect to information within servers managing data, it is also
important. Because updates to hint information are idempotent, at
least with short periods of time, we will set aside the problems of
ordering for this analysis. Denial of service is probably the most
difficult of these areas of threats both to detect and to prevent, and
we will therefore set it aside for the present as well, although it
will be seen that solutions to other problems will also mitigate some
of the problems of denial of service. Furthermore, because this is
- 12 -
intended to be provide a global service to meet the needs of a variety
of communities, the engineering tradeoffs will be different for
different clients. Hence the requirements are stated in terms of,
"It must be possible..." It is important to note that the
information of concern here is hint information, which by nature is
not guaranteed to be correct or up-to-date; therefore, it is unlikely
to be worth putting too much expense into the correctness of hints,
because there is no guarantee that they are still correct anyway. But
the exact choice of degree of privacy, authenticity, and integrity
must be determined by the needs of the client and the availability of
services from the server.
There is one further issue to address at this point, the distinction
between mechanism and policy. In general, a policy is realized by
means of a set of mechanisms. In the case of an RDS there may be
policies internal to the RDS that it needs to have supported in order
to do its business as it sees fit. Since, in general it is in the
business of storing and distributing information, most of its security
policies may have to do with maintaining its own integrity, and are
rather limited. Beyond that, to the degree possible, it should impose
no policy on its customers, the publishers and users. It is they that
may have policies that they would like supported by the RDS. To that
end, an RDS should provide a spectrum of "tools" or mechanisms that
the customers can cause to be deployed on their behalf to realize
policies. An RDS may not provide all that is needed by a customer. A
customer may have different requirements within his or her
administrative bounds than outside. Thus, "it must be possible..."
captures the idea that the RDS must generally provide the tools to
implement policies as needed by the customers.
The first approach to URN resolution is to discover local hints. In
order for hints to be discovered locally, they will be as widely
distributed to what is considered to be local for every locale. The
drawback of such wide distribution is the wide distribution of
updates, causing network traffic problems or delays in delivering
updates. An alternative model would concentrate hint information in
servers, thus requiring that update information only be distributed to servers, thus requiring that update information only be distributed to
these servers. Hence the vulnerable points are the sources of the these servers. In such a model the vulnerable points are the sources
information and the distribution network among them. If one assumes of the information and the distribution network among them. Attackers
that there will be principals of some sort that are responsible for the on the integrity of the information stored in a server may come in the
information about each URN entry in the URN resolution service, then one form of other a fake owner of the information or a fake server to the
major threat is an attacker that masquerades as a valid principal and extent that servers exchange updates with each other. Wide
inserts incorrect information into the service. A second threat vector replication of information among servers increases the difficult of
results from the fact that the service itself will be implemented by a masquerading at all the locations of the information as well as
set of servers that collaborate and share the hint information critical reducing the threat of denial service. These lead us to three
to their activities. By masquerading as a valid server in this pool, an identifiable goals for our security model:
attacker can both provide incorrect information to clients and provide
incorrect information to other servers, which those servers will then
distribute. A third threat is that if the resolution service is too
centralized, service can be denied by a variety of network attacks
ranging from flooding the service with queries to causing various
network problems that will reduce access to the service. The more
centralized a service is the more vulnerable is the community that
trusts it not to be compromised. We can turn each of these into a
security goal.
* ACCESS CONTROL ON HINTS: There needs to be an authoritative version of * ACCESS CONTROL ON HINTS: It must be possible to create an
each hint, and it must support change control limited only to those authoritative version of each hint with change control limited only
principals with the right to modify it. The choice of who those to those principals with the right to modify it. The choice of who
principals are or whether they are unlimited must be made by the those principals are or whether they are unlimited must be made by
publisher of a hint. the publisher of a hint.
- 13 -
* SERVER AUTHENTICITY: Servers and clients must be able to learn the * SERVER AUTHENTICITY: Servers and clients must be able to learn the
identity of the servers with which they communicate. This will be a identity of the servers with which they communicate. This will be a
matter of degree and it is possible that there will be more matter of degree and it is possible that there will be more
trustworthy, but less accessible servers, supported by a larger trustworthy, but less accessible servers, supported by a larger
cluster of less authenticatable servers that are more widely cluster of less authenticatable servers that are more widely
available. In the worst case, if the client receives what appears to available. In the worst case, if the client receives what appears to
be invalid information, the client should assume that the hint may be be unvalidated information, the client should assume that the hint
inaccurate and confirmation of the data should be sought from more may be inaccurate and confirmation of the data might be sought from
reliable but less accessible data. more reliable but less accessible data.
* SERVER DISTRIBUTION: Broad availability will provide resistance to * SERVER DISTRIBUTION: Broad availability will provide resistance to
denial of service. It is only to the extent that the services are denial of service. It is only to the extent that the services are
available that they provide any degree of trustworthiness. In available that they provide any degree of trustworthiness. In
addition, the distribution of services will reduce to vulnerability addition, the distribution of services will reduce vulnerability
of the whole community, by reducing the trust put in any single of the whole community, by reducing the trust put in any single
server. This must be mitigated by the fact that to the extent trust server. This must be mitigated by the fact that to the extent trust
is based on a linked set of servers, if any one fails, the whole is based on a linked set of servers, if any one fails, the whole
chain of trust fails; the more elements there are in such a chain, chain of trust fails; the more elements there are in such a chain,
the more vulnerable it may become. the more vulnerable it may become.
_Ensuring_ privacy for clients and publishers is in some respects Privacy is a more difficult problem to address. It may be a
essentially impossible. Fortunately, assuring a reasonable degree of double-edged sword; for example, an organization may consider it
privacy for those who want it is possible. The privacy of clients is critically important that its competitors not be able to read its
primarily threatened by packet sniffers and servers that log requests. traffic, while it may also consider it important to be able to monitor
A server or a packet sniffer can without much difficulty record the exactly what its employees are transmitting to and from whom, for a
contents of queries as they pass by and compile the information into a variety of reasons such as reducing the probability that its employees
relation between URNs and clients. This can be combatted by anonymizing are giving or selling the company's secrets to verifying that
queries through a trusted, fairly local gateway, although it involves an employees are not using company resources for private endeavor. Thus,
although there are likely to be needs for privacy and confidentiality,
extra step and another potential bottleneck. The additional step can be what they are, who controls them and how, and by what mechanisms vary
mitigated by caching responses in the gateway, thus often avoiding the widely enough that it is difficult to say anything concrete about them
need to forward requests beyond it. A second alternative is to send here.
only partial queries. As will be discussed further in the framework
section, there may be two reasons for transformation of a URN, first to
canonicalize it and second to extract the identity of another server to
which to send a further request. This second alternative of sending
partial queries would be achieved by also extracting some partial URN to
further resolve at each stage. This would not anonymize the queries,
but might make them more difficult to chain together into a complete
story for logging.
On the other hand, to the degree that the search process is distributed,
packet sniffing at a single point is less likely to reveal data about a
specific person, and is hence less threatening to privacy. Furthermore,
if clients have flexibility in terms of the specific services they
choose to use, they can regularly switch services in the hopes of
foiling a packet sniffer watching their usual access point.
The privacy of publishers is much easier to safeguard. Since they are The privacy of publishers is much easier to safeguard. Since they are
trying to publish something, in some situations privacy is probably not trying to publish something, in general privacy is probably not
desired. However, publishers do have information that they might like desired. However, publishers do have information that they might like
to keep private: information about who their clients are, and to keep private: information about who their clients are, and
information about what names exist in their namespace. The information information about what names exist in their namespace. The
about who their clients are may be difficult to collect depending on the information about who their clients are may be difficult to collect
implementation of the resolution system. For example, if the resolution depending on the implementation of the resolution system. For
information relating to a given publisher is widely replicated, the hits example, if the resolution information relating to a given publisher
to _each_ replicated copy will need to be recorded. Of course, is widely replicated, the hits to _each_ replicated copy will need to
determining if a specific client is requesting a given name can be be recorded. Of course, determining if a specific client is
approached from the other direction, by watching the client as we saw requesting a given name can be approached from the other direction, by
above. watching the client as we saw above.
The other privacy issue for publishers has to do with access control The other privacy issue for publishers has to do with access control
over URN resolution. This issue is dependent on the implementation of over URN resolution. This issue is dependent on the implementation of
the publisher's authoritative URN resolution server. URN resolution the publisher's authoritative URN resolver server. URN resolver
servers can be designed to require proof of identity in order to be servers can be designed to require proof of identity in order to be
issued resolution information; if the client does not have permission to issued resolution information; if the client does not have permission
access the URN requested, the service denies that such a URN exists. An to access the URN requested, the service denies that such a URN
encrypted protocol can also be used so that both the request and the exists. An encrypted protocol can also be used so that both the
response are obscured. Encryption is possible in this case because the request and the response are obscured. Encryption is possible in this
identity of the final recipient is known (i.e. the URN server).
In summary, security and privacy requirements can be identified as some - 14 -
degree of protection from threats:
* It must be possible to create authoritative versions of a hint case because the identity of the final recipient is known (i.e. the
with access to modification privileges controlled; URN server).
* It must be possible to determine the identity of servers or avoid
contact with unauthenticated servers;
* Broad availability of servers will reduce the thread to denial
of service;
* Client privacy is threatened by packet sniffing and server
logging. It is desirable to reduce these threats as much as
possible;
* It should be feasible for publishers to keep private certain
information such as an overall picture of the resources they are
publishing and the identity of their clients;
* Publishers should be able to restrict access to the resolution of
the URNs for the resources they publish, if they wish.
4. The Framework 4. The Framework
With these assumptions and requirements in mind, one can conclude with a With these assumptions and requirements in mind, one can conclude with a
general framework within which UDS designs will fall. As stated general framework within which RDS designs will fall. As stated
earlier, although this framework is put forth as a suggested guide for earlier, although this framework is put forth as a suggested guide for
UDS designers, compliance with it will in no way guarantee compliance RDS designers, compliance with it will in no way guarantee compliance
with the requirements. Such an evaluation must be performed separately. with the requirements. Such an evaluation must be performed separately.
It is also understood that there may be UDS services that do not meet It is also understood that there may be RDS services that do not meet
the requirements in clearly identified ways. This may be true the requirements in clearly identified ways. This may be true
especially with early plans and experiments. For example, although a especially with early plans and experiments. For example, although a
careful threat analysis may have been done to understand security careful threat analysis may have been done to understand security
requirements, not all those security requirements may be addressed, in requirements, not all those security requirements may be addressed, in
order to use existing facilities to allow for early deployment for order to use existing facilities to allow for early deployment for
experimentation purposes. All such lack of compliance should be clearly experimentation purposes. All such lack of compliance should be clearly
documented. documented.
The design of the framework is based on a simple assumption about the The design of the framework is based on a simple assumption about the
syntax of a URN. This assumed syntax is: syntax of a URN a documented in RFC-XXX[RFCXXX}. This assumed syntax
is:
URN:<NID>:<NSS> URN:<NID>:<NSS>
where URN: is a prefix on all URNs, NID is the namespace identifier, and where URN: is a prefix on all URNs, NID is the namespace identifier,
NSS is the namespace specific string. The prefix identifies each URN as and NSS is the namespace specific string. The prefix identifies each
such. The NID determines the general syntax for all URNs within its URN as such. The NID determines the general syntax for all URNs
namespace. The NSS is probably partitioned into a set of delegated and within its namespace. The NSS is probably partitioned into a set of
subdelegated namespaces, and this is probably reflected in further delegated and subdelegated namespaces, and this is probably reflected
syntax specifications. In the more complex environments, each delegated in further syntax specifications. In more complex environments, each
namespace will be permitted to choose the syntax of the variable part of delegated namespace will be permitted to choose the syntax of the
the namespace that has been delegated to it. In simpler namespaces, the variable part of the namespace that has been delegated to it. In
syntax will be restricted completely by the parent namespace. For simpler namespaces, the syntax will be restricted completely by the
example, although the DNS does not meet all the requirements for URNs, parent namespace. For example, although the DNS does not meet all the
it has a completely restricted syntax, such that any further structuring requirements for URNs, it has a completely restricted syntax, such
must be done only by adding further refinements to the left, maintaining that any further structuring must be done only by adding further
the high order to low order, right to left structure. A delegated refinements to the left, maintaining the high order to low order,
syntax might be one in which a host is named by the DNS, but to the right to left structure. A delegated syntax might be one in which a
right of that and separated by an "@" is a string whose internal host is named by the DNS, but to the right of that and separated by an
ordering is defined by the file system on the host, which may be defined "@" is a string whose internal ordering is defined by the file system
high order to low order, left to right. Of course, much more complex on the host, which may be defined high order to low order, left to
and nested syntaxes should be possible, especially given the need to right. Of course, much more complex and nested syntaxes should be
grandfather namespaces. In order to resolve URNs, rules will be needed possible, especially given the need to grandfather namespaces. In
for two reasons. One is simply to canonicalize those namespaces that do order to resolve URNs, rules will be needed for two reasons. One is
not fall into a straightforward (probably right to left or left to simply to canonicalize those namespaces that do not fall into a
right) ordering of the components of a URN, as determined by the straightforward (probably right to left or left to right) ordering of
delegated naming authorities involved. It is also possible that rules the components of a URN, as determined by the delegated naming
will be needed in order to derive from URNs the names of UDS servers to authorities involved. It is also possible that rules will be needed
be used in stages. in order to derive from URNs the names of RDS servers to be used in
stages.
The NID defines a top level syntax. This syntax will determine whether The NID defines a top level syntax. This syntax will determine
the NID alone or in conjunction with some extraction from the NSS (for whether the NID alone or in conjunction with some extraction from the
the top level naming authority name) to identify the first level server NSS (for the top level naming authority name) is to be used to
to be contacted. Each stage of the lookup either a new rule for - 15 -
generating the strings used in yet another lookup (the strings being the
identify of another UDS server and possibly a string to be resolved if identify the first level server to be contacted. At each stage of the
it is different than the original URN) or a reference outside the UDS to lookup either a new rule for generating the strings used in yet
a private URN resolution service, sidestepping any furthere use of the another lookup (the strings being the identity of another RDS server
UDS scheme. Figure 1 depicts this process. and possibly a string to be resolved if it is different than the
original URN) or a reference outside the RDS to a private URN
resolver service, sidestepping any further use of the RDS scheme.
Figure 1 depicts this process.
URN:<NID><NSS> URN:<NID><NSS>
| |
| |
| |
| |
v v
+-------------------+ +-------------------+
|Global NID registry| |Global NID registry|
+-------------------+ +-------------------+
| |
| |
| |
(return rule or URN resolution service reference) (return rule or URN resolver service reference)
| |
+----------------------------------+ +----------------------------------+
| | | |
+->(apply rule to determine UDS server) | +->(apply rule to determine RDS server) |
| | | | | |
| | | | | |
| | | | | |
| +----------+ | | +----------+ |
| |UDS server| +-----------------+ | |RDS server| +-----------------+
| +----------+ | | +----------+ |
| | | v | | | v
| | | (set of choices) | | | (set of choices)
| | +----+----------(...)--------+ | | +----+----------(...)--------+
| (rule) | | | (rule) | |
| | | | | | | |
| | | | | | | |
+------+ | | +------+ | |
v v v v
+----------+ +----------+ +----------+ +----------+
|private | |private | |private | |private |
|URN | |URN | |URN | |URN |
|resolution| |resolution| |resolver | |resolver |
|service | |service | |service | |service |
+----------+ +----------+ +----------+ +----------+
Figure 1: A UDS framework Figure 1: An RDS framework
There are several points worth noting about the UDS framework. First, There are several points worth noting about the RDS framework. First,
it leaves open the determination of the protocols and data organization, it leaves open the determination of the protocols, data organization,
distribution and replication needed to support a particular UDS scheme. distribution and replication needed to support a particular RDS
Second, it leaves open the location of the computations engendered by
the rules. Third, it leaves open the possibility that partitioning - 16 -
(distribution) of the UDS database need not be on the same boundaries as
the name delegation. This may seem radical to some, but if the scheme. Second, it leaves open the location of the computations
information is stored in balanced B-trees for example, the partitioning engendered by the rules. Third, it leaves open the possibility that
may not be along those naming authority delegation boundaries. Lastly, partitioning (distribution) of the RDS database need not be on the
it leaves open access to the Global NID Registry. Is this distributed same boundaries as the name delegation. This may seem radical to
to every client, or managed in widely distributed servers? One concept some, but if the information is stored in balanced B-trees for
that has not been addressed in Figure 1 is that there may be more than example, the partitioning may not be along those naming authority
one UDS available at any given time, in order to allow for evolution to delegation boundaries. Lastly, it leaves open access to the Global
new schemes. Thus, the picture should probably look more like Figure 2. NID Registry. Is this distributed to every client, or managed in
widely distributed servers?
One concept that has not been addressed in Figure 1 is that there may
be more than one RDS available at any given time, in order to allow
for evolution to new schemes. Thus, the picture should probably look
more like Figure 2.
URN:<NID>:<NSS> URN:<NID>:<NSS>
| |
| |
+-----------+-------(...)-------+ +-----------+-------(...)-------+
| | | |
| | | |
| | | |
v v v v
+---------------------+ +---------------------+ +---------------------+ +---------------------+
|Global NID registry 1| |Global NID registry N| |Global NID registry 1| |Global NID registry N|
+---------------------+ +---------------------+ +---------------------+ +---------------------+
. . . .
. . . .
. . . .
Figure 2: More than one co-existing UDS scheme Figure 2: More than one co-existing RDS scheme
If we are to support more than one co-existing UDS scheme, there will If we are to support more than one co-existing RDS scheme, there will
need to be coordination between them with respect to storage and need to be coordination between them with respect to storage and
propagation of information and modifications. The issue is that propagation of information and modifications. The issue is that
generally it should be assumed that all information should be available generally it should be assumed that all information should be available
through any operational UDS scheme. One cannot expect potential through any operational RDS scheme. One cannot expect potential
publishers to submit updates to N UDS schemes. Hence there will need to publishers to submit updates to N RDS schemes. Hence there will need to
be a straightforward mapping of information from one to the other of be a straightforward mapping of information from one to the other of
these schemes. It is possible that that transformation will only go in these schemes. It is possible that that transformation will only go in
one direction, because a newer UDS service is replacing an older one, one direction, because a newer RDS service is replacing an older one,
which is not kept up to date, in order to encourage transfer to the which is not kept up to date, in order to encourage transfer to the
newer one. Thus, at some point, updates may be made only to the newer newer one. Thus, at some point, updates may be made only to the newer
one and not be made available to the older one. Such a situation should one and not be made available to the older one. Such a situation should
probably be avoided, if possible. probably be avoided, if possible.
This framework is presented in order to suggest to UDS scheme designers This framework is presented in order to suggest to RDS scheme
a direction in which to start designing. It is obvious to the reader designers a direction in which to start designing. It should be
that adherence to this framework will in no way guarantee compliance obvious to the reader that adherence to this framework will in no way
with the requirements or even assumption described in Sections 2 and 3. guarantee compliance with the requirements or even assumption
These must be reviewed independently as part of the design process. described in Sections 2 and 3. These must be reviewed independently
There is no single correct design that will meet these requirements. as part of the design process. There is no single correct design that
Furthermore, it is assumed that preliminary proposals may not meet all
the requirements, but should be expected to itemized and justify any
lack of compliance.
5. References - 17 -
will meet these requirements. Furthermore, it is assumed that
preliminary proposals may not meet all the requirements, but should be
expected to itemized and justify any lack of compliance.
5. Acknowledgments
Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a previous URN requirements document and for his insightful
comments on this version of the document. In addition, I recognize the
contributors to a previous URN framework document, the "Knoxville"
group. There are too many of you to acknowledge here individually, but
thank you. Finally, I must thank the contributors to the URN working
group mailing list (urn-ietf@bunyip.com), for their animated discussions
on these and related topics.
6. References
[RFC1736] Kunze, J., "Functional Recommendations for Internet Resource [RFC1736] Kunze, J., "Functional Recommendations for Internet Resource
Locators", RFC 1736, February, 1995. Locators", RFC 1736, February, 1995.
[RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for [RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for
Uniform Resource Names", RFC 1738, December, 1994. Uniform Resource Names", RFC 1738, December, 1994.
[RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform
Resource Locators (URL)", RFC 1738, December, 1994. Resource Locators (URL)", RFC 1738, December, 1994.
6. Contact information: [RFCXXX] Moats, Ryan, "URN Syntax", currently available as
draft-ietf-urn-syntax-04.txt, March, 1997.
[VK83] 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.
7. Contact information:
Karen Sollins Karen Sollins
MIT Laboratory for Computer Science MIT Laboratory for Computer Science
545 Technology Sq. 545 Technology Sq.
Cambridge, MA 02139 Cambridge, MA 02139
Tel: +1 617 253 6006 Tel: +1 617 253 6006
Email: sollins@lcs.mit.edu Email: sollins@lcs.mit.edu
This InternetDraft expires on May 26, 1997. This Internet Draft expires on September 28, 1997.
- 18 -
 End of changes. 96 change blocks. 
498 lines changed or deleted 587 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/