draft-ietf-urn-req-frame-01.txt   draft-ietf-urn-req-frame-02.txt 
Internet Draft Karen R. Sollins Internet Draft Karen R. Sollins
draft-ietf-urn-req-frame-01.txt MIT/LCS draft-ietf-urn-req-frame-02.txt MIT/LCS
Expires September 28, 1997 March 28, 1997 Expires December 4, 1997 June 4, 1997
Requirements and a Framework for URN Resolution Systems Guidelines and a Framework for URN Resolution Systems
Status of this draft Status of this draft
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 local URN This document addresses the issues of the discovery of URN resolver
resolver services that in turn will directly translate URNs into services that in turn will directly translate URNs into URLs and URCs.
URLs and URCs. The document falls into three major parts, the The document falls into three major parts, the assumptions underlying
assumptions underlying the work, the requirements in order to be a the work, the guidelines in order to be a viable Resolver Discovery
viable Resolver Discovery Service or RDS to help in finding URN Service or RDS to help in finding URN resolvers, and a framework for
resolvers, and a framework for designing RDSs. The requirements fall designing RDSs. The guidelines fall into three major areas:
into three major areas: evolvability, usability, and security and evolvability, usability, and security and privacy. An RDS that is
privacy. An RDS that is compliant with the framework will not compliant with the framework will not necessarily be compliant with the
necessarily be compliant with the requirements. Compliance with the guidelines. Compliance with the guidelines will need to be validated
requirements will need to be validated separately. separately.
1. Introduction 1. Introduction
The purpose of this document is to lay out the engineering criteria The purpose of this document is to lay out the engineering criteria for
for what we will call here a Resolver Discovery Service (RDS), a what we will call here a Resolver Discovery Service (RDS), a service to
service to help in the learning about URN resolvers. This is a help in the learning about URN resolvers. This is a component of the
component of the realization of an information infrastructure. In the realization of an information infrastructure. In the case of this work,
case of this work, that infrastructure is to be available, "in the that infrastructure is to be available, "in the Internet" or globally,
Internet" or globally, and hence the solutions to the problems we are and hence the solutions to the problems we are addressing must globally
addressing must globally scalable. In this work, we are focussing scalable. In this work, we are focussing specifically on naming of
specifically on naming of resources and resolution of those names to resources and resolution of those names to the exclusion of other
the exclusion of other problems such as typing, resource access and problems such as typing, resource access and availability, security of
availability, security of the resources, etc. Those are all important the resources, etc. Those are all important problems, but not part of
problems, but not part of this effort. this effort.
The Uniform Resource Identifier Working Group defined a naming The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736[RFC1736], architecture, as demonstrated in a series of three RFCs 1736[RFC1736],
- 1 - - 1 -
1737{RFC1737}, and 1738[RFC1738]. Although several further documents 1737{RFC1737}, and 1738[RFC1738]. Although several further documents
are needed to complete the description of that architecture, it are needed to complete the description of that architecture, it
incorporates three core functions often associated with "naming": incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics. By location, we identification, location, and mnemonics or semantics. By location, we
mean full-qualified Domain Names or IP addresses. Names may provide mean fully-qualified Domain Names or IP addresses. Names may provide
the ability to distinguish one resource from another, by the ability to distinguish one resource from another, by distinguishing
distinguishing their "names". Names may help to provide access to a their "names". Names may help to provide access to a resource by
resource by including "location" information. Lastly, names may have including "location" information. Lastly, names may have other semantic
other semantic or mnemonic information that either helps human users or mnemonic information that either helps human users remember or figure
remember or figure out the names, or include other semantic out the names, or include other semantic information about the resource
information about the resource being named. The URI working group being named. The URI working group concluded that there was need for
concluded that there was need for persistent, globally unique persistent, globally unique identifiers, distinct from location or other
identifiers, distinct from location or other semantic information; semantic information; these "names" provide identity, in that if two of
these "names" provide identity, in that if two of them are "the same" them are "the same" (under some simple rule of canonicalization), they
(under some simple rule of canonicalization), they identify the same identify the same resource. Furthermore, the group decided that these
resource. Furthermore, the group decided that these "names" were "names" were generally to be for machine, rather than human,
generally to be for machine, rather than human consumption. One can consumption. One can imagine a variety human-friendly naming (HFN)
imagine a variety human-friendly naming (HFN) schemes supporting schemes supporting different suites of applications and user
different suites of applications and user communities. These will communities. These will need to provide mappings to URNs in tighter or
need to provide mappings to URNs in tighter or looser couplings, looser couplings, depending on the namespace. It is these HFNs that
depending on the namespace. It is these that will be mnemonic, will be mnemonic, content-full, and perhaps mutable, to track changes in
content-full, and perhaps mutable, to track changes in use and use and semantics. They may provide nicknaming and other aliasing,
semantics. They may provide nicknaming and other aliasing, relative relative or short names, context sensitive names, descriptive names,
or short names, context sensitive names, descriptive names, etc. The etc. The URI naming architecture as described in the introductions to
URI naming architecture as described in the introductions to RFCs 1736 RFCs 1736 and 1737 lays out three sorts of components to the naming
and 1737 lays out three sorts of components to the naming architecture: identifiers called Uniform Resource Names (URNs), locators
architecture: identifiers called Uniform Resource Names (URNs), called Uniform Resource Locators (URLs) and semantic meta-information
locators called Uniform Resource Locators (URLs) and semantic called Uniform Resource Characteristics (URCs). This document focusses
meta-information called Uniform Resource Characteristics (URCs). This on part of the problem of the translation from URN to URL and/or URC.
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
in that a URN anywhere in any context identifies the same resource.
With respect to an RDS we must ask what URN ubiquity implies for the RDS
and for resolution in general. But in terms of Internet services and
accessibility, there can be no systematic guarantees. In addition, 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 locations under some conditions, and at different times, due to
either the vagueries of network conditions or policy controls a URN may
sometimes be resolvable and other times or places not. Ubiquitous
resolution cannot be assumed simply because naming is ubiquitous. On
the other hand wide deployment and usage will be an important feature 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 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 interim stage in accessing a resource. A hint may also have
meta-information associated with it, such as an expiration_time or meta-information associated with it, such as an expiration_time or
certification of authenticity. We expect that these will stay with a certification of authenticity. We expect that these will stay with a
hint rather than being managed elsewhere. We will assume in all hint rather than being managed elsewhere. We will assume in all further
further discussion of hints that they include any necessary discussion of hints that they include any necessary meta-information as
meta-information as well as the hint information itself. Examples of well as the hint information itself. Examples of hints are: 1) the name
hints are: 1) the name of a resolver service that may further resolve of a resolver service that may further resolve the URN, 2) the address
the URN, 2) the address of such a service, 3) a location at which the of such a service, 3) a location at which the resource was previously
resource was previously found. The defining feature of hints is that
they are only hints; they may be out of date, temporarily invalid, or
only applicable within a specific locality. They do not provide a
guarantee of access, but they probably will help in the resolution
process. We must assume that most resolutions of URNs will be
provided by the use of locally stored hints, because maintaining a
database of globally available, completely up-to-date location
information is infeasible for performance reasons. There are a number
of circumstances in which one can imagine that hints become invalid,
either because a resource has moved or because a different URN
resolver service has taken over the responsibility for resolution of
the URN. Hints may be found in a variety of places. It is generally
assumed that a well engineered system will maintain a set of hints for
- 2 - - 2 -
each URN at each location where that URN is found. In addition, for found. The defining feature of hints is that they are only hints; they
those situations in which those hints found locally fail, a may be out of date, temporarily invalid, or only applicable within a
well-engineered system will provide a fall-back mechanism for specific locality. They do not provide a guarantee of access, but they
discovering further hints. It is this fall-back mechanism, an RDS, probably will help in the resolution process. We must assume that most
that is being addressed in this document. As with all hints, there resolutions of URNs will be provided by the use of locally stored hints,
can never be a guarantee that access to a resource will be available because maintaining a database of globally available, completely
to all clients, even if the resource is accessible to some. However, up-to-date location information is infeasible for performance reasons.
an RDS is expected to work with reasonably high reliability, and, There are a number of circumstances in which one can imagine that hints
hence, may result in increased response time. become invalid, either because a resource has moved or because a
different URN resolver service has taken over the responsibility for
resolution of the URN. Hints may be found in a variety of places. It
is generally assumed that a well engineered system will maintain a set
of hints for each URN at each location where that URN is found. 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. The next identifies several sets of assumptions underlying this work. There are
lays out the requirements for a Resolver Discovery Service. This three general assumptions:
section is probably the most critical of the document, because it is * URNs are persistant;
this that provides the metric for whether or not a proposed scheme for * URN assignment can be delegated;
a RDS is adequate or not. For the reader short on time, each of the * Decisions can be made independently, enabling isolation from decisions
three major subsections of the requirements section begins with a of one's peers.
summary list of the requirements identified in that section. The
final section of the document lays out a framework for such RDSs. The The next section lays out the guidelines for a Resolver Discovery
purpose of this last section is to bound the search space for RDS Service. This section is probably the most critical of the document,
schemes. One must be careful not to assume that because an RDS scheme because it is this that provides the metric for whether or not a
fits within the framework that it necessarily meets the requirements. proposed scheme for a n RDS is adequate or not. To summarize, there are
As will be discussed further in this last section, designing within three core rubrics, each of which is refined and subdivided below:
the framework does not guarantee compliance, so compliance evaluation R1) An RDS must allow for evolution and evolvability;
must also be part of the process of evaluation of a scheme. R2) Usability of an RDS with regard to each of the sets of constituents
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 -
For the reader short on time, each of the three major subsections of the
guidelines section begins with a summary list of the more detailed
guidelines identified in that section. The final section of the
document lays out a framework for such RDSs. The purpose of this last
section is to bound the search space for RDS schemes. One must be
careful not to assume that because an RDS scheme fits within the
framework that it necessarily meets the guidelines. As will be
discussed further in this last section, designing within the framework
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 requirements state that a URN is to be a "persistent The URN guidelines state that a URN is to be a "persistent identifier".
identifier". It is probably the case that nothing will last forever, It is probably the case that nothing will last forever, but in the time
but in the time frame of resources, users of those resources, and the frame of resources, users of those resources, and the systems to support
systems to support the resources, the identifier should be considered to the resources, the identifier should be considered to be persistent or
be persistent or have a longer lifetime than those other entities. have a longer lifetime than those other entities. There are two
There are two assumptions that are implied by longevity of URNs: assumptions that are implied by longevity of URNs: mobility and
mobility and evolution. "Mobility" assumes that everything will move evolution. "Mobility" assumes that everything will move over the life
over the life of a URN. For example, resources will move from one of a URN. For example, resources will move from one machine to another,
machine to another, because individual machines have a much shorter because individual machines have a much shorter lifetime than resources,
lifetime than resources, generally measured in a number of years less generally measured in a number of years less than a decade. Owners of
than a decade. Owners of resources may move and wish their resources to resources may move and wish their resources to follow them. The
follow them. The services themselves will move. "Evolution" assumes services themselves will move. "Evolution" assumes that the supporting
that the supporting infrastructure will evolve. This may take the form infrastructure will evolve. This may take the form of entirely new
of entirely new transport protocols or new versions of existing transport protocols or new versions of existing protocols. Furthermore,
protocols. Furthermore, services such as storage services may evolve; services such as storage services may evolve; it is even possible that
it is even possible that within a human lifetime the Unix file system within a human lifetime the Unix file system model may no longer be in
model may no longer be in use! Clearly there will be evolution of and use! Clearly there will be evolution of and improvement in supporting
improvement in supporting authentication and security mechanisms. These authentication and security mechanisms. These are only examples. In
are only examples. In general, we must assume that almost any piece of general, we must assume that almost any piece of the supporting
the supporting infrastructure of URN resolution will evolve. In order infrastructure of URN resolution will evolve. In order to deal with
to deal with both the mobility and evolution assumptions that derive both the mobility and evolution assumptions that derive from the
from the assumption of longevity, we must assume that users and their assumption of longevity, we must assume that users and their
- 3 -
applications can remain independent of these mutating details of the applications can remain independent of these mutating details of the
supporting infrastructure. supporting infrastructure.
The second and third assumptions are two forms of modularity: delegation The second and third assumptions are two forms of modularity: delegation
and isolation. The delegation assumption is that an entity may and isolation. The delegation assumption is that an entity may
partition and pass off some of its authority or responsibility. One of partition and pass off some of its authority or responsibility. One of
those responsibilities is for assigning URNs; practically speaking, those responsibilities is for assigning URNs; practically speaking,
there cannot be only a single authority for assigning URNs. We expect there cannot be only a single authority for assigning URNs. We expect
that there will be a multi-tiered naming authority delegation. that there will be a multi-tiered naming authority delegation.
Furthermore, it is difficult to imagine a non-partitioned and delegated Furthermore, it is difficult to imagine a non-partitioned and delegated
global RDS, meaning that hint discovery and resolution will be global RDS, meaning that hint discovery and resolution will be
partitioned and delegated. In some RDS schemes, the delegation of partitioned and delegated. In some RDS schemes, the delegation of
naming authority will form a basis for delegating the management and naming authority will form a basis for delegating the management and
dispensing of location information. dispensing of location information.
- 4 -
The third assumption is independence or isolation of one authority from The third assumption is independence or isolation of one authority from
another and, at least to some extent from its parent. Underlying much another and, at least to some extent from its parent. Underlying much
of the thinking and discussion in the URI and URN working groups has of the thinking and discussion in the URI and URN working groups has
been the assumption that when a component delegates authority to another been the assumption that when a component delegates authority to another
component, the delegatee can operate in that domain independently of its component, the delegatee can operate in that domain independently of its
peers and within bounds specified by the delegation, independently of peers and within bounds specified by the delegation, independently of
the delegator. This isolation is critically important in order to allow the delegator. This isolation is critically important in order to allow
for independence of policy and mechanism. for independence of policy and mechanism.
There are a number of more specific assumptions that fall under this There are a number of more specific assumptions that fall under this
skipping to change at line 230 skipping to change at line 272
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 a
namespace, limited by any restrictions or constraints that may have been namespace, limited by any restrictions or constraints that may have been
set by its parent namespace. This is a choice held by naming set by its parent namespace. This is a choice held by naming
authorities over their own subnamespaces. Rules for canonicalization authorities over their own subnamespaces. Rules for canonicalization
will be discussed further in the framework section below. Thus, there will be discussed further in the framework section below. Thus, there
are assumptions of independence and isolation to allow for delegated, are assumptions of independence and isolation to allow for delegated,
independent authority in a variety of domains. independent authority in a variety of domains.
- 4 -
The modularity assumptions of delegation and isolation imply The modularity assumptions of delegation and isolation imply
independence of decision and implementation, leading to a independence of decision and implementation, leading to a
decentralization that provides a certain degree of safety from denial of decentralization that provides a certain degree of safety from denial of
service. Based on these these assumptions in conjunction with that of service. Based on these these assumptions in conjunction with that of
longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737,
we can now turn to the requirements for a Resolver Discovery Service. we can now turn to the guidelines for a Resolver Discovery Service.
3. Requirements 3. Guidelines
The requirements applying to a Resolver Discovery Service or RDS The guidelines or rubrics applying to a Resolver Discovery Service or
center around three important design goals: evolvability, usability, RDS center around three important design goals: evolvability, usability,
and security and privacy. At its core the function of an RDS is to and security and privacy. At its core the function of an RDS is to
provide hints for accessing a resource given a URN for it. These provide hints for accessing a resource given a URN for it. These hints
hints may range in applicability from local to global, and from may range in applicability from local to global, and from short-lived to
short-lived to long-lived. They also may vary in their degree of long-lived. They also may vary in their degree of verifiable
verifiable authenticity. While it may be neither feasible nor authenticity. While it may be neither feasible nor necessary that
necessary that initial implementations support every requirement,
every implementation must support evolution to systems that do support
every requirement.
It is important to note that there are other requirements, not - 5 -
applicable specifically to an RDS that must also be met. A whole URN
system will consist of namespaces, the resolution information for them, initial implementations support every guideline, every implementation
and the mapping from names in the namespaces to resolution information must support evolution to systems that do support every rubric.
(or hints). URN schemes must meet the requirements of RFC 1737.
Resolution information, to the extent it is expressed as URLs must meet It is important to note that there are requirements, not applicable
the requirements of RFC 1736. But this does not tell the whole story. specifically to an RDS that must also be met. A whole URN system will
consist of namespaces, the resolution information for them, and the
mapping from names in the namespaces to resolution information (or
hints). URN schemes must meet the requirements of RFC 1737. Resolution
information, to the extent it is expressed as URLs must meet the
requirements of RFC 1736. But this does not tell the whole story.
Although the URN working group will identify several acceptable Although the URN working group will identify several acceptable
namespaces and the rules binding them, such as how delegation occurs, namespaces and the rules binding them, such as how delegation occurs,
how it is expressed in the names, how and to what extent binding to hint how it is expressed in the names, how and to what extent binding to hint
information will be constrained by the namespace, in the long run a information will be constrained by the namespace, in the long run a
document will be needed to guide the evaluation criteria for acceptance document will be needed to guide the evaluation criteria for acceptance
of new namespaces. These are not included in the list of requirements of new namespaces. These are not included in the list of guidelines
below because they are not requirements for an RDS, but rather for naming below because they are not guidelines or requirements for an RDS, but
schemes themselves. rather are requirements for naming schemes themselves.
Each section below begins with a summary of the points made and discussed Each section below begins with a summary of the points made and
in the following discussion. It is worth noting here that there is discussed in the following discussion. It is worth noting here that
some degree of overlap in the areas of requirements, 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. Issues may the evolution of security mechanisms, etc. Issues may appear in more
appear in more than one requirement. It is also important to than one place. It is also important to recognize that conformance with
recognize that conformance with the requirements may often be the rubrics may often be subjective. Most of these rubrics are not
subjective. Most of these requirements are not quantifiable and hence quantifiable and hence conformance is a judgment call and a matter of
conformance is a judgment call and a matter of degree. Lastly, the degree. Lastly, the reader may find that some of them are those of
reader may find that some of the requirements are those of general general applicability to distributed systems and some are specific to
applicability to distributed systems and some are specific to URN URN resolution. Those of general applicability are included for
resolution. Those of general applicability are included for
completeness and are not distinguished as such. completeness and are not distinguished as such.
3.1 Evolution 3.1 Evolution
The requirements in the area of evolvability are: The issues in the area of evolvability are:
[R1] To support evolution of mechanisms, specifically for R1.1) An RDS must be able to support scaling updwards both in terms
{R1.1] a growing set of URN schemes; of the number of resources for which URNs will be required and
in terms of the number of publishers and users of those
resources;
- 5 - R1.2) A hint resolution environment must support evolution of
[R1.2] new kinds local URN resolver services; mechanisms, specifically for:
[R1.3] new authentication schemes; * a growing set of URN schemes;
[R1.4] alternative RDS schemes active simultaneously; * new kinds local URN resolver services;
[R2] To support the separation of global identification from * new authentication schemes;
location information. * alternative RDS schemes active simultaneously;
[R3] To allow for the support the development and deployment of R1.3) An RDS must be capable of supporting the separation of global
administrative control mechanisms to manage human behavior identification from location information;
with respect to limited resources. R1.4) An RDS must allow the development and deployment of
administrative control mechanisms to manage human behavior with
respect to limited resources.
One of the lessons of the Internet that we must incorporate into the One of the lessons of the Internet that we must incorporate into the
development of mechanisms for resolving URNs is that we must be prepared development of mechanisms for resolving URNs is that we must be prepared
for change. Such changes may happen slowly enough to be considered for change. Such changes may happen slowly enough to be considered
evolutionary modifications of existing services or dramatically enough evolutionary modifications of existing services or dramatically enough
- 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, even at this time, prior to the
deployment of any such service. At the very least, the community and deployment of any such service. At the very least, the community and
the mechanisms proposed should be prepared for these. the mechanisms proposed should be prepared for these.
First, we expect there to be additions and changes to the mechanisms. First, scaling is a primary issue in conjunction with evolution. The
number of users and publishers is certainly on an increasing trajectory.
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
humans. As our world becomes more automated, more "users" will be
electronic. In addition, clearly the number of resources will grow by
orders of magnitude. Hence the number of URNs will also increase
similarly. These facts mean that an RDS design must be prepared to
handle increasing numbers of requests for inclusion, update and
resolution. This is not to say that there will necessarily be more
updates or resolutions per URN; we cannot predict that at this time.
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.
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 new
URN schemes. A URN scheme will define a set of URNs that meet the URN URN schemes. A URN scheme will define a set of URNs that meet the URN
requirements[RFC1737], but may have further constraints on the internal requirements[RFC1737], but may have further constraints on the internal
structure of the URN. The requirements document would allow for an structure of the URN. The intention is that URN schemes can be free to
overall plan in which URN schemes are free to specify parts of the URN specify parts of the URN that are left opaque in the larger picture. In
that are left opaque in the larger picture. In fact, a URN scheme may fact, a URN scheme may choose to make public the algorithms for any such
choose to make public the algorithms for any such "opaque" part of the "opaque" part of the URN. For example, although it may be unnecessary to
URN. For example, although it may be unnecessary to know the structure know the structure of an ISBN, the algorithm for understanding the
of an ISBN, the algorithm for understanding the structure of an ISBN has structure of an ISBN has been made public. Other schemes may either
been made public. Other schemes may either choose not to make their choose not to make their algorithms public, or choose a scheme in which
algorithms public, or choose a scheme in which knowledge of the scheme knowledge of the scheme does not provide any significant semantics to
does not provide any significant semantics to the user. In any case, we the user. In any case, we must be prepared for a growing number of URN
must be prepared for a growing number of URN schemes. 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 of any particular URN scheme, new kinds of resolver services may evolve.
evolve. For example, one can imagine a specialized resolver service For example, one can imagine a specialized resolver service based on the
based on the particular structure of ISBNs that improves the particular structure of ISBNs that improves the efficiency of finding
efficiency of finding documents given their ISBNs. Alternatively, one documents given their ISBNs. Alternatively, one can also imagine a
can also imagine a general purpose resolver service that trades general purpose resolver service that trades performance for generality;
performance for generality; although it exhibits only average although it exhibits only average performance resolving ISBNs, it makes
performance resolving ISBNs, it makes up for this weakness by up for this weakness by understanding all existing URN schemes, so that
understanding all existing URN schemes, so that its clients can use its clients can use the same service to resolve URNs regardless of
the same service to resolve URNs regardless of naming scheme. In this naming scheme. In this context, there will always be room for
context, there will always be room for improvement of services, improvement of services, through improved performance, better
through improved performance, better adaptability to new URN schemes, adaptability to new URN schemes, or lower cost, for example. In any
or lower cost. In any case, new models for URN resolution will evolve case, new models for URN resolution will evolve and we must be prepared
and we must be prepared to allow for their participation in the to allow for their participation in the overall resolution of URNs.
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
- 6 - - 7 -
evolution in the authentication schemes that will be considered either
useful or necessary in the future. There is no single globally accepted useful or necessary in the future. There is no single globally accepted
authentication scheme, and there may never be one. Even if one does authentication scheme, and there may never be one. Even if one does
exist at some point in time, there will always be threats to it, and so exist at some point in time, there will always be threats to it, and so
we must always be prepared to move on to newer and better schemes, as we must always be prepared to move on to newer and better schemes, as
the old ones become too easily spoofed or guessed. the old ones become too easily spoofed or guessed.
Lastly, in terms of mechanism, although we may develop and deploy a Lastly, in terms of mechanism, although we may develop and deploy a
single RDS scheme initially, we must be prepared for that top level single RDS scheme initially, we must be prepared for that top level
model to evolve. Thus, if the RDS model supports an apparently model to evolve. Thus, if the RDS model supports an apparently
centralized (from a policy standpoint) scheme for inserting and centralized (from a policy standpoint) scheme for inserting and
modifying authoritative information, over time we must be prepared to modifying authoritative information, over time we must be prepared to
evolve to a different model, perhaps one that has a more distributed evolve to a different model, perhaps one that has a more distributed
model of authority and authenticity. If the model has no core but model of authority and authenticity. If the model has no core but
rather a cascaded partial discovery of information, we may find that rather a cascaded partial discovery of information, we may find that
this becomes unmanageable with an increase in scaling. Whatever the this becomes unmanageable with an increase in scaling. Whatever the
core of the model, we must be prepared for it to evolve with changes in core of the model, we must be prepared for it to evolve with changes in
scaling, performance, and policy constraints such as security and cost. scaling, performance, and policy constraints such as security and cost.
Second, in addition to the evolution of resolution mechanisms, we Second, in addition to the evolution of resolution mechanisms, we expect
expect that the community will follow an evolutionary path towards the that the community will follow an evolutionary path towards the
separation of location information from identification. The URN separation of location information from identification. The URN
requirements document suggested this path as well, and there has been requirements document suggested this path as well, and there has been
general agreement in much of the community that such a separation is general agreement in much of the community that such a separation is
desirable. This is a problem that the public at large has generally desirable. This is a problem that the public at large has generally not
not understood. Today we see the problem most clearly with the use of understood. Today we see the problem most clearly with the use of URLs
URLs for identification. When a web page moves, its URL becomes for identification. When a web page moves, its URL becomes invalid.
invalid. Suppose such a URL is embedded in some page, stored in long Suppose such a URL is embedded in some page, stored in long term
term storage. There are three possible outcomes to this scenario. storage. There are three possible outcomes to this scenario. One
One possibility is that the client is left high and dry with some possibility is that the client is left high and dry with some message
message saying that the page cannot be found. Alternatively, a saying that the page cannot be found. Alternatively, a "forwarding
"forwarding pointer" may be left behind, in the form of an explicit pointer" may be left behind, in the form of an explicit page requesting
page requesting the client to click on a new URL. Although this will the client to click on a new URL. Although this will allow the client to
allow the client to find the intended page, the broken link cannot be find the intended page, the broken link cannot be fixed because the URL
fixed because the URL is embedded in a file outside of the client's is embedded in a file outside of the client's control. A third
control. A third alternative is that the target server supplies an alternative is that the target server supplies redirect so that the new
HTTP redirect so that the new page is provided for the client page is provided for the client automatically. In this case, the client
automatically. In this case, the client may not even realize that the may not even realize that the URL is no longer correct. The real
URL is no longer correct. The real problem with both of these latter problem with both of these latter two situations is that they only work
two situations is that they only work as long as the forwarding as long as the forwarding pointer can be found at the old URL. Location
pointer can be found at the old URL. Location information, was information was embedded in the identifier, and the resolution system
embedded in the identifier, and the resolution system was designed to was designed to depend on that location information being correct.
depend on that location information being correct. There are few There are few cases in which we can expect such information to remain
cases in which we can expect such information to remain valid for a valid for a long time, but in many cases references need to have long
long time, but in many cases references need to have long lifespans. lifespans. Most documents are only useful while their references still
Most documents are only useful while their references still function. function. To the extent that an RDS scheme supports the separation of
To the extent that an RDS scheme supports the separation of global global identification from location information it will be encouraging
identification from location information it will be encouraging the the longer utility of the identities.
longer utility of the identities.
A third evolutionary requirement is even more mechanical than the A third evolutionary issue is even more mechanical than the others. At
others. At any point in time, the community is likely to be any point in time, the community is likely to be supporting a compromise
supporting a compromise position with respect to resolution. We will position with respect to resolution. We will probably be operating in a
probably be operating in a situation balanced between feasibility and situation balanced between feasibility and the ideal, perhaps with
the ideal, perhaps with policy controls used to help stabilize the 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
- 7 - - 8 -
service. Ideally, the service would be providing exactly what the be in short supply, some form of policy controls will always be
customers wanted and they in turn would not request more support than necessary. Some policy controls may be realized as mechanisms within
they need. Since we will always be in a situation in which some the servers or in the details of protocols, while others may only be
service provision resources will be in short supply, some form of realized externally to the system. For example, suppose hint entries
policy controls will always be necessary. Some policy controls may be are being submitted in such volume that the hint servers are using up
realized as mechanisms within the servers or in the details of their excess capacity and need more disk space. An effective solution
protocols, while others may only be realized externally to the system. to this problem would be a mechanism such as a pricing policy. This
For example, suppose hint entries are being submitted in such volume pricing policy has the dual effect of both encouraging conservative use
that the hint servers are using up their excess capacity and need more of resources and collecting revenue for the improvement and maintenance
disk space. An effective solution to this problem would be a of the system. We can also imagine administrative policy controls with
mechanism such as a pricing policy. This pricing policy has the dual the force of laws or other social pressures behind them, but with no
effect of both encouraging conservative use of resources and technical mechanism enforcing or enabling them. As technology changes
collecting revenue for the improvement and maintenance of the system. and the balance of which resources are in short supply changes, the
We can also imagine administrative policy controls with the force of mechanisms and policies for controlling their use must evolve as well.
laws or other social pressures behind them, but with no technical
mechanism enforcing or enabling them. As technology changes and the
balance of which resources are in short supply changes, the mechanisms
and policies for controlling their use must evolve as well.
3.2 Usability and Feature Set Requirements 3.2 Usability and Feature Set Issues
To summarize, the usability requirements fall into three areas based on To summarize, the usability rubrics fall into three areas based on
participation in hint management and discovery: participation in hint management and discovery:
* The publisher R2.1) The publisher
[R4] URN to hint resolution must be correct and efficient with R2.1.1) URN to hint resolution must be correct and efficient with
very high probability; very high probability;
[R5] Publishers must be able to select and move among URN R2.1.2) Publishers must be able to select and move among URN
resolver services to locate their resources; resolver services to locate their resources;
[R6] Publishers should be able to arrange for multiple access R2.1.3) Publishers must be able to arrange for multiple access
points for their location information; points for their location information;
[R7] Publishers must be able to provide for both long-lived and R2.1.4) Publishers should be able to provide for both long-lived
short-lived hints; and short-lived hints;
[R8] It must be relatively easy for publishers to specify to the R2.1.5) It must be relatively easy for publishers to specify to
management and observer their hint information as well as the management and observe their hint information as well
any security constraints they need for their hints. as any security constraints they need for their hints.
* The client R2.2) The client
[R9] The interface to the RDS must be simple, effective, and R2.2.1) The interface to the RDS must be simple, effective, and
efficient; efficient;
[R10] The client and client applications must be able to understand R2.2.2) The client and client applications must be able to
the information stored in and provided by the RDS easily, understand the information stored in and provided by the
in order to be able to make informed choices. RDS easily, in order to be able to make informed choices.
* The management R2.3) The management
[R11] The management of hints must be as unobtrusive as possible, R2.3.1) The management of hints must be as unobtrusive as
avoiding using too many network resources; possible, avoiding using too many network resources;
[R12] The management of hints should allow for administrative R2.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
necessary to meet other requirements; necessary to meet other requirements;
[R13] The configuration and verification of configuration of R2.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
- 8 -
client requesting URN resolution, and those of the provider or manager client requesting URN resolution, and those of the provider or manager
of resolution information. We will separately address the usability of resolution information. We will separately address the usability
requirements from each of these three perspectives. 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 also stand to gain from long-lived very high probability. Publishers stand to gain from long-lived URNs,
URNs, since they increase the chance that references continue to point since they increase the chance that references continue to point to
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 resolver services, the
architecture for resolver services specified within the IETF should architecture for resolver services specified within the IETF should not
not result in a scenario in which changing from one resolver service result in a scenario in which changing from one resolver service to
to another is an expensive operation. another is an expensive operation.
The publisher should 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 published resource. For this to be useful, resolver services should be
be prepared to provide different resolution or hint information to prepared to provide different resolution or hint information to
different clients, based on a variety of information including location different clients, based on a variety of information including location
and the various access privileges the client might have. For example, and the various access privileges the client might have. For example,
companies might arrange for locally replicated copies of popular companies might arrange for locally replicated copies of popular
resources, and would like to provide access to the local copies only for resources, and would like to provide access to the local copies only for
their own employees. This is distinct from access control on the their own employees. This is distinct from access control on the
resource as a whole, and may be applied differently to different copies. resource as a whole, and may be applied differently to different copies.
The publisher should be able to provide both long and short term The publisher should be able to provide both long and short term
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 or the
location or identity of a resolver service with which the publisher location or identity of a resolver service with which the publisher has
has a long term relationship. One can imagine that the arrangement a long term relationship. One can imagine that the arrangement with
with such a long term "authoritative" resolver service might be a such a long term "authoritative" resolver service might be a guarantee
guarantee of reliability, resiliency to failure, and atomic updates. of reliability, resiliency to failure, and atomic updates. Shorter term
Shorter term information is useful for short term changes in services information is useful for short term changes in services or to avoid
or to avoid short lived congestion or failure problems. For example, short lived congestion or failure problems. For example, if the actual
if the actual repository of the resource is temporarily inaccessible, repository of the resource is temporarily inaccessible, the resource
the resource might be made available from another repository. This might be made available from another repository. This short term
short term information can be viewed as temporary refinements of the information can be viewed as temporary refinements of the longer term
longer term information, and as such should be more easily and quickly information, and as such should be more easily and quickly made
made available, but may be less reliable. available, but may be less reliable.
Lastly, the publishers will be the source of much hint information that Lastly, the publishers will be the source of much hint information that
will be stored and served by the manager of the infrastructure. Despite will be stored and served by the manager of the infrastructure. Despite
the fact that many publishers will not understand the details of the RDS the fact that many publishers will not understand the details of the RDS
mechanism, it must be easy and straightforward to install hint mechanism, it must be easy and straightforward for them to install hint
- 9 -
information. The publisher must be able not only to express hints, but information. The publisher must be able not only to express hints, but
also to verify that what is being served by the manager is correct. also to verify that what is being served by the manager is correct.
Furthermore, to the extent that there are security constraints on hint Furthermore, to the extent that there are security constraints on hint
information, the publisher must be able to both express them and verify information, the publisher must be able to both express them and verify
compliance with them easily. compliance with them easily.
- 10 -
3.2.2 The Client 3.2.2 The Client
From the perspective of the client, simplicity and usability are From the perspective of the client, simplicity and usability are
paramount. Of critical importance to serving clients effectively is paramount. Of critical importance to serving clients effectively is
that there be an efficient protocol through which the client can acquire that there be an efficient protocol through which the client can acquire
hint information. Since resolving the name is only the first step on hint information. Since resolving the name is only the first step on
the way to getting access to a resource, the amount of time spent on it the way to getting access to a resource, the amount of time spent on it
must be minimized. must be minimized.
Furthermore, it will be important to be able to build simple, standard Furthermore, it will be important to be able to build simple, standard
skipping to change at line 566 skipping to change at line 625
clients, they do not fall into the domain of this document. clients, they do not fall into the domain of this document.
3.2.3 The Management 3.2.3 The Management
Finally, we must address the usability concerns with respect to the Finally, we must address the usability concerns with respect to the
management of the hint infrastructure itself. What we are terming management of the hint infrastructure itself. What we are terming
"management" is a service that is distinct from publishing; it is the "management" is a service that is distinct from publishing; it is the
core of 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 to the extent that there is a commitment for provision of such
security; this is addressed below. 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) should 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.
- 10 - Second, in order to make hint management feasible, there may need to be
a system for administrative incentives and disincentives such as pricing
or legal restrictions. Recovering the cost of running the system is
only one reason for levying charges. The introduction of payments often
has a beneficial impact on social behavior. It may be necessary to
discourage certain forms of behavior that when out of control have
serious negative impact on the whole community. At the same time, any
Second, in order to make hint management feasible, there may need to - 11 -
be a system for administrative incentives and disincentives such as
pricing or legal restrictions. Recovering the cost of running the
system is only one reason for levying charges. The introduction of
payments often has a beneficial impact on social behavior. It may be
necessary to discourage certain forms of behavior that when out of
control have serious negative impact on the whole community. At the
same time, any administrative policies should encourage behavior that
benefits the community as a whole. Thus, for example, a small
one-time charge for authoritatively storing a hint will encourage
conservative use of hints. If we assume that there is a fixed cost
for managing a hint, then the broader its applicability across the URN
space, the more cost effective it is. That is, when one hint can
serve for a whole collection of URNs, there will be an incentive to
submit one general hint over a large number of more specific hints.
Similar policies can be instituted to discourage the frequent changing
of hints. In these ways and others, behavior benefitting the
community as a whole can be encouraged.
Lastly, symmetric to issues of usability for publishers, it must also administrative policies should encourage behavior that benefits the
be simple for the management to configure the mapping of URNs to community as a whole. Thus, for example, a small one-time charge for
hints. It must be easy both to understand the configuration and to authoritatively storing a hint will encourage conservative use of hints.
verify that configuration is correct. With respect to management, If we assume that there is a fixed cost for managing a hint, then the
this requirement may have an impact not only on the information itself broader its applicability across the URN space, the more cost effective
but also on how it is partitioned among network servers that it is. That is, when one hint can serve for a whole collection of URNs,
collaboratively provide the management service or RDS. For example, there will be an incentive to submit one general hint over a large
it should be straightforward to bring up a server and verify that the number of more specific hints. Similar policies can be instituted to
data it is managing is correct. Although this is not a requirement, discourage the frequent changing of hints. In these ways and others,
it is worth nothing that since we are discussing a global and probably behavior benefitting the community as a whole can be encouraged.
growing service, encouraging volunteer participants suggests that, as
with the DNS, such volunteers can feel confident about the service
they are providing and its benefit to both themselves and the rest of
the community.
3.3 Security and Privacy Requirements 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
must be easy both to understand the configuration and to verify that
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
partitioned among network servers that collaboratively provide the
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.
Although this is not a rubric, it is worth nothing that since we are
discussing a global and probably growing service, encouraging volunteer
participants suggests that, as with the DNS, such volunteers can feel
confident about the service they are providing and its benefit to both
themselves and the rest of the community.
SUMMARY: Security and privacy requirements can be identified as some 3.3 Security and Privacy Issues
degree of protection from threats. These requirements are all stated
in terms of possibilities or options for users of the service to
require and utilize. Hence they are requirements for the availability
of functionality, but 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, and there is no intention here to prevent
them from building more secure servers with more secure protocols to
suit their needs. These are intended to satisfy the needs of the
general public.
[R14] It must be possible to create authoritative versions of a hint In summary, security and privacy rubrics can be identified as some
degree of protection from threats. These rubrics are all stated in
terms of possibilities or options for users of the service to require
and utilize. Hence they address the availability of functionality, but
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,
and there is no intention here to prevent the building of more secure
servers with more secure protocols to suit their needs. These are
intended to satisfy the needs of the general public.
R3.1) It must be possible to create authoritative versions of a hint
with access-to-modification privileges controlled; with access-to-modification privileges controlled;
[R15] It must be possible to determine the identity of servers or avoid R3.2) It must be possible to determine the identity of servers or
contact with unauthenticated servers; avoid contact with unauthenticated servers;
[R16] It must be possible to reduce the threat of denial of service R3.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
- 11 -
[R17] It must be possible within the bounds of organization policy
criteria to provide at least some degree of privacy for criteria to provide at least some degree of privacy for
traffic. traffic.
[R18] It must be possible for publishers to keep private certain R3.5) It must be possible for publishers to keep private certain
information such as an overall picture of the resources they are information such as an overall picture of the resources they
publishing and the identity of their clients; are publishing and the identity of their clients;
[R19] It must be possible for publishers to be able to restrict R3.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 When one discusses security, one of the primary issues is an enumeration
enumeration of the threats being considered for mitigation. The of the threats being considered for mitigation. The tradeoffs often
tradeoffs often include cost in money and computational and
communications resources, ease of use, likelihood of use, and
effectiveness of the mechanisms 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 - 12 -
[VK83]. They identify unauthorized release of information as a
passive attack, and all three of unauthorized modification of
information, denial of service, and spurious association initiation as
active attacks. An intruder at any protocol layer can attack at any
of the links or computational elements (hosts, routers, etc.) at that
layer. Attacks at one layer can be achieved by subverting or
attacking the lower layers. An unauthorized release of information is
a violation of privacy or confidentiality. This may be achieved by a
release of the information itself. Additional passive threats are
from secondary information through traffic analysis or other
violations of transmission security, such as noticing lengths and/or
sources and destinations of traffic. Moving to the active threats,
unauthorized modification of information can be partitioned into
problems with authenticity, integrity and ordering. Denial of service
may take the form of discarding information before it reaches its
destination or some degree of delay in delivering information.
Finally, spurious association may occur when a previous legitimate
association initiation is played back or an initiation is made under
false identity. Security measures may take the form of either
detection or prevention of each of these threats. Within the scope of
this work, we must identify those threats that are both of concern and
that we expect to be able to mediate. Of these threats the prevention
of passive attacks is known to be a particularly difficult problem to
address in the general case.
Of these threats, the passive threats to privacy or confidentiality include cost in money and computational and communications resources,
and the active threats of authenticity and integrity are probably the ease of use, likelihood of use, and effectiveness of the mechanisms
most important to consider here. To the extent that spurious proposed. With this in mind, let us consider a set of threats.
association causes threats to the privacy, authenticity, or integrity
with respect to information within servers managing data, it is also
important. Because updates to hint information are idempotent, at
least with short periods of time, we will set aside the problems of
ordering for this analysis. Denial of service is probably the most
difficult of these areas of threats both to detect and to prevent, and
we will therefore set it aside for the present as well, although it
will be seen that solutions to other problems will also mitigate some
of the problems of denial of service. Furthermore, because this is
- 12 - A good place to begin is with the early work of Voydock and Kent [VK83].
They identify unauthorized release of information as a passive attack.
On the other hand, unauthorized modification of information, denial of
service, and spurious association initiation are labelled as active
attacks. An intruder at any protocol layer can attack at any of the
links or computational elements (hosts, routers, etc.) at that layer.
Attacks at one layer can be achieved by subverting or attacking the
lower layers. An unauthorized release of information is a violation of
privacy or confidentiality. This may be achieved by a release of the
information itself. Additional passive threats are from secondary
information through traffic analysis or other violations of transmission
security, such as noticing lengths and/or sources and destinations of
traffic. Moving to the active threats, unauthorized modification of
information can be partitioned into problems with authenticity,
integrity and ordering. Denial of service may take the form of
discarding information before it reaches its destination or some degree
of delay in delivering information. Finally, spurious association may
occur when a previous legitimate association initiation is played back
or an initiation is made under false identity. Security measures may
take the form of either detection or prevention of each of these
threats. Within the scope of this work, we must identify those threats
that are both of concern and that we expect to be able to mediate.
intended to be provide a global service to meet the needs of a variety Of these threats, the passive threats to privacy or confidentiality and
of communities, the engineering tradeoffs will be different for the active threats of authenticity and integrity are probably the most
different clients. Hence the requirements are stated in terms of, important to consider here. To the extent that spurious association
"It must be possible..." It is important to note that the causes threats to the privacy, authenticity, or integrity with respect
information of concern here is hint information, which by nature is to information within servers managing data, it is also important.
not guaranteed to be correct or up-to-date; therefore, it is unlikely Because updates to hint information are idempotent, at least within
to be worth putting too much expense into the correctness of hints, short periods of time, we will set aside the problems of ordering for
because there is no guarantee that they are still correct anyway. But this analysis. Denial of service is probably the most difficult of
the exact choice of degree of privacy, authenticity, and integrity these areas of threats both to detect and to prevent, and we will
must be determined by the needs of the client and the availability of therefore set it aside for the present as well, although it will be seen
services from the server. 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
up-to-date; therefore, it is unlikely to be worth putting too much
expense into the correctness of hints, because there is no guarantee
that they are still correct anyway. But the exact choice of degree of
privacy, authenticity, and integrity must be determined by the needs of
the client and the availability of services from the server.
To avoid confusion it is valuable to highlight the meanings of temrs
that have different meanings in other contexts. In this case, the term
"authoritative" as it is used here connotes the taking of an action or
stamp of approval by a principal (again in the security sense) that has
the right to perform such an act of approval. It has no implication of
correctness of information, but only perhaps an implication of who
- 13 -
claimed it to be correct. In contrast, the term is often also used
simply to refer to a primary copy of a piece of information for which
there may also be secondary or cached copies available. In this
discussion of security we use the former meaning, 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.
It is also important to distinguish various possible meanings for
"access control." There are two areas in which distinctions can be
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
access, read and modify access, or read with verification for
authenticity. Second, there is the question of to what access is being
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
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
(unrelated to naming or name resolution at all). We attempt to be clear
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 between mechanism and policy. In general, a policy is realized by means
means of a set of mechanisms. In the case of an RDS there may be of a set of mechanisms. In the case of an RDS there may be policies
policies internal to the RDS that it needs to have supported in order internal to the RDS that it needs to have supported in order to do its
to do its business as it sees fit. Since, in general it is in the business as it sees fit. Since, in general it is in the business of
business of storing and distributing information, most of its security storing and distributing information, most of its security policies may
policies may have to do with maintaining its own integrity, and are have to do with maintaining its own integrity, and are rather limited.
rather limited. Beyond that, to the degree possible, it should impose Beyond that, to the degree possible, it should impose no policy on its
no policy on its customers, the publishers and users. It is they that customers, the publishers and users. It is they that may have policies
may have policies that they would like supported by the RDS. To that that they would like supported by the RDS. To that end, an RDS should
end, an RDS should provide a spectrum of "tools" or mechanisms that provide a spectrum of "tools" or mechanisms that the customers can cause
the customers can cause to be deployed on their behalf to realize to be deployed on their behalf to realize policies. An RDS may not
policies. An RDS may not provide all that is needed by a customer. A provide all that is needed by a customer. A customer may have different
customer may have different requirements within his or her requirements within his or her administrative bounds than outside.
administrative bounds than outside. Thus, "it must be possible..." Thus, "it must be possible..." captures the idea that the RDS must
captures the idea that the RDS must generally provide the tools to generally provide the tools to implement policies as needed by the
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 be as widely
distributed to what is considered to be local for every locale. The distributed to what is considered to be local for every locale. The
drawback of such wide distribution is the wide distribution of drawback of such wide distribution is the wide distribution of updates,
updates, causing network traffic problems or delays in delivering causing network traffic problems or delays in delivering updates. An
updates. An alternative model would concentrate hint information in alternative model would concentrate hint information in servers, thus
servers, thus requiring that update information only be distributed to requiring that update information only be distributed to these servers.
these servers. In such a model the vulnerable points are the sources In such a model the vulnerable points are the sources of the information
of the information and the distribution network among them. Attackers and the distribution network among them. Attackers on the integrity of
on the integrity of the information stored in a server may come in the the information stored in a server may come in the form of other a fake
form of other a fake owner of the information or a fake server to the owner of the information or a fake server to the extent that servers
extent that servers exchange updates with each other. Wide exchange updates with each other. Wide replication of information among
replication of information among servers increases the difficult of servers increases the difficult of masquerading at all the locations 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 goals for our security model:
- 14 -
* 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 made by those principals are or whether they are unlimited must be should by
the publisher of a hint. the publisher of a hint.
- 13 -
* SERVER AUTHENTICITY: Servers and clients must be able to learn the * SERVER AUTHENTICITY: Servers and clients must be able to learn the
identity of the servers with which they communicate. This will be a identity of the servers with which they communicate. This will be a
matter of degree and it is possible that there will be more matter of degree and it is possible that there will be more
trustworthy, but less accessible servers, supported by a larger trustworthy, but less accessible servers, supported by a larger
cluster of less authenticatable servers that are more widely cluster of less authenticatable servers that are more widely
available. In the worst case, if the client receives what appears to available. In the worst case, if the client receives what appears to
be 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
more reliable but less accessible data. more reliable but less accessible sources.
* 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 is a more difficult problem to address. It may be a
double-edged sword; for example, an organization may consider it double-edged sword; for example, an organization may consider it
critically important that its competitors not be able to read its critically important that its competitors not be able to read its
traffic, while it may also consider it important to be able to monitor traffic, while it may also consider it important to be able to monitor
exactly what its employees are transmitting to and from whom, for a exactly what its employees are transmitting to and from whom, for a
variety of reasons such as reducing the probability that its employees variety of reasons such as reducing the probability that its employees
are giving or selling the company's secrets to verifying that are giving or selling the company's secrets to verifying that employees
employees are not using company resources for private endeavor. Thus, are not using company resources for private endeavor. Thus, although
although there are likely to be needs for privacy and confidentiality, there are likely to be needs for privacy and confidentiality, what they
what they are, who controls them and how, and by what mechanisms vary are, who controls them and how, and by what mechanisms vary widely
widely enough that it is difficult to say anything concrete about them enough that it is difficult to say anything concrete about them here.
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 trying to publish something, in general privacy is probably not desired.
desired. However, publishers do have information that they might like However, publishers do have information that they might like to keep
to keep private: information about who their clients are, and private: information about who their clients are, and information about
information about what names exist in their namespace. The what names exist in their namespace. The information about who their
information about who their clients are may be difficult to collect clients are may be difficult to collect depending on the implementation
depending on the implementation of the resolution system. For of the resolution system. For example, if the resolution information
example, if the resolution information relating to a given publisher relating to a given publisher is widely replicated, the hits to _each_
is widely replicated, the hits to _each_ replicated copy will need to replicated copy would need to be recorded. Of course, determining if a
be recorded. Of course, determining if a specific client is specific client is requesting a given name can be approached from the
requesting a given name can be approached from the other direction, by other direction, by watching the client as we saw above.
watching the client as we saw above.
The other privacy issue for publishers has to do with access control The other privacy issue for publishers has to do with access control
over URN resolution. This issue is dependent on the implementation of over URN resolution. This issue is dependent on the implementation of
the publisher's authoritative URN resolver server. URN resolver the publisher's authoritative (in the sense of "primary) URN resolver
servers can be designed to require proof of identity in order to be server. URN resolver servers can be designed to require proof of
issued resolution information; if the client does not have permission identity in order to be issued resolution information; if the client
to access the URN requested, the service denies that such a URN does not have permission to access the URN requested, the service denies
exists. An encrypted protocol can also be used so that both the
request and the response are obscured. Encryption is possible in this
- 14 - - 15 -
case because the identity of the final recipient is known (i.e. the that such a URN exists. An encrypted protocol can also be used so that
URN server). 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.
the URN server). Thus, access control over URN resolution can and
should be provided by resolver servers rather than an RDS.
4. The Framework 4. The Framework
With these assumptions and requirements in mind, one can conclude with a With these assumptions and guidelines in mind, we can conclude with a
general framework within which RDS designs will fall. As stated general framework within which RDS designs can fall. As stated earlier,
earlier, although this framework is put forth as a suggested guide for although this framework is put forth as a suggested guide for RDS
RDS designers, compliance with it will in no way guarantee compliance designers, compliance with it will in no way guarantee compliance with
with the requirements. Such an evaluation must be performed separately. the rubrics. Such an evaluation must be performed separately. It is
It is also understood that there may be RDS services that do not meet also understood that there may be RDS services that do not meet the
the requirements in clearly identified ways. This may be true guidelines in clearly identified ways. This may be true especially with
especially with early plans and experiments. For example, although a early plans and experiments. For example, although a careful threat
careful threat analysis may have been done to understand security analysis may have been done to understand security requirements, not all
requirements, not all those security requirements may be addressed, in those security issues may be addressed, in order to use existing
order to use existing facilities to allow for early deployment for facilities to allow for early deployment for experimentation purposes.
experimentation purposes. All such lack of compliance should be clearly All such lack of compliance should be clearly documented.
documented.
The design of the framework is based on a simple assumption about the The design of the framework is based on a simple assumption about the
syntax of a URN a documented in RFC-XXX[RFCXXX}. This assumed syntax syntax of a URN a documented in RFC-2141[RFC2141]. This assumed syntax
is: is:
URN:<NID>:<NSS> URN:<NID>:<NSS>
where URN: is a prefix on all URNs, NID is the namespace identifier, where URN: is a prefix on all URNs, NID is the namespace identifier, and
and NSS is the namespace specific string. The prefix identifies each NSS is the namespace specific string. The prefix identifies each URN as
URN as such. The NID determines the general syntax for all URNs such. The NID determines the general syntax for all URNs within its
within its namespace. The NSS is probably partitioned into a set of namespace. The NSS is probably partitioned into a set of delegated and
delegated and subdelegated namespaces, and this is probably reflected subdelegated namespaces, and this is probably reflected in further
in further syntax specifications. In more complex environments, each syntax specifications. In more complex environments, each delegated
delegated namespace will be permitted to choose the syntax of the namespace will be permitted to choose the syntax of the variable part of
variable part of the namespace that has been delegated to it. In the namespace that has been delegated to it. In simpler namespaces, the
simpler namespaces, the syntax will be restricted completely by the syntax will be restricted completely by the parent namespace. For
parent namespace. For example, although the DNS does not meet all the example, although the DNS does not meet all the requirements for URNs,
requirements for URNs, it has a completely restricted syntax, such it has a completely restricted syntax, such that any further structuring
that any further structuring must be done only by adding further must be done only by adding further refinements to the left, maintaining
refinements to the left, maintaining the high order to low order, the high order to low order, right to left structure. A delegated
right to left structure. A delegated syntax might be one in which a syntax might be one in which a host is named by the DNS, but to the
host is named by the DNS, but to the right of that and separated by an right of that and separated by an "@" is a string whose internal
"@" is a string whose internal ordering is defined by the file system ordering is defined by the file system on the host, which may be defined
on the host, which may be defined high order to low order, left to high order to low order, left to right. Of course, much more complex
right. Of course, much more complex and nested syntaxes should be and nested syntaxes should be possible, especially given the need to
possible, especially given the need to grandfather namespaces. In grandfather namespaces. In order to resolve URNs, rules will be needed
order to resolve URNs, rules will be needed for two reasons. One is for two reasons. One is simply to canonicalize those namespaces that do
simply to canonicalize those namespaces that do not fall into a not fall into a straightforward (probably right to left or left to
straightforward (probably right to left or left to right) ordering of right) ordering of the components of a URN, as determined by the
the components of a URN, as determined by the delegated naming delegated naming authorities involved. It is also possible that rules
authorities involved. It is also possible that rules will be needed will be needed in order to derive from URNs the names of RDS servers to
in order to derive from URNs the names of RDS servers to be used in be used in stages.
stages.
The NID defines a top level syntax. This syntax will determine The NID defines a top level syntax. This syntax will determine whether
whether the NID alone or in conjunction with some extraction from the the NID alone or in conjunction with some extraction from the NSS (for
NSS (for the top level naming authority name) is to be used to the top level naming authority name) is to be used to identify the first
- 15 - - 16 -
identify the first level server to be contacted. At each stage of the level server to be contacted. At each stage of the lookup either a new
lookup either a new rule for generating the strings used in yet rule for generating the strings used in yet another lookup (the strings
another lookup (the strings being the identity of another RDS server being the identity of another RDS server and possibly a string to be
and possibly a string to be resolved if it is different than the resolved if it is different than the original URN) or a reference
original URN) or a reference outside the RDS to a private URN outside the RDS to a URN resolver service, sidestepping any further use
resolver service, sidestepping any further use of the RDS scheme. of the RDS scheme. Figure 1 depicts this process.
Figure 1 depicts this process.
URN:<NID><NSS> URN:<NID><NSS>
| |
| |
| |
| |
v v
+-------------------+ +-------------------+
|Global NID registry| |Global NID registry|
+-------------------+ +-------------------+
skipping to change at line 899 skipping to change at line 973
| +----------+ | | +----------+ |
| | | v | | | v
| | | (set of choices) | | | (set of choices)
| | +----+----------(...)--------+ | | +----+----------(...)--------+
| (rule) | | | (rule) | |
| | | | | | | |
| | | | | | | |
+------+ | | +------+ | |
v v v v
+----------+ +----------+ +----------+ +----------+
|private | |private |
|URN | |URN | |URN | |URN |
|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 distribution and replication needed to support a particular RDS scheme.
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
- 16 - - 17 -
scheme. Second, it leaves open the location of the computations the name delegation. This may seem radical to some, but if the
engendered by the rules. Third, it leaves open the possibility that information is stored in balanced B-trees for example, the partitioning
partitioning (distribution) of the RDS database need not be on the may not be along those naming authority delegation boundaries (see
same boundaries as the name delegation. This may seem radical to [Sl97]). Lastly, it leaves open access to the Global NID Registry. Is
some, but if the information is stored in balanced B-trees for this distributed to every client, or managed in widely distributed
example, the partitioning may not be along those naming authority servers?
delegation boundaries. Lastly, it leaves open access to the Global
NID Registry. Is this distributed to every client, or managed in
widely distributed servers?
One concept that has not been addressed in Figure 1 is that there may One concept that has not been addressed in Figure 1 is that there may be
be more than one RDS available at any given time, in order to allow more than one RDS available at any given time, in order to allow for
for evolution to new schemes. Thus, the picture should probably look evolution to new schemes. Thus, the picture should probably look more
more like Figure 2. like Figure 2.
URN:<NID>:<NSS> URN:<NID>:<NSS>
| |
| |
+-----------+-------(...)-------+ +-----------+-------(...)-------+
| | | |
| | | |
| | | |
v v v v
+---------------------+ +---------------------+ +---------------------+ +---------------------+
skipping to change at line 950 skipping to change at line 1023
. . . .
. . . .
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 between them with respect to storage and
propagation of information and modifications. The issue is that propagation of information and modifications. The issue is that
generally it should be assumed that all information should be available generally it should be assumed that all information should be available
through any operational RDS scheme. One cannot expect potential through any operational RDS scheme. One cannot expect potential
publishers to submit updates to N RDS schemes. Hence there will need to publishers to submit updates to more than one RDS scheme. Hence there
be a straightforward mapping of information from one to the other of will need to be a straightforward mapping of information from one to the
these schemes. It is possible that that transformation will only go in other of these schemes. It is possible that that transformation will
one direction, because a newer RDS service is replacing an older one, only go in one direction, because a newer RDS service is replacing an
which is not kept up to date, in order to encourage transfer to the older one, which is not kept up to date, in order to encourage transfer
newer one. Thus, at some point, updates may be made only to the newer to the newer one. Thus, at some point, updates may be made only to the
one and not be made available to the older one. Such a situation should newer one and not be made available to the older one, as is often done
probably be avoided, if possible. with library catalogs.
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 reader that adherence to this framework will in no way
guarantee compliance with the requirements or even assumption
described in Sections 2 and 3. These must be reviewed independently
as part of the design process. There is no single correct design that
- 17 - 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
reader that adherence to this framework will in no way guarantee
compliance with the guidelines or even the assumptions described in
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
these guidelines. Furthermore, it is assumed that preliminary proposals
may not meet all the guidelines, but should be expected to itemized and
justify any lack of compliance.
will meet these requirements. Furthermore, it is assumed that - 18 -
preliminary proposals may not meet all the requirements, but should be
expected to itemized and justify any lack of compliance.
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 previous URN requirements document and for his insightful co-author on a preliminary URN requirements document and for his
comments on this version of the document. In addition, I recognize the insightful comments on this version of the document. In addition, I
contributors to a previous URN framework document, the "Knoxville" recognize the contributors to a previous URN framework document, the
group. There are too many of you to acknowledge here individually, but "Knoxville" group. There are too many of you to acknowledge here
thank you. Finally, I must thank the contributors to the URN working individually, but thank you. Finally, I must thank the contributors to
group mailing list (urn-ietf@bunyip.com), for their animated discussions the URN working group mailing list (urn-ietf@bunyip.com), for their
on these and related topics. animated discussions on these and related topics.
6. References 6. References
[RFC1736] Kunze, J., "Functional Recommendations for Internet Resource [RFC1736] Kunze, J., "Functional Recommendations for Internet Resource
Locators", RFC 1736, February, 1995. Locators", RFC 1736, February, 1995.
[RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for [RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for
Uniform Resource Names", RFC 1738, December, 1994. Uniform Resource Names", RFC 1738, December, 1994.
[RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform
Resource Locators (URL)", RFC 1738, December, 1994. Resource Locators (URL)", RFC 1738, December, 1994.
[RFCXXX] Moats, Ryan, "URN Syntax", currently available as [RFC2141] Moats, Ryan, "URN Syntax", RFC 2141, May 1997.
draft-ietf-urn-syntax-04.txt, March, 1997.
[Sl97] Slottow, E.G., "Engineering a Global Resolution Service,"
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/pdf-papers/tr712.pdf>.
[VK83] Voydock, V. L., and Kent, S. T., "Security Mechanisms in [VK83] 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 September 28, 1997. This Internet Draft expires on December 4, 1997.
- 18 - - 19 -
 End of changes. 94 change blocks. 
557 lines changed or deleted 633 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/