Subject: [URN] Three new I-Ds re. URL i18n
From: Martin J Duerst <[email-masked]>
To: [email-masked]
Date: Thu, 31 Jul 1997 15:49:58 +0200

Dear friends,

Yesterday I have submitted three Internet-drafts (deadlines
make me work :-) connected to the topic of internationalization
of internet identifiers. They should soon appear in the IETF
anouncements and on the respective ftp servers. You can already
obtain them as:

ftp://ftp.ifi.unizh.ch/outgoing/draft-duerst-dns-i18n-01.txt
ftp://ftp.ifi.unizh.ch/outgoing/draft-duerst-i18n-norm-00.txt
ftp://ftp.ifi.unizh.ch/outgoing/draft-duerst-query-i18n-00.txt

The first draft describes a method to internationalize DNS
easily without having to change the core DNS software in any
way. It is an update of a draft that expired a few weeks ago.
With enough consensus, this could go into experimental phase
rather quickly.

The second draft is an *initial attempt* at defining normalization
and additional guidelines for international identifiers. This
is necessary to eliminate bad user surprises, but does not have
very high priority as the normalization rules can be defined so
that most current systems and users anyway only produce already 
normalized identifiers.

The third draft contains material about the problem of internationalizing
the query component in URLs. This is a particularly important, but
also particularly tricky part of URL internationalization. The
draft describes a convention currently used by most browsers
(and working in many cases), and some additions to the HTTP
protocol (intended to be version-independent) for a safe upgrade
to UTF-8 URLs. The basic idea should be sound; the syntax and
terminology may need more work.

I am glad about any feedback directly back to me or on any of
the lists I am posting this information. I appologize to those
that get this information more than once. I will also be in
Munich and look forward to talk to anybody interested.
However, because most parties seriously interested in URL
internationalization (their number is steadily increasing :-)
have indicated that they won't be able to attend Munich,
I have unfortunately had to cancel a planned official meeting
(the specific topic of the meeting was that of the second draft
above). I hope that a meeting will become reality at a later
IETF. One occasion where there will certainly be a lot of
discussion about internationalized URLs, just because many
of the players happen to attend or be around, will be the
upcomming 11th International Unicode Conference in early
September in San Jose.

Regards,	Martin.

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-req-frame-03.txt
Date: Wed, 30 Jul 1997 09:36:49 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Uniform Resource Names 
 Working Group of the IETF.                                                

       Title     : Architectural Principles of Uniform Resource Name 
                   Resolution                                              
       Author(s) : K. Sollins
       Filename  : draft-ietf-urn-req-frame-03.txt
       Pages     : 18
       Date      : 07/29/1997

This document addresses the issues of the discovery of URN (Uniform 
Resource Name) resolver services that in turn will directly translate URNs 
into URLs (Uniform Resource Locators) and URCs (Uniform Resource 
Characteristics).  The document falls into three major parts, the 
assumptions underlying the work, the guidelines in order to be a viable 
Resolver Discovery Service or RDS, and a framework for designing RDSs.  The
guidelines fall into three principle areas:  evolvability, usability, and 
security and privacy.  An RDS that is compliant with the framework will not
necessarily be compliant with the guidelines.  Compliance with the 
guidelines will need to be validated separately.                           

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-urn-req-frame-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-03.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-urn-req-frame-03.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-req-frame-03.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-urn-req-frame-03.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 29 Jul 1997 23:27:57 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Terry Allen <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] Re std-, prv-
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Mon, 28 Jul 1997, Terry Allen wrote:
> | > connotations. How about something like "r<digits>-", where the
> | > R stands for "registered" and the digits let us deal with multiple
> | > requests for a particular namespace ID? The ever-popular "foo"
> | > NID would have r1-foo, r2-foo, r3-foo, etc.   
> | 
> | And would the "r" number be dropped for namespaces that had gone through
> | the full standardization process?
> 
> Either way I'm confused.  Do we need to do this?  Why?  I didn't find
> a clear reason in the straw proposal.

Sheer number of expected namespaces.  We aren't (yet?) ready to codify
an objective checklist for the IANA to independently approve the technical
merit of all of them, let alone potential legal implications of who
can/cannot have a namespace.  So, the proposal is to split the problem:
there will be those that have been given detailed scrutiny by the IETF
(through RFC path, at least initially), and those that spring into
existence, perhaps initially for private consumption and then more
public.  This is an approach with a precident:  registering MIME types
(I am told) includes a "vnd" subtree of the naming in which individual
vendors are free to do what they want.

In order to be globally accessible, all namespaces must have some registration
in the global NID, so there will be (I expect) IETF-standardized ones
registered there, as well as less formally-standardized ones.

> How about, standardized name space IDs are those registered in the
> appropriate registry, and all others are nonstandardized?

First of all, this isn't by default the global NID registry for the
reasons above -- the definition of that would have to change to include
something like a "standardize/not standardized" flag.

Or, it could be a separate registry of standardized names, although
my gut reaction is that this starts to be a field of blooming registries...

In general, personally,  I prefer to have things immediately and objectively
identifiable -- if you (or your software) is dealling with an "R-??"
namespace, it implicitly makes a statement about the effort the
namespace owner has made to standardize and preserve the namespace.
(No, it's not a hard and fast rule -- we've already agreed there
are things we simply cannot enforce).

Cheers!
Leslie.

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Mon, 28 Jul 1997 18:16:26 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] RDS guidelines (includes new draft)
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Hi All,

I have just sent off a new draft of the RDS guidelines document.  For
this round of updates and corrections, thanks go to Ron Daniel, Leslie
Daigle, and Dan La Liberte.  We have Leslie to thank for a new title
and a variety of comments on the content.  Ron made numerous
suggestions for shortening the document.  I took them to heart, but
discovered that in some cases, his suggestions illuminated the fact
that something needed more explanation not less:-)  Dan asked that I
revisit some older comments of his that he felt had not had
appropriate attention.  I did - and again some of them illuminated
either problems or places where further explanation was needed.  In
the end it _is_ a little shorter and definitely more tightened up.
Experience with RFC 1737 and the possibilities for misunderstandings
and misinterpretations have led me to believe that full explanations of
choices and decisions are extremely valuable in order to avoid
creative new interpretations that were not intended.

Overall the document has not changed a great deal.  Given that only 3
people had comments, in this last round, I hope we are finally
reaching consensus.  Clearly, send interesting comments to the mailing
list, and minor editorial ones directly to me.

I have one extremely minor question: is this long enough that anyone
feels it merits a toc?

			Karen

______________________________

Internet Draft                                          Karen R. Sollins
draft-ietf-urn-req-frame-03.txt                                  MIT/LCS
Expires January 30, 1998                                   July 30, 1997

       Architectural Principles of Uniform Resource Name Resolution

Status of this draft
     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Abstract:

This document addresses the issues of the discovery of URN (Uniform
Resource Name) resolver services that in turn will directly translate
URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource
Characteristics).  The document falls into three major parts, the
assumptions underlying the work, the guidelines in order to be a
viable Resolver Discovery Service or RDS, and a framework for
designing RDSs.  The guidelines fall into three principle areas:
evolvability, usability, and security and privacy.  An RDS that is
compliant with the framework will not necessarily be compliant with
the guidelines.  Compliance with the guidelines will need to be
validated separately.

1. Introduction

The purpose of this document is to lay out the engineering criteria
for what we will call here a Resolver Discovery Service (RDS), a
service to help in the learning about URN (Uniform Resource Name)
resolvers.  The term "resolver" is used in this document to indicate a
service that translates URNs to URLs (Uniform Resource Locators) or
URCs (Uniform Resource Characteristics).  Some resolvers may provide
direct access to resources as well.  An RDS helps in finding a
resolver to contact for further resolution.  It is worth noting that
some RDS designs may also incorporate resolver functionality.  This
function of URN resolution is a component of the realization of an
information infrastructure.  In the case of this work, that
infrastructure is to be available, "in the Internet" or globally, and
hence the solutions to the problems we are addressing must be globally

                                 - 1 -

scalable.  In this document, we are focussing specifically on the
design of RDS schemes.

The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736[1],
1737[2], and 1738[3].  Although several further documents are needed
to complete the description of that architecture, it incorporates
three core functions often associated with "naming": identification,
location, and mnemonics or semantics.  By location, we mean
fully-qualified Domain Names or IP addresses, possibly extended with
TCP ports and/or local identifiers, such as pathnames.  Names may
provide the ability to distinguish one resource from another, by
distinguishing their "names".  Names may help to provide access to a
resource by including "location" information.  Lastly, names may have
other semantic or mnemonic information that either helps human users
remember or figure out the names, or include other semantic
information about the resource being named.  The URI working group
concluded that there was need for persistent, globally unique
identifiers, distinct from location or other semantic information;
these were called URNs.  These "names" provide identity, in that if
two of them are "the same" (under some simple rule of
canonicalization), they identify the same resource.  Furthermore, the
group decided that these "names" were generally to be for machine,
rather than human, consumption.

In contrast to URNs, one can imagine a variety human-friendly naming
(HFN) schemes supporting different suites of applications and user
communities.  These will need to provide mappings to URNs in tighter
or looser couplings, depending on the namespace.  It is these HFNs
that will be mnemonic, content-full, and perhaps mutable, to track
changes in use and semantics.  They may provide nicknaming and other
aliasing, relative or short names, context sensitive names,
descriptive names, etc.  Their definition is not part of this effort,
but will clearly play an important role in the long run.

URNs as described in RFC 1737 are defined globally; they are
ubiquitous in that a URN anywhere in any context identifies the same
resource.  Given this requirement on URNs, one must ask about its
implication for an RDS.  Does ubiquity imply a guarantee of RDS
resolution everywhere?  Does ubiquity imply resolution to the same
information about resolution everywhere?  In both cases the answer is
probably not.  One cannot make global, systemic guarantees, except at
an expense beyond reason.  In addition there may be policy reasons for
not resolving in the same way everywhere.  It is quite possible that
the resolution of a URN to an instance of a resource may reach
different instances or copies under different conditions.  Thus,
although a URN anywhere refers to the same resource, in some
environments under some conditions, and at different times, due to
either the vagaries of network conditions or policy controls a URN may
sometimes be resolvable and other times or places not.  Ubiquitous
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
for lack of a better term we will call a _hint_.  A hint is something

                                 - 2 -

that helps in the resolution of a URN; in theory we map URNs to hints
as an interim stage in accessing a resource.  In practice, an RDS may
map a URN directly into the resource itself if it chooses to.  It is
very likely that there will be hints that are applicable to large sets
of URNs, for example, a hint that indicates that all URNs with a
certain prefix or suffix can be resolved by a particular resolver.  A
hint may also have meta-information associated with it, such as an
expiration_time or certification of authenticity.  We expect that
these will stay with a hint rather than being managed elsewhere.  We
will assume in all further discussion of hints that they include any
necessary meta-information as well as the hint information itself.
Examples of hints are: 1) the URN of a resolver service that may
further resolve the URN, 2) the address of such a service, 3) a
location at which the resource was previously 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 or cache
a set of hints for each URN at each location where that URN is found.
These may have been acquired from the owner of the resources, a
recommendation of the resource, or one of many other sources.  In
addition, for those situations in which those hints found locally
fail, a well engineered system will provide a fall-back mechanism for
discovering further hints.  It is this fall-back mechanism, an RDS,
that is being addressed in this document.  As with all hints, there
can never be a guarantee that access to a resource will be available
to all clients, even if the resource is accessible to some.  However,
an RDS is expected to work with reasonably high reliability, and,
hence, may result in increased response time.

The remainder of this document falls into three sections.  The first
identifies several sets of assumptions underlying this work.  There are
three general assumptions:
   * URNs are persistent;
   * URN assignment can be delegated;
   * Decisions can be made independently, enabling isolation from decisions 
     of one's peers.

The next section lays out three central principles Resolver Discovery
Service design.  For each of these, we have identified a number of
more specific guidelines that further define and refine the general
principle.  This section is probably the most critical of the
document, because one must hold any proposed RDS scheme up against
these principles and corollary guidelines to learn whether or not it
is adequate.  The three central principles can be summarized as:
   1) An RDS must allow for evolution and evolvability;
   2) Usability of an RDS with regard to each of the sets of constituents 
       involved in the identification and location or resources is paramount;

                                 - 3 -

   3) It is centrally important that the security and privacy needs of all 
       constituents be feasibly supported, to the degree possible.
Each of the three major subsections of the guidelines section begins
with a summary list of the more detailed guidelines identified in that
section.

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.  The RDS designer should be aware that meeting the guidelines
is of primary importance; it is possible to meet them without
conforming to the framework.  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

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
apparent: longevity, delegation, and independence.  Each will be
discussed separately.

The URN requirements[2] state that a URN is to be a "persistent
identifier".  It is probably the case that nothing will last forever,
but in the time frame of resources, users of those resources, and the
systems to support the resources, the identifier should be considered
to be persistent or have a longer lifetime than those other entities.
There are two assumptions that are implied by longevity of URNs:
mobility and evolution.  Mobility will occur because resources may
move from one machine to another, owners of resources may move among
organizations, or the organizations themselves may merge, partition,
or otherwise transforms themselves.  The Internet is continually
evolving; protocols are being revised, new ones created, while
security policies and mechanisms evolve as well.  These are only
examples.  In general, we must assume that almost any piece of the
supporting infrastructure of URN resolution will evolve.  In order to
deal with both the mobility and evolution assumptions that derive from
the assumption of longevity, we must assume that users and their
applications can remain independent of these mutating details of the
supporting infrastructure.

The second assumption is that naming and resolution authorities may
delegate some of their authority or responsibility; in both cases, the
delegation of such authority is the only known method of allowing for
the kind of scaling expected.  It is important to note that a
significant feature of this work is the potential to separate name
assignment, the job of labelling a resource with a URN, from name
resolution, the job of discovering the resource given the URN.  In
both cases, we expect multi-tiered delegation.  There may be RDS
schemes that merge these two sets of responsibilities and delegation
relationships; by doing so, they bind together or overload two
distinctly different activities, thus probably impeding growth.

The third assumption is independence or isolation of one authority
from another and, at least to some extent, from its parent.  When one
authority delegates some of its rights and responsibilities to another

                                 - 4 -

authority, the delegatee can operate in that domain independently of
its peers and within bounds specified by the delegation, independently
of the delegator.  This isolation is critically important in order to
allow for independence of policy and mechanism.

This third assumption has several corollaries.  First, we assume that
the publisher of a resource can choose resolver services,
independently of choices made by others.  At any given time, the owner
of a namespace may choose a particular URN resolver service for that
delegated namespace.  Such a URN resolver service may be outside the
RDS service model, and only identified or located by the RDS service.
Second, it must be possible to make a choice among RDS services.  The
existence of multiple RDS services may arise from the evolution of an
RDS service, or development of new ones.  Although at any given time
there is likely to be only one or a small set of such services, the
number is likely to increase during a transition period from one
architecture to another.  Thus, it must be assumed that clients can
make a choice among a probably very small set of RDSs.  Third, there
must be independence in the choice about levels and models of security
and authenticity required.  This choice may be made by the owner of a
naming subspace, in controlling who can modify hints in that subspace.
A naming authority may delegate this choice to the owners of the
resources named by the names it has assigned.  There may be
limitations on this freedom of choice in order to allow other
participants to have the level of security and authenticity they
require, for example, in order to maintain the integrity of the RDS
infrastructure as a whole.  Fourth, there is an assumption of
independence of choice of the rule of canonicalization of URNs within
a namespace, limited by any restrictions or constraints that may have
been set by its parent namespace.  This is a choice held by naming
authorities over their own subnamespaces.  Rules for canonicalization
will be discussed further in the framework section below.  Thus, there
are assumptions of independence and isolation to allow for delegated,
independent authority in a variety of domains.

The modularity assumptions of delegation and isolation imply
independence of decision and implementation, leading to a
decentralization that provides a certain degree of safety from denial
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, we can now turn to the guidelines for an RDS.

3. Guidelines

The guidelines applying to an RDS center around three important design
principles in the areas of evolvability, usability, 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 hints may range in
applicability from local to global, and from short-lived to
long-lived.  They also may vary in their degree of verifiable
authenticity.  While it may be neither feasible nor necessary that
initial implementations support every guideline, every implementation
must support evolution to systems that do support the guideline more
fully.

                                 - 5 -

It is important to note that there are requirements, not applicable
specifically to an RDS that must also be met.  A whole URN system will
consist of names in namespaces, the resolution information for them,
and the mapping from names in the namespaces to resolution information
(or hints).  URNs themselves must meet the requirements of RFC 1737.
In addition, namespaces themselves must meet certain requirements as
described in RFC NNNN[5].  Although all these requirements and
guidelines are not described here, they must be supported to provide
an acceptable system.

Each section below begins with a summary of the points made in that
section.  There is some degree of overlap among the areas, such as in
allowing for the evolution of security mechanisms, etc., and hence
issues may be addressed in more than one section.  It is also
important to recognize that conformance with the guidelines will often
be subjective.  As with most IETF guidelines and requirements, most of
these are not quantifiable and hence conformance is a judgment call
and a matter of degree.  Lastly, the reader may find that some of them
are those of general applicability to distributed systems and some are
specific to URN resolution.  Those of general applicability are
included for completeness and are not distinguished as such.

3.1 Evolution

The issues in the area of the first principle, that of evolvability,
are:

    1.1) An RDS must be able to support scaling in at least three
         dimensions: the number of resources for which URNs will be
         required, the number of publishers and users of those
         resources, and the complexity of the delegation, as authority
         for resolution grows and possibly reflects delegation in
         naming authority;
    1.2) A hint resolution environment must support evolution of 
         mechanisms, specifically for:
         * a growing set of URN schemes;
         * new kinds local URN resolver services;
         * new authentication schemes;
         * alternative RDS schemes active simultaneously;
    1.3) An RDS must allow the development and deployment 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
development of mechanisms for resolving URNs is that we must be prepared
for change.  Such changes may happen slowly enough to be considered
evolutionary modifications of existing services, or dramatically enough
to be considered revolutionary.  They may permeate the Internet universe
bit by bit, living side by side with earlier services or they may take
the Internet by storm, causing an apparent complete transformation over
a short period of time.  There are several directions in which we can
predict the need for evolution.  At the very least, the community and
the mechanisms proposed should be prepared for these.

First, scaling is a primary issue in conjunction with evolution.  The
number of users, both human and electronic, as well as the number of

                                 - 6 -

resources will continue to grow exponentially for the near term, at
least.  Hence the number of URNs will also increase similarly.  In
addition, with growth in sheer numbers is likely to come growth in the
delegation of both naming authority and resolution authority.  These
facts mean that an RDS design must be prepared to handle increasing
numbers of requests for inclusion, update and resolution, in a set of
RDS servers perhaps inter-related in more complex ways.  This is not
to say that there will necessarily be more updates or resolutions per
URN; we cannot predict that at this time.  But, even so, the
infrastructure may become more complex due to delegation, which may
(as can be seen in Section 4 on the framework) lead to more complex
rules for rewriting or extracting terms for staged resolution.  Any
design is likely to perform less well above some set of limits, so it
is worth considering the growth limitations of each design
alternative.

Second, we expect there to be additions and changes to the mechanisms.
The community already understands that there must be a capacity for
new URN schemes, as described in [5].  A URN scheme will define a set
of URNs that meet the URN requirements[2], but may have further
constraints on the internal structure of the URN. The intention is
that URN schemes can be free to specify parts of the URN that are left
opaque in the larger picture.  In fact, a URN scheme may choose to
make public or keep private the algorithms for any such "opaque" part
of the URN.  In any case, we must be prepared for a growing number of
URN schemes.

Often in conjunction with a new URN scheme, but possibly independently
of any particular URN scheme, new kinds of resolver services may
evolve.  For example, one can imagine a specialized resolver service
based on the particular structure of ISBNs that improves the
efficiency of finding documents given their ISBNs.  Alternatively, one
can also imagine a general purpose resolver service that trades
performance for generality; although it exhibits only average
performance resolving ISBNs, it makes up for this weakness by
understanding all existing URN schemes, so that its clients can use
the same service to resolve URNs regardless of naming scheme.  In this
context, there will always be room for improvement of services,
through improved performance, better adaptability to new URN schemes,
or lower cost, for example.  New models for URN resolution will evolve
and we must be prepared to allow for their participation in the
overall resolution of URNs.

If we begin with one overall plan for URN resolution, into which the
enhancements described above may fit, we must also be prepared for an
evolution in the authentication schemes that will be considered either
useful or necessary in the future.  There is no single globally
accepted authentication scheme, and there may never be one.  Even if
one does exist at some point in time, we must always be prepared to
move on to newer and better schemes, as the old ones become too easily
spoofed or guessed.

In terms of mechanism, although we may develop and deploy a single RDS
scheme initially, we must be prepared for that top level model to
evolve.  Thus, if the RDS model supports an apparently centralized
(from a policy standpoint) scheme for inserting and modifying

                                 - 7 -

authoritative information, over time we must be prepared to evolve to
a different model, perhaps one that has a more distributed model of
authority and authenticity.  If the model has no core but rather a
cascaded partial discovery of information, we may find that this
becomes unmanageable with an increase in scaling.  Whatever the model,
we must be prepared for it to evolve with changes in scaling,
performance, and policy constraints such as security and cost.

The third evolutionary issue is even more mechanical than the others.
At any point in time, the community is likely to be supporting a
compromise position with respect to resolution.  We will probably be
operating in a situation balanced between feasibility and the ideal,
perhaps with policy controls used to help stabilize use of the
service.  Ideally, the service would be providing exactly what the
customers wanted and they in turn would not request more support than
they need, but it seems extremely unlikely.  Since we will almost
always be in a situation in which some service provision resources
will be in short supply, some form of policy controls will generally
be necessary.  Some policy controls may be realized as mechanisms
within the servers or in the details of protocols, while others may
only be realized externally to the system.  For example, suppose hint
entries are being submitted in such volume that the hint servers are
using up their excess capacity and need more disk space.  Two
suggestions for policy control are pricing and administrative.  As
technology changes and the balance of which resources are in short
supply changes, the mechanisms and policies for controlling their use
must evolve as well.

3.2 Usability

To summarize, the usability guidelines fall into three areas based on
participation in hint management and discovery:

    2.1) The publisher
       2.1.1) URN to hint resolution must be correct and efficient with
              very high probability;
       2.1.2) Publishers must be able to select and move among URN 
              resolver services to locate their resources;
       2.1.3) Publishers must be able to arrange for multiple access
              points for their location information;
       2.1.4) Publishers should be able to provide hints with varying
              lifetimes;
       2.1.5) It must be relatively easy for publishers to specify to
              the management and observe their hint information as well
              as any security constraints they need for their hints.
    2.2) The client
       2.2.1) The interface to the RDS must be simple, effective, and
              efficient;
       2.2.2) The client and client applications must be able to
              understand the information stored in and provided by the
              RDS easily, in order to be able to make informed choices.
    2.3) The management
       2.3.1) The management of hints must be as unobtrusive as
              possible, avoiding using too many network resources;
       2.3.2) The management of hints must allow for administrative
              controls that encourage certain sorts of behavior deemed

                                 - 8 -

              necessary to meet other requirements;
       2.3.3) The configuration and verification of configuration of
              individual RDS servers must be simple enough not to
              discourage configuration and verification.

Usability can be evaluated from three distinct perspectives: those of a
publisher wishing to make a piece of information public, those of a
client requesting URN resolution, and those of the provider or manager
of resolution information.  We will separately address the usability
issues from each of these three perspectives.

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
naming authorities which choose and assign names, and the authors who
include URNs in their resources.  These two are not relevant to the
design of an RDS and hence are not discussed further here.

3.2.1 The Publisher

The publisher must be able to make URNs known to potential customers.
>From the perspective of a publisher, it is of primary importance that
URNs be correctly and efficiently resolvable by potential clients with
very high probability.  Publishers stand to gain from long-lived URNs,
since they increase the chance that references continue to point to
their published resources.

The publisher must also be able to choose easily among a variety of
potential services that might translate URNs to location information.
In order to allow for this mobility among resolvers, the RDS
architecture must support such transitions, within policy control
bounds.  It is worth noting that although multiple listing services
are available in telephone books, they are generally accompanied by a
fee.  There is nothing preventing there being fees collected for
similar sorts of services with respect to URNs.

The publisher must be able to arrange for multiple access points to a
published resource.  For this to be useful, resolver services should
be prepared to provide different resolution or hint information to
different clients, based on a variety of information including
location and the various access privileges the client might have.  It
is important to note that this may have serious implications for
caching this information.  For example, companies might arrange for
locally replicated copies of popular resources, and would like to
provide access to the local copies only for their own employees.  This
is distinct from access control on the resource as a whole, and may be
applied differently to different copies.

The publisher should be able to provide both long and short term
location information about accessing the resource.  Long term
information is likely to be such information as the long term address
of a resource itself or the location or identity of a resolver service
with which the publisher has a long term relationship.  One can
imagine that the arrangement with such a long term "authoritative"
resolver service might be a guarantee of reliability, resiliency to
failure, and atomic updates.  Shorter term information is useful for
short term changes in services or to avoid short lived congestion or

                                 - 9 -

failure problems.  For example, if the actual repository of the
resource is temporarily inaccessible, the resource might be made
available from another repository.  This short term information can be
viewed as temporary refinements of the longer term information, and as
such should be more easily and quickly made available, but may be less
reliable.  Some RDS designs may not distinguish between these two
extremes.

Lastly, the publishers will be the source of much hint information
that will be stored and served by the manager of the infrastructure.
Despite the fact that many publishers will not understand the details
of the RDS mechanism, it must be easy and straightforward for them to
install hint information.  This means that in general any one who
wishes to publish and to whom the privilege of resolution has been
extended through delegation, can do so.  The publisher must be able
not only to express hints, but also to verify that what is being
served by the manager is correct.  Furthermore, to the extent that
there are security constraints on hint information, the publisher must
be able to both express them and verify compliance with them easily.

3.2.2 The Client

>From the perspective of the client, simplicity and usability are
paramount.  Of critical importance to serving clients effectively is
that there be an efficient protocol through which the client can acquire
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
must be minimized.

Furthermore, it will be important to be able to build simple, standard
interfaces to the RDS so that both the client and applications on the
client's behalf can interpret hints and subsequently make informed
choices.  The client, perhaps with the assistance of the application,
must be able to specify preferences and priorities and then apply them.
If the ordering of hints is only partial, the client may become directly
involved in the choice and interpretation of them and hence they must be
understandable to that client.  On the other hand, in general it should
be possible to configure default preferences, with individual
preferences viewed as overriding any defaults.

>From the client's perspective, although URNs will provide important
functionality, the client is most likely to interact directly only with
human friendly names (HFNs).  As in direct human interaction (not
computer mediated), the sharing of names will be on a small, private, or
domain specific scale.  HFNs will be the sorts of references and names
that are easy to remember, type, choose among, assign, etc.  There will
also need to be a number of mechanisms for mapping HFNs to URNs.  Such
services as "yellow pages" or "search tools" fall into this category.
Although we are mentioning HFNs here, it is important to recognize that
HFNs and the mappings from HFNs to URNs is and must remain a separate
functionality from an RDS.  Hence, although HFNs will be critical to
clients, they do not fall into the domain of this document.

                                 - 10 -

3.2.3 The Management

Finally, we must address the usability concerns with respect to the
management of the hint infrastructure itself.  What we are terming
"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
clients, so that they can find published resources.  It also provides
security with respect to name resolution to the extent that there is a
commitment for provision of such security; this is addressed in
Section 3.3 below.

The management of hints must be as unobtrusive as possible. First, its
infrastructure (hint storage servers and distribution protocols) must
have as little impact as possible on other network activities.  It must
be remembered that this is an auxiliary activity and must remain in the
background.

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 an 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 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 guideline, 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.

3.3 Security and Privacy

In summary, security and privacy guidelines can be identified as some
degree of protection from threats.  The guidelines that fall under
this third principle, that of security, are all stated in terms of
possibilities or options for users of the service to require and

                                 - 11 -

utilize.  Hence they address the availability of functionality, but
not for the use of it.  We recognize that all security is a matter of
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.

    3.1) It must be possible to create authoritative versions of a hint
         with access-to-modification privileges controlled;
    3.2) It must be possible to determine the identity of servers or
         avoid contact with unauthenticated servers;
    3.3) It must be possible to reduce the threat of denial of service
         by broad distribution of information across servers.
    3.4) It must be possible within the bounds of organizational
         policy criteria to provide at least some degree of privacy
         for traffic. 
    3.5) It must be possible for publishers to keep private certain
         information such as an overall picture of the resources they
         are publishing and the identity of their clients;
    3.6) It must be possible for publishers to be able to restrict
         access to the resolution of the URNs for the resources they
         publish, if they wish. 

When one discusses security, one of the primary issues is an enumeration
of the threats being considered for mitigation.  The 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.

Voydock and Kent[7] provide a useful catalog of potential threats.  Of
these the passive threats to privacy or confidentiality and the active
threats of authenticity and integrity are probably the most important
to consider here.  To the extent that spurious association causes
threats to the privacy, authenticity, or integrity with respect to
information within servers managing data, it is also important.
Denial of service is probably the most difficult of these areas of
threats both to detect and to prevent, and we will therefore set it
aside for the present as well, although it will be seen that solutions
to other problems will also mitigate some of the problems of denial of
service.  Furthermore, because this is intended to be provide a global
service to meet the needs of a variety of communities, the engineering
tradeoffs will be different for different clients.  Hence the
guidelines 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.  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 terms
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

                                 - 12 -

no implication of correctness of information, but only perhaps an
implication of who 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.  This second meaning arises elsewhere in the document
and is so noted there.

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
between mechanism and policy.  In general, a policy is realized by means
of a set of mechanisms.  In the case of an RDS there may be policies
internal to the RDS that it needs to have supported in order to do its
business as it sees fit.  Since, in general it is in the business of
storing and distributing information, most of its security policies may
have to do with maintaining its own integrity, and are rather limited.
Beyond that, to the degree possible, it should impose no policy on its
customers, the publishers and users.  It is they that may have policies
that they would like supported by the RDS.  To that end, an RDS should
provide a spectrum of "tools" or mechanisms that the customers can cause
to be deployed on their behalf to realize policies.  An RDS may not
provide all that is needed by a customer.  A customer may have different
requirements within his or her administrative bounds than outside.
Thus, "it must be possible..."  captures the idea that the RDS must
generally provide the tools to implement policies as needed by the
customers.

The first approach to URN resolution is to discover local hints.  In
order for hints to be discovered locally, they will need to be as
widely distributed to what is considered to be local for every locale.
The drawback of such wide distribution is the wide distribution of
updates, causing network traffic problems or delays in delivering
updates.  An alternative model would concentrate hint information in
servers, thus requiring that update information only be distributed to
these servers.  In such a model the vulnerable points are the sources
of the information and the distribution network among them.  Attackers
on the integrity of the information stored in a server may come in the
form of masquerading as the owner or the server of the information.
Wide replication of information among servers increases the difficult
of masquerading at all the locations of the information as well as
reducing the threat of denial service.  These lead us to three
identifiable guidelines for our security model:

                                 - 13 -

* ACCESS CONTROL ON HINTS: It must be possible to create an
  authoritative version of each hint with change control limited only
  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
  the publisher of a hint.

* SERVER AUTHENTICITY: Servers and clients must be able to learn the
  identity of the servers with which they communicate.  This will be a
  matter of degree and it is possible that there will be more
  trustworthy, but less accessible servers, supported by a larger 
  cluster of less authenticatable servers that are more widely
  available.  In the worst case, if the client receives what appears to
  be unvalidated information, the client should assume that the hint
  may be inaccurate and confirmation of the data might be sought from
  more reliable but less accessible sources.

* SERVER DISTRIBUTION: Broad availability will provide resistance to
  denial of service.  It is only to the extent that the services are
  available that they provide any degree of trustworthiness.  In
  addition, the distribution of services will reduce vulnerability
  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
  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,
  the more vulnerable it may become.

Privacy can be a double-edged sword.  For example, on one hand, an
organization may consider it critically important that its competitors
not be able to read its traffic.  On the other hand, it may also
consider it important to be able to monitor exactly what its employees
are transmitting to and from whom, for a variety of reasons such as
reducing the probability that its employees are giving or selling the
company's secrets to verifying that employees are not using company
resources for private endeavor.  Thus, although there are likely to be
needs for privacy and confidentiality, what they are, who controls
them and how, and by what mechanisms vary widely enough that it is
difficult to say anything concrete about them here.

The privacy of publishers is much easier to safeguard.  Since they are
trying to publish something, in general privacy is probably not desired.
However, publishers do have information that they might like to keep
private: information about who their clients are, and information about
what names exist in their namespace.  The information about who their
clients are may be difficult to collect depending on the implementation
of the resolution system.  For example, if the resolution information
relating to a given publisher is widely replicated, the hits to _each_
replicated copy would need to be recorded.  Of course, determining if a
specific client is requesting a given name can be approached from the
other direction, by watching the client as we saw above.

There are likely to be some publishers publishing for a restricted
audience.  To the extent they want to restrict access to a resource,
that is the responsibility of the repository providing and restricting
access to the resource.  If they wish to keep the name and hints for a
resource private, a public RDS may be inadequate for their needs.  In

                                 - 14 -

general, it is intended for those who want customers to find their
resources in an unconstrained fashion.

The final privacy issue for publishers has to do with access control
over URN resolution.  This issue is dependent on the implementation of
the publisher's authoritative (in the sense of "primary) URN resolver
server.  URN resolver servers can be designed to require proof of
identity in order to be issued resolution information; if the client
does not have permission to access the URN requested, the service denies
that such a URN exists.  An encrypted protocol can also be used so that
both the request and the response are obscured.  Encryption is possible
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

With these assumptions and guidelines in mind, we conclude with a
general framework within which RDS designs may fall.  As stated
earlier, although this framework is put forth as a suggested guide for
RDS designers, compliance with it will in no way guarantee compliance
with the guidelines.  Such an evaluation must be performed separately.
All such lack of compliance should be clearly documented.

The design of the framework is based on the syntax of a URN as
documented in RFC-2141[4].  This is:

	URN:<NID>:<NSS>

where URN: is a prefix on all URNs, NID is the namespace identifier, and
NSS is the namespace specific string.  The prefix identifies each URN as
such.  The NID determines the general syntax for all URNs within its
namespace.  The NSS is probably partitioned into a set of delegated and
subdelegated namespaces, and this is possibly reflected in further
syntax specifications.  In more complex environments, each delegated
namespace will be permitted to choose the syntax of the variable part of
the namespace that has been delegated to it.  In simpler namespaces, the
syntax will be restricted completely by the parent namespace.  For
example, although the DNS does not meet all the requirements for URNs,
it has a completely restricted syntax, such that any further structuring
must be done only by adding further refinements to the left, maintaining
the high order to low order, right to left structure.  A delegated
syntax might be one in which a host is named by the DNS, but to the
right of that and separated by an "@" is a string whose internal
ordering is defined by the file system on the host, which may be defined
high order to low order, left to right.  Of course, much more complex
and nested syntaxes should be possible, especially given the need to
grandfather namespaces.  In order to resolve URNs, rules will be needed
for two reasons.  One is simply to canonicalize those namespaces that do
not fall into a straightforward (probably right to left or left to
right) ordering of the components of a URN, as determined by the
delegated naming authorities involved.  It is also possible that rules
will be needed in order to derive from URNs the names of RDS servers to
be used in stages.

The NID defines a top level syntax.  This syntax will determine whether

                                 - 15 -

the NID alone or in conjunction with some extraction from the NSS (for
the top level naming authority name) is to be used to identify the first
level server to be contacted.  At each stage of the lookup either a new
rule for generating the strings used in yet another lookup (the strings
being the identity of another RDS server and possibly a string to be
resolved if it is different than the original URN) or a reference
outside the RDS to a URN resolver service, sidestepping any further use
of the RDS scheme.  Figure 1 depicts this process.

                            URN:<NID><NSS>
                                 |
                                 |
                                 |
                                 |
                                 v
                       +-------------------+
                       |Global NID registry|
                       +-------------------+
                                 |
       	       	       	       	 |
                                 |
              (return rule or URN resolver service reference)
                                 |
                                 +----------------------------------+
                                 |                                  |
                       +->(apply rule to determine RDS server)	    |
		       |         |				    |
		       |         |				    |
		       |         |				    |
                       |    +----------+			    |
                       |    |RDS server|	  +-----------------+
                       |    +----------+	  |
                       |      |	  |		  v
 		       |      |	  |   (set of choices)
 		       |      |	  +----+----------(...)--------+
                       |   (rule)      |                       |
                       |      |	       |		       |
 		       |      |	       |		       |
 		       +------+	       |		       |
 			      	       v		       v
 				  +----------+		  +----------+
                                  |URN	     |            |URN	     |
                                  |resolver  |		  |resolver  |
                                  |service   |		  |service   |
 				  +----------+		  +----------+

        Figure 1: An RDS framework

There are several points worth noting about the RDS framework.  First,
it leaves open the determination of the protocols, data organization,
distribution and replication needed to support a particular RDS scheme.
Second, it leaves open the location of the computations engendered by

                                 - 16 -

the rules.  Third, it leaves open the possibility that partitioning
(distribution) of the RDS database need not be on the same boundaries as
the name delegation.  This may seem radical to some, but if the
information is stored in balanced B-trees for example, the partitioning
may not be along those naming authority delegation boundaries (see
[6]).  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 be
more than one RDS available at any given time, in order to allow for
evolution to new schemes.  Thus, the picture should probably look more
like Figure 2.

                         URN:<NID>:<NSS>
                               |
        		       |
		   +-----------+-------(...)-------+
		   |				   |
		   |				   |
		   |				   |
		   v				   v
	 +---------------------+	+---------------------+
	 |Global NID registry 1|        |Global NID registry N|
	 +---------------------+        +---------------------+
                   .                               .
                   .                               .
                   .                               .

        Figure 2: More than one co-existing RDS scheme

If we are to support more than one co-existing RDS scheme, there will
need to be coordination among them with respect to storage and
propagation of information and modifications.  The issue is that
generally it should be assumed that all information should be available
through any operational RDS scheme.  One cannot expect potential
publishers to submit updates to more than one RDS scheme.  Hence there
will need to be a straightforward mapping of information from one to the
other of these schemes.  It is possible that that transformation will
only go in one direction, because a newer RDS service is replacing an
older one, which is not kept up to date, in order to encourage transfer
to the newer one.  Thus, at some point, updates may be made only to the
newer one and not be made available to the older one, as is often done
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 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

                                 - 17 -

may not meet all the guidelines, but should be expected to itemized and
justify any lack of compliance.

5. Acknowledgments

Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a preliminary URN requirements document and for his
insightful comments on this version of the document.  Thanks also go
to Ron Daniel especially for his many comments on my writing.  In
addition, I recognize the contributors to a previous URN framework
document, the "Knoxville" group.  There are too many of you to
acknowledge here individually, but thank you.  Finally, I must thank
the contributors to the URN working group and mailing list
([email-masked]), for your animated discussions on these and
related topics.

6. References

[1] Kunze, J., "Functional Recommendations for Internet Resource
Locators", RFC 1736, February, 1995.

[2] Sollins, K. and Masinter, L., "Functional Requirements for Uniform
Resource Names", RFC 1738, December, 1994.

[3] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource
Locators (URL)", RFC 1738, December, 1994.

[4] Moats, R., "URN Syntax", RFC 2141, May 1997.

[5] Iannella, R. and Faltstrom, P., "Namespace Identifier Requirements
for URN Services," currently draft-ietf-urn-nid-req-01.txt.  Intended
to become an information rfc by the URN working group.

[6] Slottow, E.G., "Engineering a Global Resolution Service,"
MIT-LCS-TR712, June, 1997.  Currently available as
<http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or
<http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.

[7] Voydock, V. L., and Kent, S. T., "Security Mechanisms in
High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June,
1983, pp. 135-171.

7. Contact information:

Karen Sollins
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139

Tel: +1 617 253 6006
Email: [email-masked]

This Internet Draft expires on December 4, 1997.

                                 - 18 -

Date: Mon, 28 Jul 1997 11:36:30 -0700
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] Re std-, prv-
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Leslie replying to Ron:
| Is it also necessary/interesting to have a separate registry that simply
| registers the namespace ID, without any connotations of accessibility
| through one resolution system or another?    I.e., _just_ a registry
| of known namespace ID's.

Someone is going to make a business of making a list of all known
name space IDs (so as to be able to offer some sort of response to
any request for any purported URN).  I don't know whether it's useful 
to spend volunteer effort on doing so.

| > connotations. How about something like "r<digits>-", where the
| > R stands for "registered" and the digits let us deal with multiple
| > requests for a particular namespace ID? The ever-popular "foo"
| > NID would have r1-foo, r2-foo, r3-foo, etc.   
| 
| And would the "r" number be dropped for namespaces that had gone through
| the full standardization process?

Either way I'm confused.  Do we need to do this?  Why?  I didn't find
a clear reason in the straw proposal.

| I'll accept Martin's argument for dropping the "std-" (although it
| sounds suspiciously isomorphic to the "URL:/URN:" problem :-)  but 
| I think it is important to be able to distinguish namespaces that have
| _not_ gone through a standardization process.  So, if we did something
| like the "r-" scheme, I would like to see that dropped for standardized
| namespaces.

How about, standardized name space IDs are those registered in the
appropriate registry, and all others are nonstandardized?

Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html

Date: Mon, 28 Jul 1997 12:20:59 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: "Ron Daniel, Jr." <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] strawcat proposal
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Mon, 28 Jul 1997, Ron Daniel, Jr. wrote:
> between names there still needs to be a registry for unreviewed
> namespace IDs. They are not truly private. "x-" has the wrong

This is quite true.  In my mind, it should be possible to register them
at least in the Global NID  in order to be globally accessible and
otherwise as functional as fully standardized namespaces.  

Is it also necessary/interesting to have a separate registry that simply
registers the namespace ID, without any connotations of accessibility
through one resolution system or another?    I.e., _just_ a registry
of known namespace ID's.

> connotations. How about something like "r<digits>-", where the
> R stands for "registered" and the digits let us deal with multiple
> requests for a particular namespace ID? The ever-popular "foo"
> NID would have r1-foo, r2-foo, r3-foo, etc.   

And would the "r" number be dropped for namespaces that had gone through
the full standardization process?

I'll accept Martin's argument for dropping the "std-" (although it
sounds suspiciously isomorphic to the "URL:/URN:" problem :-)  but 
I think it is important to be able to distinguish namespaces that have
_not_ gone through a standardization process.  So, if we did something
like the "r-" scheme, I would like to see that dropped for standardized
namespaces.

Leslie.

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Mon, 28 Jul 1997 09:51:00 -0600
To: Leslie Daigle <[email-masked]>, [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] strawcat proposal
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 02:59 PM 7/24/97 -0400, Leslie Daigle wrote:
>We can write up the list of technical _expectations_ of a namespace, AND
>namespace serving:
[...]
>Then, we can write up a list of guidelines for _good_ namespaces and
>namespace serving:
[...]

Yes, I like the idea of setting forth the REQUIREMENTS and the RECOMMENDATIONS
for namespaces. The list of true requirements is small. Therefore I suggest
we do this as two drafts, since the list of recommendations is likely to
take awhile to hammer out.

On the subject of Leslie's suggestion to use something like priv- to denote
a namespace that is intended to be easier to establish, less likely
to be truly persistent, etc. This is, of course, tempting us into
commiting the sin of embedding semantics into our IDs. However, I think that
the sin in this case is venal rather than mortal, and as a sinner of long
standing I have to say that I tend to agree with the sense of the
suggestion, although I have some quibbles with the details. I certainly
agree with Martin in asking that we not do a "std-" prefix for names that
have gone through review.

I'm not so sure about the literal string "priv-". To avoid collisions
between names there still needs to be a registry for unreviewed
namespace IDs. They are not truly private. "x-" has the wrong
connotations. How about something like "r<digits>-", where the
R stands for "registered" and the digits let us deal with multiple
requests for a particular namespace ID? The ever-popular "foo"
NID would have r1-foo, r2-foo, r3-foo, etc.   

Later,

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email-masked]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545  

Date: Mon, 28 Jul 1997 12:10:14 +0200 (MET DST)
From: "Martin J. Duerst" <[email-masked]>
To: Leslie Daigle <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] strawcat proposal
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 24 Jul 1997, Leslie Daigle wrote:

> ----------------------------------------
> Proposal:
> ----------------------------------------
> 
> Here comes the strawcat proposal for naming conventions:
> 
> 	. reserve "std-" prefix in NIDs for those namespaces that have
> 	  gone through a technical review within the IETF and for which
> 	  there is an RFC describing the namespace and its conformance
> 	  to the guidelines.  (Then, Ryan's proposed namespace would
> 	  be "std-ietf").
> 
> 	.. use "prv-" prefix for NIDs of any other namespace (which _can_
> 	  be registered in the urn.net domain).

Distinguishing the two and having a prefix for private namespaces
(I assume "prv" is standing for "private") is very good. But I think
"std-" is not needed. There should be some incentive for going through
IETF review, and having a short NID is a clear incentive.
Also, it should be expected that standard namespaces are used more
often than private ones, and it would be a pain to always have to
type the "std-" prefix. Clever browser makers may even automatically
add it, so there will be a difference between the official URN and
its actual use, which is confusing and unnecessary.

Regards,	Martin.

Date: Thu, 24 Jul 1997 14:59:25 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] strawcat proposal
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

----------------------------------------
Preamble:
----------------------------------------

In Memphis, there was much debate about who should  or should not
be deemed eligible to "have" a namespace -- e.g., only multi-national
organizations.  What could those identifiers be -- some suggested there
are too many socio-political problem areas with letters (of any character
set), so we'd best stick with numbers, and perhaps assigned ones at that
(and anyone else that has read C. J. Cherryh's Atevi books will point out
the potential problems of being assigned infelicitous numbers, but that's
a different earth... ;-)

It has often been pointed out on this list that we, the URN group, and
the IETF in general, are not in a position to _enforce_ much of anything
in the way of socio-political requirements.  We need a technical system that 
works irrespective of the wars raged in those areas.

And, we have people who want to set up URN namespaces _now_ -- having read
the URN syntax document, they have a clear idea of how the would like their
URNs to be structured, but maybe haven't thought a lot about how the 
resolution service will be set up and maintained and linked into the
global infrastructure.

We've discussed some of this before, and some of this does already appear
in Renato and Patrik's document, but I'd like to step away from that for
a moment, to just focus on what we need to have written _somewhere:

We can write up the list of technical _expectations_ of a namespace, AND
namespace serving:

	. no identifier reused
	. mapping from identifier to URN syntax (in the case of grandfathering)
	. no forseen reasons that the namespace resolution service(s) will be
	  terminated before the URN references are all deleted
	. registration in the Global NID registry
	. fall-back plans for passing off resolution of the namespace in
	  the event that the entity defining the namespace ceases to exist
	. <etc>

This at least gives some guidelines for people who think they want a
URN namespace.

Then, we can write up a list of guidelines for _good_ namespaces and
namespace serving:

	. if a namespace that works already exists, use it
	. it's better if it demonstrates multi-national applicability
	. <etc>

So, then, what is the process for defining a namespace?  Do you define
a NID, set up a tHTTP server, and start resolving those?  Are these valid
URNs?  Is it valid if you send in the appropriate NAPTR information to
be registered in the urn.net domain?  Should each and every proposed namespace
be put through an RFC-definition process?  

----------------------------------------
Proposal:
----------------------------------------

Here comes the strawcat proposal for naming conventions:

	. reserve "std-" prefix in NIDs for those namespaces that have
	  gone through a technical review within the IETF and for which
	  there is an RFC describing the namespace and its conformance
	  to the guidelines.  (Then, Ryan's proposed namespace would
	  be "std-ietf").

	.. use "prv-" prefix for NIDs of any other namespace (which _can_
	  be registered in the urn.net domain).

This is meant to draw on what I've  understood is the approach used with
MIMEtypes -- the "vnd." subtypes for vendor-defined types.  It means that 
namespaces can be set up fairly easily for those who don't forsee the need for 
URNs outside their own space -- but if these URNs do escape (and 
they will) they can still be recognized/handled in the global context.  The 
theory is that, if a namespace has been put through the full technical 
definition to become an std- namespace, then the proposer was serious enough 
about it to be a reasonable bet for providing the necessary longterm 
infrastructure for serving it.  No guarantee -- we aren't about guarantees.  
It also provides a mechanism for distinguishing between the two types.  And,
if  "foo" is first defined as a private namespace ("prv-foo"), and then
made a standard ("std-myfoo", because "std-foo" is something else), 
the Global NID can map the existing "prv-foo" URN resolution to the same
servers as the "std-myfoo".

Anyway, this is just a proposal, meant to kick off some discussions about
the issues in the area.  I'm climbing into my flame-retardant suit and
awaiting feedback... :-)

Leslie.

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Thu, 24 Jul 1997 14:58:59 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] All-righty...
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

'Tis the season to stir up discussion and chase down the last of the issues
that need to find their way into Internet-Drafts before the Munich meeting
(I-D draft deadline is Wednesday, July 30, 1997 at 5pm ET).

We're doing pretty well on our ToDo list from Memphis -- I've attached a list
of RFCs and state of the current Internet-Drafts at the end of this message.
Most of these I-D's are in their nth revision, and are quite close to being
ready to be proposed as RFCs.

There is, however, one area that is really in need of documentation before
we can say our job is done and let people go wild with URNs.

This is the whole area of defining what a URN namespace _is_, what it takes
to "get" one, and what is expected of entities that intend to "maintain"
one.  Renato and Patrik have been valiantly struggling with the document, but
I don't think we've yet given them a clear enough definition of what it is 
that's meant to be written, and what scope it should have.  

The Memphis meeting featured a number of heated debates about this issue, but
no real convergence.  We have two major challenges to face in getting
these things sorted out in a document:

	. we have to avoid policy-like statements, because this is traditionally
	  an area of weakness for the IETF.  I.e., this must focus
	  strictly on the technical

	. if we seriously want to be able to declare our job done, it is
	  not enough to simply define a technical ideal and walk away. There
	  are people who want to use URNs _today_, and I believe we need
	  to capture our thoughts on the pragmatic usage of these things.

This is somewhat challenging, as these items are sometimes in opposition
with each other, but we have to have a bash at it.  

I have a strawcat proposal that I'll send, as a member of this list, in
another mail.  What I'd like to do in Munich is walk through the process
of assigning URNs, so that we can get the guidelines down for URN namespaces,
and figure out what are the last things that need to be captured (if any
others) before we can declare that the world has enough documentation to
step forward with URN usage.   

Leslie.

----------------------------------------
URN WG Documents
----------------------------------------

Request for Comments 
     . URN Syntax (RFC 2141) 
     . Resolution of Uniform Resource Identifiers using the Domain Name System 
       (RFC 2168)
     . A Trivial Convention for using HTTP in URN Resolution (RFC 2169) 

Current Internet-Drafts 
     . Guidelines and a Framework for URN Resolution Systems 
       [Revision in progress]
     . URI Resolution Services Necessary for URN Resolution 
       [Revision in progress -- due to be released any day now]
     . Using Existing Bibliographic Identifiers as Uniform Resource Names 
       [Revision circulated on list; haven't confirmed receipt by I-D 
        editor]
     . A URN Namespace for IETF Documents 
       [Revision has been circulated.  Last call is largely waiting on the
        document for defining namespaces, in order to ensure necessary
        correlations are made]

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Wed, 23 Jul 1997 17:23:55 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] comment on NID requirements doc
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Hi Renato and Patrik,

I don't remember the details of the dicussion about this document in
Memphis, but basically, I think it's got the right ideas in it.  There
is probably one thing that should be said up front - that all URNs in
any approved namespace must be compliant with RFCs 1737 and 2141.
But, in reading it again, I realized that there is a small issue of
naming that we might valuably discuss.  The title of the document is
"Namespace Identifier Requirements for URN Services."  I have a couple
of issues with this:

1) I don't think this document should be talking about "namespace
identifiers" but rather namespaces.  The NID is just a NAME for a
namespace, and we really are concerned here with namespaces and how
names are defined in them, not what we call them.

2) I don't think it is appropriate to call these "requirements".  Some
of the points clearly derive from requirements, such as the URN
requirements, but I thought these were supposed to be guidelines or a
checklist for whoever might be given the job in the future of
approving of namespaces.

3) I think the "for URN Services" is misleading in the title.

My suggestion for a title is "Guidelines for Acceptable URN
Namespaces".  As a result, there are a number of places where the
wording would neet to be changed to reflect this.  If and when you are
planning to do another revision of the document, let me know and I can
send you a bunch of minor corrections as well.  There's no need to
fill the mailing list with that.

			Karen

Date: Tue, 25 Mar 1997 07:19:26 -0800
To: [email-masked]
From: Cecilia Preston <[email-masked]>
Subject: [URN] draft Bibliographic Identifiers to URNs
Status: R
Sender: [email-masked]
Reply-To: Cecilia Preston <[email-masked]>

As promised for the next meeting.  Cliff, Ron and I are responsible for
content, I am responsible for typos etc.

--Cecilia

<fontfamily><param>Times</param><bigger>

</bigger></fontfamily><bigger><fontfamily><param>Courier</param>Internet
Draft                                Clifford
Lynch</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>draft-ietf-urn-biblio-00.txt
       University of
California</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>22 March 1997          =20
                    Cecilia
Preston</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Expires in six months  =20
                    Preston &
Lynch</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                     Ron Daniel
Jr.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
     Los Alamos National
Laboratory</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>          Using Existing
Bibliographic Identifiers</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
    as </fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                 =20
Uniform Resource Names</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Status of this
Document</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>This document is an
Internet-Draft.  Internet-Drafts are
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>working documents of the
Internet Engineering Task Force
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>(IETF), its areas, and
its working groups.  Note that other
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>groups may also
distribute working documents as
Internet-</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Drafts.</fontfamily><fontfami=
ly><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Internet-Drafts are
draft documents valid for a maximum of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>six months and may be
updated, replaced or made obsolete by
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>other documents at any
time.  It is inappropriate to use
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Internet-Drafts as
reference material or to cite them other
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>than as works in
progress. </fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Distribution of this
document is unlimited.  Please send
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>comments to
[email-masked] and
[email-masked].</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>This document does not
specify a standard; it is purely
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>informational.</fontfamily><f=
ontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>0.
Abstract</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>A system for Uniform
Resource Names (URNs) must be
capable</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>of supporting
identifiers from existing widely-used naming
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>systems.  This document
discusses how three major
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>bibliographic
identifiers (the ISBN, ISSN and SICI) can be
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>supported within the URN
framework and the currently
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>proposed syntax for
URNs.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                           [Page
1]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>1.
Introduction</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The ongoing work of
several IETF working groups, most
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>recently in the Uniform
Resource Names working group, has
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>culminated the
development of a syntax for Uniform Resource
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Names (URNs).   The
functional requirements and overall
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>framework for Uniform
Resource Names are specified in RFC
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>1737 [Sollins &
Masinter] and the current proposal for the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>URN syntax is
draft-ietf-urn-syntax-04.txt
[Moats].</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>As part of the
validation process for the development of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>URNs the IETF working
group has agreed that it is important
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>to demonstrate that the
current URN syntax proposal can
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>accommodate existing
identifiers from well managed
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>namespaces.  One such
well-established infrastructure for
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>assigning and managing
names comes from the bibliographic
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>community.=20
Bibliographic identifiers function as names for
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>objects that exist both
in print and, increasingly, in
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>electronic formats.=20
This Internet draft demonstrates the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>feasibility of
supporting three representative bibliographic
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>identifiers within the
currently proposed URN framework and
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>syntax.</fontfamily><fontfami=
ly><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Note that this document
does not purport to define the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>"official" standard way
of doing so; it merely demonstrates
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>feasibility.  It has not
been developed in consultation with
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the standards bodies and
maintenance agencies that oversee
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the existing
bibliographic identifiers.  Any actual Internet
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>standard for encoding
these bibliographic identifiers as
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>URNs will need to be
developed in consultation with the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>responsible standards
bodies and maintenance
agencies.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>In addition, there are
several open questions with regard to
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the management and
registry of Namespace Identifiers (NIDs)
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>for URNs.  For purposes
of illustration, we have used the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>three NIDs "ISBN",
"ISSN" and "SICI" for the three
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>corresponding
bibliographic identifiers discussed in this
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>document.  While we
believe this to be the most appropriate
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>choice, it is not the
only one.  The NIDs could be based on
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the standards body and
standard number (e.g.
"US-ANSI-NISO-</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Z39.56-1997" rather than
"SICI").  Alternatively, one could
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>lump all bibliographic
identifiers into a single
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>"BIBLIOGRAPHIC" name
space, and structure the
namespace-</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                          [Page
2]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param> INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>specific string to
specify which identifier is being
used.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>We do not believe that
these are advantageous approaches,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>but must wait for the
outcome of namespace management
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>discussions in the
working group. </fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>For the purposes of this
document, we have selected three
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>major bibliographic
identifiers (national and international)
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>to fit within the URN
framework.  These are the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>International Standard
Book Number (ISBN) [ISO1], the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>International Standard
Serials Number (ISSN) [NISO1,ISO2,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>ISO3], and the Serial
Item and Contribution Identifier
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>(SICI) [NISO2].  ISBNs
are used to identify monographs
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>(books).  ISSNs are used
to identify serial publications
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>(journals, newspapers)
as a whole.  SICIs augment the ISSN
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>in order to identify
individual issues of serial
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>publications, or
components within those issues (such as an
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>individual article, or
the table of contents of a given
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>issue).  The ISBN and
ISSN are defined in the United States
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>by standards issued by
the National Information Standards
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Organization (NISO) and
also by parallel international
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>standards issued under
the auspices of the International
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Organization for
Standardization (ISO).  NISO is the
ANSI-</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>accredited standards
body serving libraries, publishers and
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>information services.=20
The SICI code is defined by a NISO
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>document in the United
States and does not have a parallel
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>international standards
document at present. </fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Many other bibliographic
identifiers are in common use (for
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>example, the CODEN,
numbers assigned by major bibliographic
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>utilities such as OCLC
and RLG, national library numbers
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>such as the Library of
Congress Control Number) or are under
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>development.  While we
do not discuss them in this document,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>many of these will also
need to be supported within the URN
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>framework as it moves to
large scale implementation.  The
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>issues involved in
supporting those additional identifiers
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>are anticipated to be
broadly similar to those involved in
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>supporting ISBNs, ISSNs,
and SICIs.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>2. Identification vs.
Resolution</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>It is important to
distinguish between the resource
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>identified by a URN and
the resources that can reasonably be
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>provided when attempting
to resolve an identifier.=20
=46or</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                           [Page
3]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>example, the ISSN
0040-781X identifies the
popular</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>"Time".  All of it,
every issue for from the start of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>publication to present.=20
Resolving such an identifier should
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>not result in the
equivalent of hundreds of thousands of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>pages of text and photos
being dumped to the user's
machine.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>It is more reasonable
for ISSNs to resolve to a navigational
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>system, such as an
HTML-based search form, so the user may
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>select issues or
articles of interest.  ISBNs and SICIs,
on</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the other hand, do
identify finite, manageably-sized
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>objects, but they may
still be large enough that resolution
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>to a hierarchical system
is appropriate.  </fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>In addition, the
materials identified by an ISSN, ISBN or
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>SICI may exist only in
printed or other physical form, not
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>electronically.  The
best that a resolver may be able to
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>offer is information
about where to get the physical
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>resource, such as
library holdings or a bookstore or
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>publisher order form.=20
The URN Framework provides resolution
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>services that may be
used to describe any differences
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>between the resource
identified by a URN and the resource
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>that would be returned
as a result of resolving that
URN.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>3. International
Standard Book Numbers</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>3.1
Overview</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>An International
Standard Book Number (ISBN) identifies an
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>edition of a monographic
work.  The ISBN is defined by the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>standard NISO/ANSI/ISO
2108:1992 [ISO 1]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Basically, an ISBN is a
ten-digit number (actually, the last
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>digit can be the letter
"X" as well, as described below)
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>which is divided into
four variable length parts usually
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>separated by hyphens
when printed.  The parts are as follows
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>(in this order):
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>* a group identifier
which specifies a group of publishers,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>based on national,
geographic or some other
criteria,</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>* the publisher
identifier,</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                          [Page
4]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>* the title
identifier,</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>* and a modulus 11 check
digit, using X in lieu of
10.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The group and publisher
number assignments are managed in
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>such a way that the
hyphens are not needed to parse the ISBN
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>unambiguously into its
constituent parts.  However, the ISBN
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>is normally transmitted
and displayed with hyphens to make
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>it easy for human beings
to recognize these parts without
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>having to make reference
to or have knowledge of the number
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>assignments for group
and publisher
identifiers.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>3.2 Encoding
Considerations</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Embedding ISBNs within
the URN framework presents no
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>particular coding
problems, since all of the characters that
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>can appear in an ISBN
are valid in the identifier segment of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the URN.  %-encoding is
never needed.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Example:
URN:ISBN:0-395-36341-1</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>For the ISBN namespace,
some additional equivalence rules
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>are appropriate.  Prior
to comparing two ISBN URNs for
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>equivalence, it is
appropriate to remove all hyphens, and to
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>convert any occurrences
of the letter X to upper
case.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>3.3 Additional
considerations</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The ISBN standard and
related community implementation
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>guidelines define when
different versions of a work should
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>be assigned the same or
differing ISBNs.  In actuality,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>however, practice varies
somewhat depending on publisher as
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>to whether different
ISBNs are assigned for paperbound vs.
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>hardbound versions of
the same work, electronic vs. printed
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>versions of the same
work, or versions of the same work
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>published for example in
the US and in Europe.  The choice
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>of whether to assign a
new ISBN or to reuse an existing one
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>when publishing a
revised printing of an existing edition of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>a work or even a revised
edition of a work is
somewhat</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>subjective.  Practice
varies from publisher to publisher
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>(indeed, the distinction
between a revised printing and a
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>new edition is itself
somewhat subjective).  The use of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                           [Page
5]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>ISBNs within the URN
framework simply reflects these
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>existing practices.=20
Note that it is likely that an ISBN URN
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>will often resolve to
many instances of the work (many
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>URLs).</fontfamily><fontfamil=
y><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>4. International
Standard Serials Numbers</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>4.1
Overview</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>International Standard
Serials Numbers (ISSN) identify a
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>work that is being
published on a continued basis in issues;
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>they identify the entire
(often open-ended, in the case of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>an actively published)
work.  ISSNs are defined by the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>standards ISO 3297:1986
[ISO 2] and ISO/DIS 3297 [ISO 3] and
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>within the United States
by NISO Z39.9-1992 [NISO 1].  The
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>ISSN International
Centre is located in Paris and
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>coordinates a network of
regional centers.  The National
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Serials Data Program
within the Library of Congress is the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>US Center of this
network.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>ISSNs have the form
NNNN-NNNN where N is a digit, the last
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>digit may be an upper
case X as the result of the check
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>character calculation.=20
Unlike the ISBN the ISSN components
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>do not have much
structure; blocks of numbers are passed out
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>to the regional centers
and publishers.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>4.2 Encoding
Considerations</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Again, there is no
problem representing ISSNs in the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>namespace-specific
string of URNs since all characters valid
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>in the ISSN are valid in
the namespace-specific URN string,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>and %-encoding is never
required. </fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Example:
URN:ISSN:1046-8188</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Supplementary comparison
rules are also appropriate for the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>ISSN namespace.  Just as
for ISBNs, hyphens should be
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>dropped prior to
comparison and occurrences of 'x'
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>normalized to
uppercase.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                           [Page
6]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>4.3 Additional
Considerations</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The ISSN standard and
related community implementation
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>guidelines specify when
new ISSNs should be assigned vs.
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>continuing to use an
existing one.  There are some
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>publications where
practice within the bibliographic
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>community varies from
site to site, such as annuals or
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>annual conference
proceedings.  In some cases these are
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>treated as serials and
ISSNs are used, and in some cases
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>they are treated as
monographs and ISBNs are used.  For
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>example SIGMOD Record
volume 24 number 2 June 1995 contains
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the Proceedings of the
1995 ACM SIGMOD International
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Conference on Management
of Data.  If you subscribe to the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>journal (ISSN 0163-5808)
this is simply the June issue.  On
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the other hand you may
have acquired this volume as the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>conference proceedings
(a monograph) and as such would use
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the ISBN 0-89791-731-6
to identify the work.  There are also
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>varying practices within
the publishing community as to when
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>new ISSNs are assigned
due to the change in the name of a
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>periodical (Atlantic
becomes Atlantic Monthly); or when a
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>periodical is published
both in printed and electronic
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>versions (The New York
Times).  The use of ISSNs as URNs
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>will reflect these
judgments and practices.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>5. Serial Item and
Contribution Identifiers</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>5.1
Overview</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The standard for Serial
Item and Contribution Identifiers
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>(SICI) has recently been
extensively revised and is defined
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>by NISO/ANSI Z39.56-1997
[NISO 2].  The maintenance agency
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>for the SICI code is the
UnCover Corporation.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>SICI codes can be used
to identify an issue of a serial, or
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>a specific contribution
(i.e., an article, or the table of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>contents) within an
issue of a serial.  SICI codes are not
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>assigned, they are
constructed based on information about
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the issue or issue
component in question.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The complete syntax for
the SICI code will not be discussed
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>here; see NISO/ANSI
Z39.56-1997 for details.  However an
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>example and brief review
of the major components is
needed</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                           [Page
7]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>to understand the
relationship with the ISSN and how this
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>identifier differs.  An
example of a SICI code
is:</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>0015-6914(19960101)157:1<<62:=
KTSW>2.0.TX;2-F</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The first nine
characters are the ISSN identifying the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>serial title.  The
second component, in parentheses, is the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>chronology information
giving the date the particular serial
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>issue was published.  In
this example that date was January
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>1, 1996.  The third
component, 157:1, is enumeration
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>information (volume,
number) on the particular issue of the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>serial.  These three
components comprise the "item segment"
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>of a SICI code.  By
augmenting the ISSN with the chronology
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>and/or enumeration
information, specific issues of the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>serial can be
identified.  The next segment, <<62:KTSW>,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>identifies a particular
contribution within the issue.  In
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>this example we provide
the starting page number and a title
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>code constructed from
the initial characters of the title.
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Identifiers assigned to
a contribution can be used in the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>contribution segment if
page numbers are inappropriate.  The
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>rest of the identifier
is the control segment, which
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>includes a check
character.  Interested readers are
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>encouraged to consult
the standard for an explanation of the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>fields in that
segment.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>5.2 Encoding
Considerations</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>The character set for
SICIs is intended to be
email-</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>transport-transparent,
so it does not present major
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>problems.  However, all
printable excluded and reserved
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>characters from the URN
syntax draft are valid in the SICI
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>character set and must
be %-encoded.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Example of a SICI for an
issue of a journal</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>   =20
URN:SICI:1046-8188(199501)13:1%3C%3E1.0.TX;2-F</fontfamily><fontfamily><para=
m>Times</param>

</fontfamily><fontfamily><param>Courier</param>For an article contained
within that issue</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>   =20
URN:SICI:1046-8188(199501)13:1%3C69:FTTHBI%3E2.0.TX;2-4</fontfamily><fontfam=
ily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                           [Page
8]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Special equivalence
rules for SICIs are not appropriate for
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>definition as part of
the namespace and incorporation in
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>areas such as cache
management algorithms.  These are best
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>left to resolver systems
which try to determine if two SICIs
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>refer to the same
content.  Consequently, we do not propose
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>any specific rules for
equivalence testing through lexical
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>manipulation.</fontfamily><fo=
ntfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>5.3 Additional
Considerations</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Since the serial is
identified by an ISSN, some of the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>ambiguity currently
found in the assignment of ISSNs carries
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>over into SICI codes.=20
In cases where an ISSN may refer to a
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>serial that exists in
multiple formats, the SICI contains a
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>qualifier that specifies
the format type (for example,
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>print, microform, or
electronic).  SICI codes may be
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>constructed from a
variety of sources (the actual issue of
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>the  serial, a citation
or a record from an abstracting
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>service) and, as such
are based on the principle of using
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>all available
information, so there may be multiple SICI
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>codes representing the
same article [NISO2, Appenidx D].=20
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>For example, one code
might be constructed with access to
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>both chronology and
enumeration (that is, date of issue and
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>volume, issue and page
number), another code might be
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>constructed based only
on enumeration information and
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>without benefit of
chronology.  Systems that use SICI codes
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>employ complex matching
algorithms to try to match SICI
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>codes constructed from
incomplete information to SICI codes
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>constructed with the
benefit of all relevant
information.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>6. Security
Considerations</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>This document proposes
means of encoding several existing
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>bibliographic
identifiers within the URN framework.  It does
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>not discuss resolution;
thus questions of secure or
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>authenticated resolution
mechanisms are out of scope.  It
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>does not address means
of validating the integrity or
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>authenticating the
source or provenance of URNs that contain
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>bibliographic
identifiers.  Issues regarding intellectual
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>property rights
associated with objects identified by
the</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>various bibliographic
identifiers are also beyond the scope
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>of this document, as are
questions about rights to the
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>databases that might be
used to construct
resolvers.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>                       =20
                           [Page
9]</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>INTERNET
DRAFT:Bibliographic Identifiers as URNs   =20
3/1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>7.
References</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[ISO1] NISO/ANSI/ISO
2108:1992 Information and documentation
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       -- International
standard book number
(ISBN)</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[ISO2] ISO 3297:1986
Documentation -- International standard
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       serial numbering
(ISSN)</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[ISO3] ISO/DIS 3297
Information and documentation --
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       International
standard serial numbering (ISSN)
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       (Revision of ISO
3297:1986)</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[Moats] R. Moats, "URN
Syntax"
draft-ietf-urn-syntax-</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       04.text. March
1997</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[NISO 1] NISO/ANSI
Z39.9-1992 International standard
serial</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       numbering
(ISSN)</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[NISO 2] NISO/ANSI
Z39.56-1997 Serial Item and
Contribution</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>     =20
Identifier</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[Sollins & Masinter] K.
Sollins and L. Masinter,
"Functional</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       Requirements for
Uniform Resource Names", RFC 1737
</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>       December
1994.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>8. Author's
Addresses</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Clifford
Lynch</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>University of California
Office of the President</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>300 Lakeside Drive, 8th
floor</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Oakland CA
94612-3550</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[email-masked]</font=
family><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Cecilia
Preston</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Preston &
Lynch</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>PO Box
8310</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Emeryville, CA
94662</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>[email-masked]</fontfamily>=
<fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Ron Daniel
Jr.</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Advanced Computing Lab,
MS B287</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Los Alamos National
Laboratory</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>Los Alamos, NM,
87545</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>voice: +1 505 665
0597</fontfamily><fontfamily><param>Times</param>

</fontfamily><fontfamily><param>Courier</param>fax: +1 505 665
4939</fontfamily><fontfamily><param>Times</param>

<bigger>http://www.acl.lanl.gov/~rdaniel</bigger>

</fontfamily><fontfamily><param>Courier</param>                       =20
                          [Page
10]</fontfamily><fontfamily><param>Times</param>

</fontfamily></bigger>

Date: Sat, 19 Jul 1997 12:33:50 -0400 (EDT)
From: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

From: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Mon, 14 Jul 97 09:28:14 
Priority: Normal
Subject: [URN] Open Issues for ietf-02.
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Hi everybody!

Well, I had hoped that the "ietf" namespace draft was ready to go to WG last call,
but a couple of open issues have come up that could delay moving forward.

Either before or after this message (depending on the vagaries of Internet mail)
is a copy of draft-02.  The open issues on this document that still remain are:

>	. who assigns the names, and how are they assigned (i.e., the
>	  implicit thing is that you can derive a URN from an IETF
>	  document name, but does that mean someone is willing to 
>	  resolve all IETF document names to some kind of result?
>
>	. who owns this part of URN space and is willing to serve it
>	  up (assignment and/or resolution)?

I believe that these two issues are closely related in that I think that whomever owns
this namespace should be willing to resolve ALL assigned names.  While I am willing
to volunteer the InterNIC Directory and Database Services as the owner/resolver
of the namespace, I am unwilling to do so because I don't expect us to be around
after March 1998.  Therefore, I am looking for a volunteer to own/resolve this
namespace.

As far as name assignment is concerned,  my thoughts are that a new name is assigned
when the canonical documents referred to in the draft have new versions created or
when minutes are added to the IETF records. Thus names are assigned by the RFC editor 
(in the case of the RFC family) or the IETF (in the case of meeting minutes).  This is 
already covered in the draft, so I think this portion (how names are assigned) can be
considered closed.

Another open issue is in reference to the NSS ABNF and following draft text:

   > The ABNF specification for "family" is based on the current documents
   > in the RFC family.  As new document series are added to the IETF
   > family by the IESG (or its successor), this ABNF specification will
   > need to be updated.  Any system intended to resolve names for this
   > namespace should be written with the awareness that a new document
   > series may be introduced at any time.

It has been pointed out that the ABNF could claim that the NSS is an
opaque string.  In this case, the specific ABNF would not have to be
specified, and the above paragraph could be removed.  I'm currently
in the camp of specifying this information so that multiple resolvers could
be set up.  However, if enough folks care strongly enough, I'm flexible on
making this specification opaque.

I don't think there are any other open issues.  There have been several
editorial changes based on comments from the -01 draft.  I'd like to
try to reach closure on these issues so that I can submit a draft for
WG last call before Munich so that we can stay on schedule.

Thanks,
Ryan

Date: Mon, 14 Jul 97 09:12 CDT
To: [email-masked]
Subject: [URN] submission of draft-ietf-urn-ietf-02.txt
From: [email-masked] (Ryan Moats)
Sender: [email-masked]
Reply-To: [email-masked] (Ryan Moats)

Internet-Draft                                                Ryan Moats
draft-ietf-urn-ietf-02.txt                                          AT&T
Expires in six months                                          July 1997

                   A URN Namespace for IETF Documents
                  Filename: draft-ietf-urn-ietf-02.txt

Status of This Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its
      areas, and its working groups.  Note that other groups may also
      distribute working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as ``work
      in progress.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).

Abstract

   A system for Uniform Resource Names (URNs) must be capable of
   supporting new naming systems.  As an example of how a new namespace
   may be proposed, this document presents a naming system based on the
   RFC family of documents (RFCs, STDs, and FYIs) developed by the IETF
   and published by the RFC editor and the minutes of working groups
   (WG) and birds of a feather (BOF) meetings that occur during IETF
   conferences.  This namespace can be supported within the URN
   framework and the currently proposed syntax for URNs.

1. Namespace Syntax

   Consistent with the URN syntax specification [1], each namespace must
   specify syntax related information that is specific to that
   namespace.  This section covers these specifications.

Expires 1/31/98                                                 [Page 1]

INTERNET DRAFT     A URN Namespace for IETF Documents          July 1997

1.1. Namespace Identifier (NID)

   The namespace identifier for this namespace is "ietf".

1.2. Namespace Specific String (NSS)

   The Namespace Specific String has the following ABNF [2]
   specification:
           NSS = (family ":" number) / ("mtg-" number "-" wgbofname)

           family = "rfc" / "std" / "fyi"

           number = 1*DIGIT

           wgbofname = 1*LETDIGIT

           LETDIGIT = DIGIT / %x41..%x5a / %x61..%x7a

           DIGIT = %x30..%x39

   The ABNF specification for "family" is based on the current documents
   in the RFC family.  As new document series are added to the IETF
   family by the IESG (or its successor), this ABNF specification will
   need to be updated.  Any system intended to resolve names for this
   namespace should be written with the awareness that a new document
   series may be introduced at any time.

   The ABNF specification for "wgbofname" is based on the current and
   past abbreviations for working groups and BOFs in the IETF.  If a
   working group or BOF is created that used characters outside the
   range of this ABNF specification, this specification will need to be
   updated. Any system intended to resolve names for this namespace
   should be written with the awareness that this could occur at any
   time.

1.3. Assignment of URNs in this Namespace

   URNs are assigned in the namespace in two ways.  The first is when a
   new RFC, FYI or STD is passed by the IESG and published by the RFC
   Editor.  This new document will have a new series number and will
   therefore define a new URN.  The document mappings maintained by the
   RFC Editor (the index files "rfc-index.txt", "fyi-index.txt", "std-
   index.txt") are defined to be the definitive statement of the
   assignment of RFC Family URNs in this namespace.

   The second way a URN is assigned is when a working group or birds of
   a feather files meeting minutes as part of an IETF conference.  The
   list of minutes maintained by the IETF for each working group and

Expires 1/31/98                                                 [Page 2]

INTERNET DRAFT     A URN Namespace for IETF Documents          July 1997

   conference in the subtree pointed at by the URL ftp://ietf.org/ietf/
   is considered the definitive assignment of URNs for working group or
   birds of a feather minutes.

1.4. Additional Reserved Characters

   No characters in addition to those specified in [1] are reserved by
   this namespace.

1.5. Additional Lexical Equivalence Relations

   Note that the entire URN is case-insensitive, because of the
   definition of the NSS.

1.6. Functional Equivalence Relations

   Rules for equivalence in this namespace are embedded in the document
   mappings maintained by the RFC Editor (the index files "rfc-
   index.txt", "fyi-index.txt", "std-index.txt").  A resource is
   equivalent to the set of resources implied by the "(Also...)"
   construct in these mappings.  As an example, the URN
   "urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because
   the "rfc-index.txt" map shows that RFC 1661 is also STD 51.  However,
   the URN "urn:ietf:std:51" is equivalent to the SET of URNs
   "urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt"
   shows that STD 51 is also RFC 1661 and RFC 1662.  Therefore, a
   resolver receiving a N2R request for "urn:ietf:std:51" MUST return
   either STD 51 or BOTH RFC 1661 and RFC 1662.

2. Comments

   Readers will notice that this namespace does not include internet
   drafts.  While these documents are published by the internet drafts
   editor, they were excluded because they do not provide persistent
   resources to refer to (all internet drafts expire after six months).
   This is as opposed to the RFC family of documents which never expire
   (an RFC may be obsoleted or superceded but the actual RFC document
   itself does not expire).

3. Security Considerations

   Because this namespace defines no additional reserved characters, it
   does not add any security considerations beyond those inherent from
   the existence of the reserved characters from [1].  Further, the
   definition of the NSS above does not use any of the reserved
   characters from [1], which means that resolvers for this namespace
   may be considered "secure" in the sense that any escaping of
   characters in the NSS MUST result in the resolver indicating that the

Expires 1/31/98                                                 [Page 3]

INTERNET DRAFT     A URN Namespace for IETF Documents          July 1997

   URN has incorrect syntax.

4. Acknowledgments

   Thanks to various members of the URN working group for comments on
   earlier drafts of this document.  The work described in this document
   is partially supported by the National Science Foundation,
   Cooperative Agreement NCR-9218179.

4. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         R. Moats, "URN Syntax," RFC 2141, May 5, 1997.

         [2]         D. Crocker, P. Overell, "Augmented BNF for Syntax
                     Specifications: ABNF," Internet Draft (work in pro-
                     gress), January 1997.

5. Author's Address

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

   Phone:  +1 402 894-9456
   EMail:  [email-masked]

               This Internet Draft expires January 31, 1998.

Expires 1/31/98                                                 [Page 4]