draft-ietf-urn-req-frame-02.txt   draft-ietf-urn-req-frame-03.txt 
Internet Draft Karen R. Sollins Internet Draft Karen R. Sollins
draft-ietf-urn-req-frame-02.txt MIT/LCS draft-ietf-urn-req-frame-03.txt MIT/LCS
Expires December 4, 1997 June 4, 1997 Expires January 30, 1998 July 30, 1997
Guidelines and a Framework for URN Resolution Systems Architectural Principles of Uniform Resource Name Resolution
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
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
skipping to change at line 28 skipping to change at line 28
``work in progress.'' ``work in progress.''
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 URN resolver This document addresses the issues of the discovery of URN (Uniform
services that in turn will directly translate URNs into URLs and URCs. Resource Name) resolver services that in turn will directly translate
The document falls into three major parts, the assumptions underlying URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource
the work, the guidelines in order to be a viable Resolver Discovery Characteristics). The document falls into three major parts, the
Service or RDS to help in finding URN resolvers, and a framework for assumptions underlying the work, the guidelines in order to be a
designing RDSs. The guidelines fall into three major areas: viable Resolver Discovery Service or RDS, and a framework for
designing RDSs. The guidelines fall into three principle areas:
evolvability, usability, and security and privacy. An RDS that is evolvability, usability, and security and privacy. An RDS that is
compliant with the framework will not necessarily be compliant with the compliant with the framework will not necessarily be compliant with
guidelines. Compliance with the guidelines will need to be validated the guidelines. Compliance with the guidelines will need to be
separately. 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 Resolver Discovery Service (RDS), a service to for what we will call here a Resolver Discovery Service (RDS), a
help in the learning about URN resolvers. This is a component of the service to help in the learning about URN (Uniform Resource Name)
realization of an information infrastructure. In the case of this work, resolvers. The term "resolver" is used in this document to indicate a
that infrastructure is to be available, "in the Internet" or globally, service that translates URNs to URLs (Uniform Resource Locators) or
and hence the solutions to the problems we are addressing must globally URCs (Uniform Resource Characteristics). Some resolvers may provide
scalable. In this work, we are focussing specifically on naming of direct access to resources as well. An RDS helps in finding a
resources and resolution of those names to the exclusion of other resolver to contact for further resolution. It is worth noting that
problems such as typing, resource access and availability, security of some RDS designs may also incorporate resolver functionality. This
the resources, etc. Those are all important problems, but not part of function of URN resolution is a component of the realization of an
this effort. information infrastructure. In the case of this work, that
infrastructure is to be available, "in the Internet" or globally, and
The Uniform Resource Identifier Working Group defined a naming hence the solutions to the problems we are addressing must be globally
architecture, as demonstrated in a series of three RFCs 1736[RFC1736],
- 1 - - 1 -
1737{RFC1737}, and 1738[RFC1738]. Although several further documents scalable. In this document, we are focussing specifically on the
are needed to complete the description of that architecture, it design of RDS schemes.
incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics. By location, we
mean fully-qualified Domain Names or IP addresses. Names may provide
the ability to distinguish one resource from another, by distinguishing
their "names". Names may help to provide access to a resource by
including "location" information. Lastly, names may have other semantic
or mnemonic information that either helps human users remember or figure
out the names, or include other semantic information about the resource
being named. The URI working group concluded that there was need for
persistent, globally unique identifiers, distinct from location or other
semantic information; these "names" provide identity, in that if two of
them are "the same" (under some simple rule of canonicalization), they
identify the same resource. Furthermore, the group decided that these
"names" were generally to be for machine, rather than human,
consumption. One can imagine a variety human-friendly naming (HFN)
schemes supporting different suites of applications and user
communities. These will need to provide mappings to URNs in tighter or
looser couplings, depending on the namespace. It is these HFNs that
will be mnemonic, content-full, and perhaps mutable, to track changes in
use and semantics. They may provide nicknaming and other aliasing,
relative or short names, context sensitive names, descriptive names,
etc. The URI naming architecture as described in the introductions to
RFCs 1736 and 1737 lays out three sorts of components to the naming
architecture: identifiers called Uniform Resource Names (URNs), 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.
URNs as described in RFC 1737 are defined globally; they are ubiquitous The Uniform Resource Identifier Working Group defined a naming
in that a URN anywhere in any context identifies the same resource. architecture, as demonstrated in a series of three RFCs 1736[1],
With respect to an RDS we must ask what URN ubiquity implies for the RDS 1737[2], and 1738[3]. Although several further documents are needed
and for resolution in general. But in terms of Internet services and to complete the description of that architecture, it incorporates
accessibility, there can be no systematic guarantees. In addition, it three core functions often associated with "naming": identification,
is quite possible that the resolution of a URN to an instance of a location, and mnemonics or semantics. By location, we mean
resource may reach different instances or copies under different fully-qualified Domain Names or IP addresses, possibly extended with
conditions. Thus, although a URN anywhere refers to the same resource, TCP ports and/or local identifiers, such as pathnames. Names may
in some locations under some conditions, and at different times, due to provide the ability to distinguish one resource from another, by
either the vagueries of network conditions or policy controls a URN may distinguishing their "names". Names may help to provide access to a
resource by including "location" information. Lastly, names may have
other semantic or mnemonic information that either helps human users
remember or figure out the names, or include other semantic
information about the resource being named. The URI working group
concluded that there was need for persistent, globally unique
identifiers, distinct from location or other semantic information;
these were called URNs. These "names" provide identity, in that if
two of them are "the same" (under some simple rule of
canonicalization), they identify the same resource. Furthermore, the
group decided that these "names" were generally to be for machine,
rather than human, consumption.
In contrast to URNs, one can imagine a variety human-friendly naming
(HFN) schemes supporting different suites of applications and user
communities. These will need to provide mappings to URNs in tighter
or looser couplings, depending on the namespace. It is these HFNs
that will be mnemonic, content-full, and perhaps mutable, to track
changes in use and semantics. They may provide nicknaming and other
aliasing, relative or short names, context sensitive names,
descriptive names, etc. Their definition is not part of this effort,
but will clearly play an important role in the long run.
URNs as described in RFC 1737 are defined globally; they are
ubiquitous in that a URN anywhere in any context identifies the same
resource. Given this requirement on URNs, one must ask about its
implication for an RDS. Does ubiquity imply a guarantee of RDS
resolution everywhere? Does ubiquity imply resolution to the same
information about resolution everywhere? In both cases the answer is
probably not. One cannot make global, systemic guarantees, except at
an expense beyond reason. In addition there may be policy reasons for
not resolving in the same way everywhere. It is quite possible that
the resolution of a URN to an instance of a resource may reach
different instances or copies under different conditions. Thus,
although a URN anywhere refers to the same resource, in some
environments under some conditions, and at different times, due to
either the vagaries of network conditions or policy controls a URN may
sometimes be resolvable and other times or places not. Ubiquitous sometimes be resolvable and other times or places not. Ubiquitous
resolution cannot be assumed simply because naming is ubiquitous. On resolution cannot be assumed simply because naming is ubiquitous. On
the other hand wide deployment and usage will be an important feature of the other hand wide deployment and usage will be an important feature
any RDS design. of any RDS design.
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; we map URNs to hints as an
interim stage in accessing a resource. A hint may also have
meta-information associated with it, such as an expiration_time or
certification of authenticity. We expect that these will stay with a
hint rather than being managed elsewhere. We will assume in all further
discussion of hints that they include any necessary meta-information as
well as the hint information itself. Examples of hints are: 1) the name
of a resolver service that may further resolve the URN, 2) the address
of such a service, 3) a location at which the resource was previously
- 2 - - 2 -
found. The defining feature of hints is that they are only hints; they that helps in the resolution of a URN; in theory we map URNs to hints
may be out of date, temporarily invalid, or only applicable within a as an interim stage in accessing a resource. In practice, an RDS may
specific locality. They do not provide a guarantee of access, but they map a URN directly into the resource itself if it chooses to. It is
probably will help in the resolution process. We must assume that most very likely that there will be hints that are applicable to large sets
resolutions of URNs will be provided by the use of locally stored hints, of URNs, for example, a hint that indicates that all URNs with a
because maintaining a database of globally available, completely certain prefix or suffix can be resolved by a particular resolver. A
up-to-date location information is infeasible for performance reasons. hint may also have meta-information associated with it, such as an
There are a number of circumstances in which one can imagine that hints expiration_time or certification of authenticity. We expect that
become invalid, either because a resource has moved or because a these will stay with a hint rather than being managed elsewhere. We
different URN resolver service has taken over the responsibility for will assume in all further discussion of hints that they include any
resolution of the URN. Hints may be found in a variety of places. It necessary meta-information as well as the hint information itself.
is generally assumed that a well engineered system will maintain a set Examples of hints are: 1) the URN of a resolver service that may
of hints for each URN at each location where that URN is found. In further resolve the URN, 2) the address of such a service, 3) a
addition, for those situations in which those hints found locally fail, location at which the resource was previously found. The defining
a well-engineered system will provide a fall-back mechanism for feature of hints is that they are only hints; they may be out of date,
discovering further hints. It is this fall-back mechanism, an RDS, that temporarily invalid, or only applicable within a specific locality.
is being addressed in this document. As with all hints, there can never They do not provide a guarantee of access, but they probably will help
be a guarantee that access to a resource will be available to all in the resolution process. We must assume that most resolutions of
clients, even if the resource is accessible to some. However, an RDS is URNs will be provided by the use of locally stored hints, because
expected to work with reasonably high reliability, and, hence, may maintaining a database of globally available, completely up-to-date
result in increased response time. 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 or cache
a set of hints for each URN at each location where that URN is found.
These may have been acquired from the owner of the resources, a
recommendation of the resource, or one of many other sources. In
addition, for those situations in which those hints found locally
fail, a well engineered system will provide a fall-back mechanism for
discovering further hints. It is this fall-back mechanism, an RDS,
that is being addressed in this document. As with all hints, there
can never be a guarantee that access to a resource will be available
to all clients, even if the resource is accessible to some. However,
an RDS is expected to work with reasonably high reliability, and,
hence, may result in increased response time.
The remainder of this document falls into three sections. The first The remainder of this document falls into three sections. The first
identifies several sets of assumptions underlying this work. There are identifies several sets of assumptions underlying this work. There are
three general assumptions: three general assumptions:
* URNs are persistant; * URNs are persistent;
* URN assignment can be delegated; * URN assignment can be delegated;
* Decisions can be made independently, enabling isolation from decisions * Decisions can be made independently, enabling isolation from decisions
of one's peers. of one's peers.
The next section lays out the guidelines for a Resolver Discovery The next section lays out three central principles Resolver Discovery
Service. This section is probably the most critical of the document, Service design. For each of these, we have identified a number of
because it is this that provides the metric for whether or not a more specific guidelines that further define and refine the general
proposed scheme for a n RDS is adequate or not. To summarize, there are principle. This section is probably the most critical of the
three core rubrics, each of which is refined and subdivided below: document, because one must hold any proposed RDS scheme up against
R1) An RDS must allow for evolution and evolvability; these principles and corollary guidelines to learn whether or not it
R2) Usability of an RDS with regard to each of the sets of constituents is adequate. The three central principles can be summarized as:
1) An RDS must allow for evolution and evolvability;
2) Usability of an RDS with regard to each of the sets of constituents
involved in the identification and location or resources is paramount; involved in the identification and location or resources is paramount;
R3) It is centrally important that the security and privacy needs of all
consituents be feasibly supported, to the degree possible.
It is important to note that the origins of this document were as a
requirements document. Therefore it retains its flavor of a requirments
documents including the use of "must" and "should". The consensus of
the working group currently is that more experience is needed before it
can have the confidence necessary to be explicit about requirements for
RDSs. Hence the document is worded in terms of "guidelines" and
"rubrics", with the understanding that anyone any proposal for an RDS
design should still measure up to the statements in this document, based
on the accrued knowledge and experience of a group that has been working
in this area for a number of years. Any RDS proposal should document
how it addresses each of the rubrics. If it does not adequately address
any of them, it should document the reasoning behind it, so that the
community can learn from that experience, with the intention of defining
a set of requirements in the future.
- 3 - - 3 -
3) It is centrally important that the security and privacy needs of all
constituents be feasibly supported, to the degree possible.
Each of the three major subsections of the guidelines section begins
with a summary list of the more detailed guidelines identified in that
section.
For the reader short on time, each of the three major subsections of the The final section of the document lays out a framework for such RDSs.
guidelines section begins with a summary list of the more detailed The purpose of this last section is to bound the search space for RDS
guidelines identified in that section. The final section of the schemes. The RDS designer should be aware that meeting the guidelines
document lays out a framework for such RDSs. The purpose of this last is of primary importance; it is possible to meet them without
section is to bound the search space for RDS schemes. One must be conforming to the framework. As will be discussed further in this
careful not to assume that because an RDS scheme fits within the last section, designing within the framework does not guarantee
framework that it necessarily meets the guidelines. As will be compliance, so compliance evaluation must also be part of the process
discussed further in this last section, designing within the framework of evaluation of a scheme.
does not guarantee compliance, so compliance evaluation 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 guidelines state that a URN is to be a "persistent identifier". The URN requirements[2] state that a URN is to be a "persistent
It is probably the case that nothing will last forever, but in the time identifier". It is probably the case that nothing will last forever,
frame of resources, users of those resources, and the systems to support but in the time frame of resources, users of those resources, and the
the resources, the identifier should be considered to be persistent or systems to support the resources, the identifier should be considered
have a longer lifetime than those other entities. There are two to be persistent or have a longer lifetime than those other entities.
assumptions that are implied by longevity of URNs: mobility and There are two assumptions that are implied by longevity of URNs:
evolution. "Mobility" assumes that everything will move over the life mobility and evolution. Mobility will occur because resources may
of a URN. For example, resources will move from one machine to another, move from one machine to another, owners of resources may move among
because individual machines have a much shorter lifetime than resources, organizations, or the organizations themselves may merge, partition,
generally measured in a number of years less than a decade. Owners of or otherwise transforms themselves. The Internet is continually
resources may move and wish their resources to follow them. The evolving; protocols are being revised, new ones created, while
services themselves will move. "Evolution" assumes that the supporting security policies and mechanisms evolve as well. These are only
infrastructure will evolve. This may take the form of entirely new examples. In general, we must assume that almost any piece of the
transport protocols or new versions of existing protocols. Furthermore, supporting infrastructure of URN resolution will evolve. In order to
services such as storage services may evolve; it is even possible that deal with both the mobility and evolution assumptions that derive from
within a human lifetime the Unix file system model may no longer be in the assumption of longevity, we must assume that users and their
use! Clearly there will be evolution of and improvement in supporting
authentication and security mechanisms. These are only examples. In
general, we must assume that almost any piece of the supporting
infrastructure of URN resolution will evolve. In order to deal with
both the mobility and evolution assumptions that derive 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 assumption is that naming and resolution authorities may
and isolation. The delegation assumption is that an entity may delegate some of their authority or responsibility; in both cases, the
partition and pass off some of its authority or responsibility. One of delegation of such authority is the only known method of allowing for
those responsibilities is for assigning URNs; practically speaking, the kind of scaling expected. It is important to note that a
there cannot be only a single authority for assigning URNs. We expect significant feature of this work is the potential to separate name
that there will be a multi-tiered naming authority delegation. assignment, the job of labelling a resource with a URN, from name
Furthermore, it is difficult to imagine a non-partitioned and delegated resolution, the job of discovering the resource given the URN. In
global RDS, meaning that hint discovery and resolution will be both cases, we expect multi-tiered delegation. There may be RDS
partitioned and delegated. In some RDS schemes, the delegation of schemes that merge these two sets of responsibilities and delegation
naming authority will form a basis for delegating the management and relationships; by doing so, they bind together or overload two
dispensing of location information. distinctly different activities, thus probably impeding growth.
The third assumption is independence or isolation of one authority
from another and, at least to some extent, from its parent. When one
authority delegates some of its rights and responsibilities to another
- 4 - - 4 -
The third assumption is independence or isolation of one authority from authority, the delegatee can operate in that domain independently of
another and, at least to some extent from its parent. Underlying much its peers and within bounds specified by the delegation, independently
of the thinking and discussion in the URI and URN working groups has of the delegator. This isolation is critically important in order to
been the assumption that when a component delegates authority to another allow for independence of policy and mechanism.
component, the delegatee can operate in that domain independently of its
peers and within bounds specified by the delegation, independently of
the delegator. This isolation is critically important in order to allow
for independence of policy and mechanism.
There are a number of more specific assumptions that fall under this This third assumption has several corollaries. First, we assume that
rubric of isolation. First, we assume that the publisher of a resource the publisher of a resource can choose resolver services,
can choose resolver services, independently of choices made by others. independently of choices made by others. At any given time, the owner
At any given time, the owner of a namespace may choose a particular URN of a namespace may choose a particular URN resolver service for that
resolver service for that delegated namespace. Such a URN resolver delegated namespace. Such a URN resolver service may be outside the
service may be outside the RDS service model, and just identified or RDS service model, and only identified or located by the RDS service.
located by the RDS service. Second, it must be possible to make a Second, it must be possible to make a choice among RDS services. The
choice among RDS services, perhaps based on different underlying existence of multiple RDS services may arise from the evolution of an
internal architectures. The reason that this is an assumption is that RDS service, or development of new ones. Although at any given time
there must be an evolutionary path through a sequence of core RDS there is likely to be only one or a small set of such services, the
services. Although at any given time there is likely to be only one or number is likely to increase during a transition period from one
a small set of such services, the number is likely to increase during a architecture to another. Thus, it must be assumed that clients can
transition period from one architecture to another. Thus, it must be make a choice among a probably very small set of RDSs. Third, there
assumed that clients can make a choice among a probably very small set must be independence in the choice about levels and models of security
of RDSs. Third, there must be independence in the choice about levels and authenticity required. This choice may be made by the owner of a
and models of security and authenticity required. This choice may be naming subspace, in controlling who can modify hints in that subspace.
made by the owner of a naming subspace, in controlling who can modify A naming authority may delegate this choice to the owners of the
hints in that subspace. A naming authority may delegate this choice to resources named by the names it has assigned. There may be
the owners of the resources named by the names it has assigned. There 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 RDS 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
namespace, limited by any restrictions or constraints that may have been a namespace, limited by any restrictions or constraints that may have
set by its parent namespace. This is a choice held by naming been 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.
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
service. Based on these these assumptions in conjunction with that of of service. Based on these these assumptions in conjunction with that
longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, of longevity and those for URLs and URNs as detailed in RFCs 1736 and
we can now turn to the guidelines for a Resolver Discovery Service. 1737, we can now turn to the guidelines for an RDS.
3. Guidelines 3. Guidelines
The guidelines or rubrics applying to a Resolver Discovery Service or The guidelines applying to an RDS center around three important design
RDS center around three important design goals: evolvability, usability, principles in the areas of evolvability, usability, and security and
and security and privacy. At its core the function of an RDS is to privacy. At its core the function of an RDS is to provide hints for
provide hints for accessing a resource given a URN for it. These hints accessing a resource given a URN for it. These hints may range in
may range in applicability from local to global, and from short-lived to applicability from local to global, and from short-lived to
long-lived. They also may vary in their degree of verifiable long-lived. They also may vary in their degree of verifiable
authenticity. While it may be neither feasible nor necessary that authenticity. While it may be neither feasible nor necessary that
initial implementations support every guideline, every implementation
must support evolution to systems that do support the guideline more
fully.
- 5 - - 5 -
initial implementations support every guideline, every implementation
must support evolution to systems that do support every rubric.
It is important to note that there are requirements, not applicable It is important to note that there are requirements, not applicable
specifically to an RDS that must also be met. A whole URN system will specifically to an RDS that must also be met. A whole URN system will
consist of namespaces, the resolution information for them, and the consist of names in namespaces, the resolution information for them,
mapping from names in the namespaces to resolution information (or and the mapping from names in the namespaces to resolution information
hints). URN schemes must meet the requirements of RFC 1737. Resolution (or hints). URNs themselves must meet the requirements of RFC 1737.
information, to the extent it is expressed as URLs must meet the In addition, namespaces themselves must meet certain requirements as
requirements of RFC 1736. But this does not tell the whole story. described in RFC NNNN[5]. Although all these requirements and
Although the URN working group will identify several acceptable guidelines are not described here, they must be supported to provide
namespaces and the rules binding them, such as how delegation occurs, an acceptable system.
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
document will be needed to guide the evaluation criteria for acceptance
of new namespaces. These are not included in the list of guidelines
below because they are not guidelines or requirements for an RDS, but
rather are requirements for naming schemes themselves.
Each section below begins with a summary of the points made and Each section below begins with a summary of the points made in that
discussed in the following discussion. It is worth noting here that section. There is some degree of overlap among the areas, such as in
there is some degree of overlap among the areas, such as in allowing for allowing for the evolution of security mechanisms, etc., and hence
the evolution of security mechanisms, etc. Issues may appear in more issues may be addressed in more than one section. It is also
than one place. It is also important to recognize that conformance with important to recognize that conformance with the guidelines will often
the rubrics may often be subjective. Most of these rubrics are not be subjective. As with most IETF guidelines and requirements, most of
quantifiable and hence conformance is a judgment call and a matter of these are not quantifiable and hence conformance is a judgment call
degree. Lastly, the reader may find that some of them are those of and a matter of degree. Lastly, the reader may find that some of them
general applicability to distributed systems and some are specific to are those of general applicability to distributed systems and some are
URN resolution. Those of general applicability are included for specific to URN resolution. Those of general applicability are
completeness and are not distinguished as such. included for completeness and are not distinguished as such.
3.1 Evolution 3.1 Evolution
The issues in the area of evolvability are: The issues in the area of the first principle, that of evolvability,
are:
R1.1) An RDS must be able to support scaling updwards both in terms
of the number of resources for which URNs will be required and
in terms of the number of publishers and users of those
resources;
R1.2) A hint resolution environment must support evolution of 1.1) An RDS must be able to support scaling in at least three
dimensions: the number of resources for which URNs will be
required, the number of publishers and users of those
resources, and the complexity of the delegation, as authority
for resolution grows and possibly reflects delegation in
naming authority;
1.2) A hint resolution environment must support evolution of
mechanisms, specifically for: mechanisms, specifically for:
* a growing set of URN schemes; * a growing set of URN schemes;
* new kinds local URN resolver services; * new kinds local URN resolver services;
* new authentication schemes; * new authentication schemes;
* alternative RDS schemes active simultaneously; * alternative RDS schemes active simultaneously;
R1.3) An RDS must be capable of supporting the separation of global 1.3) An RDS must allow the development and deployment of
identification from location information;
R1.4) An RDS must allow the development and deployment of
administrative control mechanisms to manage human behavior with administrative control mechanisms to manage human behavior with
respect to limited resources. 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
- 6 -
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. 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, scaling is a primary issue in conjunction with evolution. The First, scaling is a primary issue in conjunction with evolution. The
number of users and publishers is certainly on an increasing trajectory. number of users, both human and electronic, as well as the number of
One might consider that it has an upper limit based on the population,
but that assumes that resources are only published by and for the use of - 6 -
humans. As our world becomes more automated, more "users" will be
electronic. In addition, clearly the number of resources will grow by resources will continue to grow exponentially for the near term, at
orders of magnitude. Hence the number of URNs will also increase least. Hence the number of URNs will also increase similarly. In
similarly. These facts mean that an RDS design must be prepared to addition, with growth in sheer numbers is likely to come growth in the
handle increasing numbers of requests for inclusion, update and delegation of both naming authority and resolution authority. These
resolution. This is not to say that there will necessarily be more facts mean that an RDS design must be prepared to handle increasing
updates or resolutions per URN; we cannot predict that at this time. numbers of requests for inclusion, update and resolution, in a set of
Any design is likely to perform less well above some set of limits, so RDS servers perhaps inter-related in more complex ways. This is not
it is worth considering the growth limitations of each design to say that there will necessarily be more updates or resolutions per
URN; we cannot predict that at this time. But, even so, the
infrastructure may become more complex due to delegation, which may
(as can be seen in Section 4 on the framework) lead to more complex
rules for rewriting or extracting terms for staged resolution. Any
design is likely to perform less well above some set of limits, so it
is worth considering the growth limitations of each design
alternative. alternative.
Second, we expect there to be additions and changes to the mechanisms. Second, 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
URN schemes. A URN scheme will define a set of URNs that meet the URN new URN schemes, as described in [5]. A URN scheme will define a set
requirements[RFC1737], but may have further constraints on the internal of URNs that meet the URN requirements[2], but may have further
structure of the URN. The intention is that URN schemes can be free to constraints on the internal structure of the URN. The intention is
specify parts of the URN that are left opaque in the larger picture. In that URN schemes can be free to specify parts of the URN that are left
fact, a URN scheme may choose to make public the algorithms for any such opaque in the larger picture. In fact, a URN scheme may choose to
"opaque" part of the URN. For example, although it may be unnecessary to make public or keep private the algorithms for any such "opaque" part
know the structure of an ISBN, the algorithm for understanding the of the URN. In any case, we must be prepared for a growing number of
structure of an ISBN has been made public. Other schemes may either URN schemes.
choose not to make their 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 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 kinds of resolver services may evolve. of any particular URN scheme, new kinds of resolver services may
For example, one can imagine a specialized resolver 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 resolver service that trades performance for generality; can also imagine a general purpose resolver service that trades
although it exhibits only average performance resolving ISBNs, it makes performance for generality; although it exhibits only average
up for this weakness by understanding all existing URN schemes, so that performance resolving ISBNs, it makes up for this weakness by
its clients can use the same service to resolve URNs regardless of understanding all existing URN schemes, so that its clients can use
naming scheme. In this context, there will always be room for the same service to resolve URNs regardless of naming scheme. In this
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, for example. In any through improved performance, better adaptability to new URN schemes,
case, new models for URN resolution will evolve and we must be prepared or lower cost, for example. New models for URN resolution will evolve
to allow for 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
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 authentication scheme, and there may never be one. Even if
one does exist at some point in time, we must always be prepared to
move on to newer and better schemes, as the old ones become too easily
spoofed or guessed.
- 7 - In terms of mechanism, although we may develop and deploy a single RDS
scheme initially, we must be prepared for that top level model to
useful or necessary in the future. There is no single globally accepted evolve. Thus, if the RDS model supports an apparently centralized
authentication scheme, and there may never be one. Even if one does (from a policy standpoint) scheme for inserting and modifying
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
the old ones become too easily spoofed or guessed.
Lastly, in terms of mechanism, although we may develop and deploy a
single RDS scheme initially, we must be prepared for that top level
model to evolve. Thus, if the RDS model supports an apparently
centralized (from a policy standpoint) scheme for inserting and
modifying authoritative information, over time we must be prepared to
evolve to a different model, perhaps one that has a more distributed
model of authority and authenticity. If the model has no core but
rather a cascaded partial discovery of information, we may find that
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
scaling, performance, and policy constraints such as security and cost.
Second, in addition to the evolution of resolution mechanisms, we expect
that the community will follow an evolutionary path towards the
separation of location information from identification. The URN
requirements document suggested this path as well, and there has been
general agreement in much of the community that such a separation is
desirable. This is a problem that the public at large has generally not
understood. Today we see the problem most clearly with the use of URLs
for identification. When a web page moves, its URL becomes invalid.
Suppose such a URL is embedded in some page, stored in long term
storage. There are three possible outcomes to this scenario. One
possibility is that the client is left high and dry with some message
saying that the page cannot be found. Alternatively, a "forwarding
pointer" may be left behind, in the form of an explicit page requesting
the client to click on a new URL. Although this will allow the client to
find the intended page, the broken link cannot be fixed because the URL
is embedded in a file outside of the client's control. A third
alternative is that the target server supplies redirect so that the new
page is provided for the client automatically. In this case, the client
may not even realize that the URL is no longer correct. The real
problem with both of these latter two situations is that they only work
as long as the forwarding pointer can be found at the old URL. Location
information was embedded in the identifier, and the resolution system
was designed to depend on that location information being correct.
There are few cases in which we can expect such information to remain
valid for a long time, but in many cases references need to have long
lifespans. Most documents are only useful while their references still
function. To the extent that an RDS scheme supports the separation of
global identification from location information it will be encouraging
the longer utility of the identities.
A third evolutionary issue is even more mechanical than the others. At - 7 -
any point in time, the community is likely to be supporting a compromise
position with respect to resolution. We will probably be operating in a
situation balanced between feasibility and the ideal, perhaps with
policy controls used to help stabilize use of the service. 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
- 8 - authoritative information, over time we must be prepared to evolve to
a different model, perhaps one that has a more distributed model of
authority and authenticity. If the model has no core but rather a
cascaded partial discovery of information, we may find that this
becomes unmanageable with an increase in scaling. Whatever the model,
we must be prepared for it to evolve with changes in scaling,
performance, and policy constraints such as security and cost.
be in short supply, some form of policy controls will always be The third evolutionary issue is even more mechanical than the others.
necessary. Some policy controls may be realized as mechanisms within At any point in time, the community is likely to be supporting a
the servers or in the details of protocols, while others may only be compromise position with respect to resolution. We will probably be
realized externally to the system. For example, suppose hint entries operating in a situation balanced between feasibility and the ideal,
are being submitted in such volume that the hint servers are using up perhaps with policy controls used to help stabilize use of the
their excess capacity and need more disk space. An effective solution service. Ideally, the service would be providing exactly what the
to this problem would be a mechanism such as a pricing policy. This customers wanted and they in turn would not request more support than
pricing policy has the dual effect of both encouraging conservative use they need, but it seems extremely unlikely. Since we will almost
of resources and collecting revenue for the improvement and maintenance always be in a situation in which some service provision resources
of the system. We can also imagine administrative policy controls with will be in short supply, some form of policy controls will generally
the force of laws or other social pressures behind them, but with no be necessary. Some policy controls may be realized as mechanisms
technical mechanism enforcing or enabling them. As technology changes within the servers or in the details of protocols, while others may
and the balance of which resources are in short supply changes, the only be realized externally to the system. For example, suppose hint
mechanisms and policies for controlling their use must evolve as well. entries are being submitted in such volume that the hint servers are
using up their excess capacity and need more disk space. Two
suggestions for policy control are pricing and administrative. 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.
3.2 Usability and Feature Set Issues 3.2 Usability
To summarize, the usability rubrics fall into three areas based on To summarize, the usability guidelines fall into three areas based on
participation in hint management and discovery: participation in hint management and discovery:
R2.1) The publisher 2.1) The publisher
R2.1.1) URN to hint resolution must be correct and efficient with 2.1.1) URN to hint resolution must be correct and efficient with
very high probability; very high probability;
R2.1.2) Publishers must be able to select and move among URN 2.1.2) Publishers must be able to select and move among URN
resolver services to locate their resources; resolver services to locate their resources;
R2.1.3) Publishers must be able to arrange for multiple access 2.1.3) Publishers must be able to arrange for multiple access
points for their location information; points for their location information;
R2.1.4) Publishers should be able to provide for both long-lived 2.1.4) Publishers should be able to provide hints with varying
and short-lived hints; lifetimes;
R2.1.5) It must be relatively easy for publishers to specify to 2.1.5) It must be relatively easy for publishers to specify to
the management and observe their hint information as well the management and observe their hint information as well
as any security constraints they need for their hints. as any security constraints they need for their hints.
R2.2) The client 2.2) The client
R2.2.1) The interface to the RDS must be simple, effective, and 2.2.1) The interface to the RDS must be simple, effective, and
efficient; efficient;
R2.2.2) The client and client applications must be able to 2.2.2) The client and client applications must be able to
understand the information stored in and provided by the understand the information stored in and provided by the
RDS easily, in order to be able to make informed choices. RDS easily, in order to be able to make informed choices.
R2.3) The management 2.3) The management
R2.3.1) The management of hints must be as unobtrusive as 2.3.1) The management of hints must be as unobtrusive as
possible, avoiding using too many network resources; possible, avoiding using too many network resources;
R2.3.2) The management of hints must allow for administrative 2.3.2) The management of hints must allow for administrative
controls that encourage certain sorts of behavior deemed controls that encourage certain sorts of behavior deemed
- 8 -
necessary to meet other requirements; necessary to meet other requirements;
R2.3.3) The configuration and verification of configuration of 2.3.3) The configuration and verification of configuration of
individual RDS servers must be simple enough not to individual RDS servers must be simple enough not to
discourage configuration and verification. 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
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
issues from each of these three perspectives. issues 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
- 9 -
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 an RDS 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 with URNs be correctly and efficiently resolvable by potential clients with
very high probability. Publishers stand to gain from long-lived URNs, very high probability. Publishers stand to gain from long-lived URNs,
since they increase the chance that references continue to point to since they increase the chance that references continue to point to
their published resources. their published resources.
The publisher must also be able to choose easily among a variety of The publisher must also be able to choose easily among a variety of
potential services that might translate URNs to location information. potential services that might translate URNs to location information.
In order to allow for this mobility among resolver services, the In order to allow for this mobility among resolvers, the RDS
architecture for resolver services specified within the IETF should not architecture must support such transitions, within policy control
result in a scenario in which changing from one resolver service to bounds. It is worth noting that although multiple listing services
another is an expensive operation. are available in telephone books, they are generally accompanied by a
fee. There is nothing preventing there being fees collected for
similar sorts of services with respect to URNs.
The publisher must be able to arrange for multiple access points to a The publisher must be able to arrange for multiple access points to a
published resource. For this to be useful, resolver services should be published resource. For this to be useful, resolver services should
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
and the various access privileges the client might have. For example, location and the various access privileges the client might have. It
companies might arrange for locally replicated copies of popular is important to note that this may have serious implications for
resources, and would like to provide access to the local copies only for caching this information. For example, companies might arrange for
their own employees. This is distinct from access control on the locally replicated copies of popular resources, and would like to
resource as a whole, and may be applied differently to different copies. provide access to the local copies only for their own employees. This
is distinct from access control on the 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
location information about accessing the resource. Long term location information about accessing the resource. Long term
information is likely to be such information as the long term or the information is likely to be such information as the long term address
location or identity of a resolver service with which the publisher has of a resource itself or the location or identity of a resolver service
a long term relationship. One can imagine that the arrangement with with which the publisher has a long term relationship. One can
such a long term "authoritative" resolver service might be a guarantee imagine that the arrangement with such a long term "authoritative"
of reliability, resiliency to failure, and atomic updates. Shorter term resolver service might be a guarantee of reliability, resiliency to
information is useful for short term changes in services or to avoid failure, and atomic updates. Shorter term information is useful for
short lived congestion or failure problems. For example, if the actual short term changes in services or to avoid short lived congestion or
repository of the resource is temporarily inaccessible, the resource
might be made available from another repository. This short term
information can be viewed as temporary refinements of the longer term
information, and as such should be more easily and quickly made
available, but may be less reliable.
Lastly, the publishers will be the source of much hint information that - 9 -
will be stored and served by the manager of the infrastructure. Despite
the fact that many publishers will not understand the details of the RDS
mechanism, it must be easy and straightforward for them to install hint
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.
Furthermore, to the extent that there are security constraints on hint
information, the publisher must be able to both express them and verify
compliance with them easily.
- 10 - failure problems. For example, if the actual repository of the
resource is temporarily inaccessible, the resource might be made
available from another repository. This short term information can be
viewed as temporary refinements of the longer term information, and as
such should be more easily and quickly made available, but may be less
reliable. Some RDS designs may not distinguish between these two
extremes.
Lastly, the publishers will be the source of much hint information
that will be stored and served by the manager of the infrastructure.
Despite the fact that many publishers will not understand the details
of the RDS mechanism, it must be easy and straightforward for them to
install hint information. This means that in general any one who
wishes to publish and to whom the privilege of resolution has been
extended through delegation, can do so. The publisher must be able
not only to express hints, but also to verify that what is being
served by the manager is correct. Furthermore, to the extent that
there are security constraints on hint information, the publisher must
be able to both express them and verify 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.
skipping to change at line 617 skipping to change at line 579
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
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 an RDS. 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.
- 10 -
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 an RDS. 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 with respect to name resolution to the extent that there is a
security; this is addressed in Section 3.3 below. commitment for provision of such security; this is addressed in
Section 3.3 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) must infrastructure (hint storage servers and distribution protocols) must
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 may need to be Second, in order to make hint management feasible, there may need to
a system for administrative incentives and disincentives such as pricing be a system for administrative incentives and disincentives such as
or legal restrictions. Recovering the cost of running the system is pricing or legal restrictions. Recovering the cost of running the
only one reason for levying charges. The introduction of payments often system is only one reason for levying charges. The introduction of
has a beneficial impact on social behavior. It may be necessary to payments often has an impact on social behavior. It may be necessary
discourage certain forms of behavior that when out of control have to discourage certain forms of behavior that when out of control have
serious negative impact on the whole community. At the same time, any serious negative impact on the whole community. At the same time, any
- 11 -
administrative policies should encourage behavior that benefits the administrative policies should encourage behavior that benefits the
community as a whole. Thus, for example, a small one-time charge for community as a whole. Thus, for example, a small one-time charge for
authoritatively storing a hint will encourage conservative use of hints. authoritatively storing a hint will encourage conservative use of
If we assume that there is a fixed cost for managing a hint, then the hints. If we assume that there is a fixed cost for managing a hint,
broader its applicability across the URN space, the more cost effective then the broader its applicability across the URN space, the more cost
it is. That is, when one hint can serve for a whole collection of URNs, effective it is. That is, when one hint can serve for a whole
there will be an incentive to submit one general hint over a large collection of URNs, there will be an incentive to submit one general
number of more specific hints. Similar policies can be instituted to hint over a large number of more specific hints. Similar policies can
discourage the frequent changing of hints. In these ways and others, be instituted to discourage the frequent changing of hints. In these
behavior benefitting the community as a whole can be encouraged. 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 be
simple for the management to configure the mapping of URNs to hints. It simple for the management to configure the mapping of URNs to hints. It
must be easy both to understand the configuration and to verify that must be easy both to understand the configuration and to verify that
configuration is correct. With respect to management, this issue may configuration is correct. With respect to management, this issue may
have an impact not only on the information itself but also on how it is have an impact not only on the information itself but also on how it is
partitioned among network servers that collaboratively provide the partitioned among network servers that collaboratively provide the
management service or RDS. For example, it should be straightforward to management service or RDS. For example, it should be straightforward to
bring up a server and verify that the data it is managing is correct. bring up a server and verify that the data it is managing is correct.
Although this is not a rubric, it is worth nothing that since we are Although this is not a guideline, it is worth nothing that since we are
discussing a global and probably growing service, encouraging volunteer discussing a global and probably growing service, encouraging volunteer
participants suggests that, as with the DNS, such volunteers can feel participants suggests that, as with the DNS, such volunteers can feel
confident about the service they are providing and its benefit to both confident about the service they are providing and its benefit to both
themselves and the rest of the community. themselves and the rest of the community.
3.3 Security and Privacy Issues 3.3 Security and Privacy
In summary, security and privacy rubrics can be identified as some In summary, security and privacy guidelines can be identified as some
degree of protection from threats. These rubrics are all stated in degree of protection from threats. The guidelines that fall under
terms of possibilities or options for users of the service to require this third principle, that of security, are all stated in terms of
and utilize. Hence they address the availability of functionality, but possibilities or options for users of the service to require and
- 11 -
utilize. Hence they address the availability of functionality, but
not for the use of it. We recognize that all security is a matter of not for the use of it. We recognize that all security is a matter of
degree and compromise. These may not satisfy all potential customers, degree and compromise. These may not satisfy all potential customers,
and there is no intention here to prevent the building of more secure and there is no intention here to prevent the building of more secure
servers with more secure protocols to suit their needs. These are servers with more secure protocols to suit their needs. These are
intended to satisfy the needs of the general public. intended to satisfy the needs of the general public.
R3.1) It must be possible to create authoritative versions of a hint 3.1) It must be possible to create authoritative versions of a hint
with access-to-modification privileges controlled; with access-to-modification privileges controlled;
R3.2) It must be possible to determine the identity of servers or 3.2) It must be possible to determine the identity of servers or
avoid contact with unauthenticated servers; avoid contact with unauthenticated servers;
R3.3) It must be possible to reduce the threat of denial of service 3.3) It must be possible to reduce the threat of denial of service
by broad distribution of information across servers. by broad distribution of information across servers.
R3.4) It must be possible within the bounds of organization policy 3.4) It must be possible within the bounds of organizational
criteria to provide at least some degree of privacy for policy criteria to provide at least some degree of privacy
traffic. for traffic.
R3.5) It must be possible for publishers to keep private certain 3.5) It must be possible for publishers to keep private certain
information such as an overall picture of the resources they information such as an overall picture of the resources they
are publishing and the identity of their clients; are publishing and the identity of their clients;
R3.6) It must be possible for publishers to be able to restrict 3.6) It must be possible for publishers to be able to restrict
access to the resolution of the URNs for the resources they access to the resolution of the URNs for the resources they
publish, if they wish. publish, if they wish.
When one discusses security, one of the primary issues is an enumeration When one discusses security, one of the primary issues is an enumeration
of the threats being considered for mitigation. The tradeoffs often of the threats being considered for mitigation. The tradeoffs often
- 12 -
include cost in money and computational and communications resources, include cost in money and computational and communications resources,
ease of use, likelihood of use, and effectiveness of the mechanisms ease of use, likelihood of use, and effectiveness of the mechanisms
proposed. With this in mind, let us consider a set of threats. proposed. With this in mind, let us consider a set of threats.
A good place to begin is with the early work of Voydock and Kent [VK83]. Voydock and Kent[7] provide a useful catalog of potential threats. Of
They identify unauthorized release of information as a passive attack. these the passive threats to privacy or confidentiality and the active
On the other hand, unauthorized modification of information, denial of threats of authenticity and integrity are probably the most important
service, and spurious association initiation are labelled as active to consider here. To the extent that spurious association causes
attacks. An intruder at any protocol layer can attack at any of the threats to the privacy, authenticity, or integrity with respect to
links or computational elements (hosts, routers, etc.) at that layer. information within servers managing data, it is also important.
Attacks at one layer can be achieved by subverting or attacking the Denial of service is probably the most difficult of these areas of
lower layers. An unauthorized release of information is a violation of threats both to detect and to prevent, and we will therefore set it
privacy or confidentiality. This may be achieved by a release of the aside for the present as well, although it will be seen that solutions
information itself. Additional passive threats are from secondary to other problems will also mitigate some of the problems of denial of
information through traffic analysis or other violations of transmission service. Furthermore, because this is intended to be provide a global
security, such as noticing lengths and/or sources and destinations of service to meet the needs of a variety of communities, the engineering
traffic. Moving to the active threats, unauthorized modification of tradeoffs will be different for different clients. Hence the
information can be partitioned into problems with authenticity, guidelines are stated in terms of, "It must be possible..." It is
integrity and ordering. Denial of service may take the form of important to note that the information of concern here is hint
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 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 within
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 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 rubrics 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 information, which by nature is not guaranteed to be correct or
up-to-date; therefore, it is unlikely to be worth putting too much up-to-date; therefore, it is unlikely to be worth putting too much
expense into the correctness of hints, because there is no guarantee expense into the correctness of hints, because there is no guarantee
that they are still correct anyway. But the exact choice of degree of that they are still correct anyway. The exact choice of degree of
privacy, authenticity, and integrity must be determined by the needs of privacy, authenticity, and integrity must be determined by the needs
the client and the availability of services from the server. of the client and the availability of services from the server.
To avoid confusion it is valuable to highlight the meanings of temrs To avoid confusion it is valuable to highlight the meanings of terms
that have different meanings in other contexts. In this case, the term that have different meanings in other contexts. In this case, the
"authoritative" as it is used here connotes the taking of an action or term "authoritative" as it is used here connotes the taking of an
stamp of approval by a principal (again in the security sense) that has action or stamp of approval by a principal (again in the security
the right to perform such an act of approval. It has no implication of sense) that has the right to perform such an act of approval. It has
correctness of information, but only perhaps an implication of who
- 13 - - 12 -
claimed it to be correct. In contrast, the term is often also used no implication of correctness of information, but only perhaps an
simply to refer to a primary copy of a piece of information for which implication of who claimed it to be correct. In contrast, the term is
there may also be secondary or cached copies available. In this often also used simply to refer to a primary copy of a piece of
discussion of security we use the former meaning, although it may also information for which there may also be secondary or cached copies
be important to be able to learn about whether a piece of information is available. In this discussion of security we use the former meaning,
from a primary source or not and request that it be primary. although it may also be important to be able to learn about whether a
piece of information is from a primary source or not and request that
it be primary. This second meaning arises elsewhere in the document
and is so noted there.
It is also important to distinguish various possible meanings for It is also important to distinguish various possible meanings for
"access control." There are two areas in which distinctions can be "access control". There are two areas in which distinctions can be
made. First, there is the question of the kind of access control that made. First, there is the question of the kind of access control that
is being addressed, for example, in terms of hints whether it is read is being addressed, for example, in terms of hints whether it is read
access, read and modify access, or read with verification for access, read and modify access, or read with verification for
authenticity. Second, there is the question of to what access is being authenticity. Second, there is the question of to what access is being
controlled. In the context of naming it might be the names themselves controlled. In the context of naming it might be the names themselves
(not the case for URNs), the mapping of URNs to hints (the business of (not the case for URNs), the mapping of URNs to hints (the business of
an RDS), the mapping of URNs to addresses (not the business of an RDS as an RDS), the mapping of URNs to addresses (not the business of an RDS as
will be discussed below in terms of privacy), or the resource itself will be discussed below in terms of privacy), or the resource itself
(unrelated to naming or name resolution at all). We attempt to be clear (unrelated to naming or name resolution at all). We attempt to be clear
about what is meant when using "access control." about what is meant when using "access control".
There is one further issue to address at this point, the distinction There is one further issue to address at this point, the distinction
between mechanism and policy. In general, a policy is realized by means 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 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 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 business as it sees fit. Since, in general it is in the business of
storing and distributing information, most of its security policies may storing and distributing information, most of its security policies may
have to do with maintaining its own integrity, and are rather limited. 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 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 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 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 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 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 provide all that is needed by a customer. A customer may have different
requirements within his or her administrative bounds than outside. requirements within his or her administrative bounds than outside.
Thus, "it must be possible..." captures the idea that the RDS must Thus, "it must be possible..." captures the idea that the RDS must
generally provide the tools to implement policies as needed by the generally provide the tools to implement policies as needed by the
customers. customers.
The first approach to URN resolution is to discover local hints. In The first approach to URN resolution is to discover local hints. In
order for hints to be discovered locally, they will be as widely order for hints to be discovered locally, they will need to be as
distributed to what is considered to be local for every locale. The widely distributed to what is considered to be local for every locale.
drawback of such wide distribution is the wide distribution of updates, The drawback of such wide distribution is the wide distribution of
causing network traffic problems or delays in delivering updates. An updates, causing network traffic problems or delays in delivering
alternative model would concentrate hint information in servers, thus updates. An alternative model would concentrate hint information in
requiring that update information only be distributed to these servers. servers, thus requiring that update information only be distributed to
In such a model the vulnerable points are the sources of the information these servers. In such a model the vulnerable points are the sources
and the distribution network among them. Attackers on the integrity of of the information and the distribution network among them. Attackers
the information stored in a server may come in the form of other a fake on the integrity of the information stored in a server may come in the
owner of the information or a fake server to the extent that servers form of masquerading as the owner or the server of the information.
exchange updates with each other. Wide replication of information among Wide replication of information among servers increases the difficult
servers increases the difficult of masquerading at all the locations of of masquerading at all the locations of the information as well as
the information as well as reducing the threat of denial service. These reducing the threat of denial service. These lead us to three
lead us to three identifiable goals for our security model: identifiable guidelines for our security model:
- 14 - - 13 -
* ACCESS CONTROL ON HINTS: It must be possible to create an * ACCESS CONTROL ON HINTS: It must be possible to create an
authoritative version of each hint with change control limited only authoritative version of each hint with change control limited only
to those principals with the right to modify it. The choice of who to those principals with the right to modify it. The choice of who
those principals are or whether they are unlimited must be should by those principals are or whether they are unlimited must be made by
the publisher of a hint. the publisher of a hint.
* 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 unvalidated information, the client should assume that the hint be unvalidated information, the client should assume that the hint
may be inaccurate and confirmation of the data might be sought from may be inaccurate and confirmation of the data might be sought from
skipping to change at line 842 skipping to change at line 784
* 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 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.
Privacy is a more difficult problem to address. It may be a Privacy can be a double-edged sword. For example, on one hand, an
double-edged sword; for example, an organization may consider it organization may consider it critically important that its competitors
critically important that its competitors not be able to read its not be able to read its traffic. On the other hand, it may also
traffic, while it may also consider it important to be able to monitor consider it important to be able to monitor exactly what its employees
exactly what its employees are transmitting to and from whom, for a are transmitting to and from whom, for a variety of reasons such as
variety of reasons such as reducing the probability that its employees reducing the probability that its employees are giving or selling the
are giving or selling the company's secrets to verifying that employees company's secrets to verifying that employees are not using company
are not using company resources for private endeavor. Thus, although resources for private endeavor. Thus, although there are likely to be
there are likely to be needs for privacy and confidentiality, what they needs for privacy and confidentiality, what they are, who controls
are, who controls them and how, and by what mechanisms vary widely them and how, and by what mechanisms vary widely enough that it is
enough that it is difficult to say anything concrete about them here. difficult to say anything concrete about them here.
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 general privacy is probably not desired. trying to publish something, in general privacy is probably not desired.
However, publishers do have information that they might like to keep However, publishers do have information that they might like to keep
private: information about who their clients are, and information about private: information about who their clients are, and information about
what names exist in their namespace. The information about who their what names exist in their namespace. The information about who their
clients are may be difficult to collect depending on the implementation clients are may be difficult to collect depending on the implementation
of the resolution system. For example, if the resolution information of the resolution system. For example, if the resolution information
relating to a given publisher is widely replicated, the hits to _each_ relating to a given publisher is widely replicated, the hits to _each_
replicated copy would need to be recorded. Of course, determining if a replicated copy would need to be recorded. Of course, determining if a
specific client is requesting a given name can be approached from the specific client is requesting a given name can be approached from the
other direction, by watching the client as we saw above. other direction, by watching the client as we saw above.
The other privacy issue for publishers has to do with access control There are likely to be some publishers publishing for a restricted
audience. To the extent they want to restrict access to a resource,
that is the responsibility of the repository providing and restricting
access to the resource. If they wish to keep the name and hints for a
resource private, a public RDS may be inadequate for their needs. In
- 14 -
general, it is intended for those who want customers to find their
resources in an unconstrained fashion.
The final 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 (in the sense of "primary) URN resolver the publisher's authoritative (in the sense of "primary) URN resolver
server. URN resolver servers can be designed to require proof of server. URN resolver servers can be designed to require proof of
identity in order to be issued resolution information; if the client identity in order to be issued resolution information; if the client
does not have permission to access the URN requested, the service denies does not have permission to access the URN requested, the service denies
- 15 -
that such a URN exists. An encrypted protocol can also be used so that that such a URN exists. An encrypted protocol can also be used so that
both the request and the response are obscured. Encryption is possible both the request and the response are obscured. Encryption is possible
in this case because the identity of the final recipient is known (i.e. in this case because the identity of the final recipient is known (i.e.
the URN server). Thus, access control over URN resolution can and the URN server). Thus, access control over URN resolution can and
should be provided by resolver servers rather than an RDS. should be provided by resolver servers rather than an RDS.
4. The Framework 4. The Framework
With these assumptions and guidelines in mind, we can conclude with a With these assumptions and guidelines in mind, we conclude with a
general framework within which RDS designs can fall. As stated earlier, general framework within which RDS designs may fall. As stated
although this framework is put forth as a suggested guide for RDS earlier, although this framework is put forth as a suggested guide for
designers, compliance with it will in no way guarantee compliance with RDS designers, compliance with it will in no way guarantee compliance
the rubrics. Such an evaluation must be performed separately. It is with the guidelines. Such an evaluation must be performed separately.
also understood that there may be RDS services that do not meet the
guidelines in clearly identified ways. This may be true especially with
early plans and experiments. For example, although a careful threat
analysis may have been done to understand security requirements, not all
those security issues may be addressed, in order to use existing
facilities to allow for early deployment for experimentation purposes.
All such lack of compliance should be clearly documented. All such lack of compliance should be clearly documented.
The design of the framework is based on a simple assumption about the The design of the framework is based on the syntax of a URN as
syntax of a URN a documented in RFC-2141[RFC2141]. This assumed syntax documented in RFC-2141[4]. This is:
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, and
NSS is the namespace specific string. The prefix identifies each URN as NSS is the namespace specific string. The prefix identifies each URN as
such. The NID determines the general syntax for all URNs within its such. The NID determines the general syntax for all URNs within its
namespace. The NSS is probably partitioned into a set of delegated and namespace. The NSS is probably partitioned into a set of delegated and
subdelegated namespaces, and this is probably reflected in further subdelegated namespaces, and this is possibly reflected in further
syntax specifications. In more complex environments, each delegated syntax specifications. In more complex environments, each delegated
namespace will be permitted to choose the syntax of the variable part of namespace will be permitted to choose the syntax of the variable part of
the namespace that has been delegated to it. In simpler namespaces, the the namespace that has been delegated to it. In simpler namespaces, the
syntax will be restricted completely by the parent namespace. For syntax will be restricted completely by the parent namespace. For
example, although the DNS does not meet all the requirements for URNs, example, although the DNS does not meet all the requirements for URNs,
it has a completely restricted syntax, such that any further structuring it has a completely restricted syntax, such that any further structuring
must be done only by adding further refinements to the left, maintaining must be done only by adding further refinements to the left, maintaining
the high order to low order, right to left structure. A delegated the high order to low order, right to left structure. A delegated
syntax might be one in which a host is named by the DNS, but to the syntax might be one in which a host is named by the DNS, but to the
right of that and separated by an "@" is a string whose internal right of that and separated by an "@" is a string whose internal
skipping to change at line 929 skipping to change at line 872
and nested syntaxes should be possible, especially given the need to and nested syntaxes should be possible, especially given the need to
grandfather namespaces. In order to resolve URNs, rules will be needed grandfather namespaces. In order to resolve URNs, rules will be needed
for two reasons. One is simply to canonicalize those namespaces that do for two reasons. One is simply to canonicalize those namespaces that do
not fall into a straightforward (probably right to left or left to not fall into a straightforward (probably right to left or left to
right) ordering of the components of a URN, as determined by the right) ordering of the components of a URN, as determined by the
delegated naming authorities involved. It is also possible that rules delegated naming authorities involved. It is also possible that rules
will be needed in order to derive from URNs the names of RDS servers to will be needed in order to derive from URNs the names of RDS servers to
be used in stages. 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 whether
the NID alone or in conjunction with some extraction from the NSS (for
the top level naming authority name) is to be used to identify the first
- 16 - - 15 -
the NID alone or in conjunction with some extraction from the NSS (for
the top level naming authority name) is to be used to identify the first
level server to be contacted. At each stage of the lookup either a new level server to be contacted. At each stage of the lookup either a new
rule for generating the strings used in yet another lookup (the strings rule for generating the strings used in yet another lookup (the strings
being the identity of another RDS server and possibly a string to be being the identity of another RDS server and possibly a string to be
resolved if it is different than the original URN) or a reference resolved if it is different than the original URN) or a reference
outside the RDS to a URN resolver service, sidestepping any further use outside the RDS to a URN resolver service, sidestepping any further use
of the RDS scheme. Figure 1 depicts this process. of the RDS scheme. Figure 1 depicts this process.
URN:<NID><NSS> URN:<NID><NSS>
| |
| |
skipping to change at line 984 skipping to change at line 927
|resolver | |resolver | |resolver | |resolver |
|service | |service | |service | |service |
+----------+ +----------+ +----------+ +----------+
Figure 1: An RDS framework Figure 1: An RDS framework
There are several points worth noting about the RDS framework. First, There are several points worth noting about the RDS framework. First,
it leaves open the determination of the protocols, data organization, it leaves open the determination of the protocols, data organization,
distribution and replication needed to support a particular RDS scheme. distribution and replication needed to support a particular RDS scheme.
Second, it leaves open the location of the computations engendered by Second, it leaves open the location of the computations engendered by
the rules. Third, it leaves open the possibility that partitioning
(distribution) of the RDS database need not be on the same boundaries as
- 17 - - 16 -
the rules. Third, it leaves open the possibility that partitioning
(distribution) of the RDS database need not be on the same boundaries as
the name delegation. This may seem radical to some, but if the the name delegation. This may seem radical to some, but if the
information is stored in balanced B-trees for example, the partitioning information is stored in balanced B-trees for example, the partitioning
may not be along those naming authority delegation boundaries (see may not be along those naming authority delegation boundaries (see
[Sl97]). Lastly, it leaves open access to the Global NID Registry. Is [6]). Lastly, it leaves open access to the Global NID Registry. Is
this distributed to every client, or managed in widely distributed this distributed to every client, or managed in widely distributed
servers? servers?
One concept that has not been addressed in Figure 1 is that there may be 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 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 evolution to new schemes. Thus, the picture should probably look more
like Figure 2. like Figure 2.
URN:<NID>:<NSS> URN:<NID>:<NSS>
| |
skipping to change at line 1019 skipping to change at line 962
+---------------------+ +---------------------+ +---------------------+ +---------------------+
|Global NID registry 1| |Global NID registry N| |Global NID registry 1| |Global NID registry N|
+---------------------+ +---------------------+ +---------------------+ +---------------------+
. . . .
. . . .
. . . .
Figure 2: More than one co-existing RDS scheme Figure 2: More than one co-existing RDS scheme
If we are to support more than one co-existing RDS 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 among 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 RDS scheme. One cannot expect potential through any operational RDS scheme. One cannot expect potential
publishers to submit updates to more than one RDS scheme. Hence there publishers to submit updates to more than one RDS scheme. Hence there
will need to be a straightforward mapping of information from one to the will need to be a straightforward mapping of information from one to the
other of these schemes. It is possible that that transformation will other of these schemes. It is possible that that transformation will
only go in one direction, because a newer RDS service is replacing an only go in one direction, because a newer RDS service is replacing an
older one, which is not kept up to date, in order to encourage transfer older one, 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 to the newer one. Thus, at some point, updates may be made only to the
newer one and not be made available to the older one, as is often done newer one and not be made available to the older one, as is often done
with library catalogs. with library catalogs.
This framework is presented in order to suggest to RDS scheme designers This framework is presented in order to suggest to RDS scheme designers
a direction in which to start designing. It should be obvious to the a direction in which to start designing. It should be obvious to the
reader that adherence to this framework will in no way guarantee reader that adherence to this framework will in no way guarantee
compliance with the guidelines or even the assumptions described in compliance with the guidelines or even the assumptions described in
Sections 2 and 3. These must be reviewed independently as part of the Sections 2 and 3. These must be reviewed independently as part of the
design process. There is no single correct design that will conform to design process. There is no single correct design that will conform to
these guidelines. Furthermore, it is assumed that preliminary proposals these guidelines. Furthermore, it is assumed that preliminary proposals
- 17 -
may not meet all the guidelines, but should be expected to itemized and may not meet all the guidelines, but should be expected to itemized and
justify any lack of compliance. justify any lack of compliance.
- 18 -
5. Acknowledgments 5. Acknowledgments
Foremost acknowledgment for this document goes to Lewis Girod, as my Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a preliminary URN requirements document and for his co-author on a preliminary URN requirements document and for his
insightful comments on this version of the document. In addition, I insightful comments on this version of the document. Thanks also go
recognize the contributors to a previous URN framework document, the to Ron Daniel especially for his many comments on my writing. In
"Knoxville" group. There are too many of you to acknowledge here addition, I recognize the contributors to a previous URN framework
individually, but thank you. Finally, I must thank the contributors to document, the "Knoxville" group. There are too many of you to
the URN working group mailing list (urn-ietf@bunyip.com), for their acknowledge here individually, but thank you. Finally, I must thank
animated discussions on these and related topics. the contributors to the URN working group and mailing list
(urn-ietf@bunyip.com), for your animated discussions on these and
related topics.
6. References 6. References
[RFC1736] Kunze, J., "Functional Recommendations for Internet Resource [1] 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 [2] Sollins, K. and Masinter, L., "Functional Requirements for Uniform
Uniform Resource Names", RFC 1738, December, 1994. Resource Names", RFC 1738, December, 1994.
[RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform [3] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource
Resource Locators (URL)", RFC 1738, December, 1994. Locators (URL)", RFC 1738, December, 1994.
[RFC2141] Moats, Ryan, "URN Syntax", RFC 2141, May 1997. [4] Moats, R., "URN Syntax", RFC 2141, May 1997.
[Sl97] Slottow, E.G., "Engineering a Global Resolution Service," [5] Iannella, R. and Faltstrom, P., "Namespace Identifier Requirements
for URN Services," currently draft-ietf-urn-nid-req-01.txt. Intended
to become an information rfc by the URN working group.
[6] Slottow, E.G., "Engineering a Global Resolution Service,"
MIT-LCS-TR712, June, 1997. Currently available as MIT-LCS-TR712, June, 1997. Currently available as
<http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or <http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or
<http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>. <http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.
[VK83] Voydock, V. L., and Kent, S. T., "Security Mechanisms in [7] Voydock, V. L., and Kent, S. T., "Security Mechanisms in
High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June,
1983, pp. 135-171. 1983, pp. 135-171.
7. Contact information: 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 Internet Draft expires on December 4, 1997. This Internet Draft expires on December 4, 1997.
- 19 - - 18 -
 End of changes. 105 change blocks. 
574 lines changed or deleted 524 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/