Subject: [URN] Re: Hierarchical ownership of name spaces
From: Leslie Daigle <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: Patrik Faltstrom <[email-masked]>, [email-masked]
Date: Mon, 31 Mar 1997 21:54:51 -0500 (EST)

On Sun, 30 Mar 1997, Daniel LaLiberte wrote:
>  > Some entity is going to have to take responsibility for the namespace,
>  > in one fashion or another. This is what, to my way of thinking, makes
>  > URN namespaces more closely related to TLDs than to URL schemes.
> 
> The entity that takes responsibility for the definition of a name
> space could be something like IETF or W3C that is a cooperative
> effort, and part of that definition is how to delegate ownership to
> authorities.  In fact, that is what you are trying to do in defining

Yes, it _could_ be something like IETF or W3C; but in the case of something
like CORBA object IDs or ISBNs, I'd rather think that the entities
responsible for having developed the namespace will be involved in
the process of proposing them as URN namespaces, and thereby taking some
responsibility in their maintenance.

> Yes.  I suppose even that is ambiguous.  I meant to distinguish
> name registration from name resolution.
> 
>  > I'd like to disagree here. It certainly _can_ be tricky, in a
>  > namespace that is to guarantee global uniqueness and may have
>  > multiple assigners.
> 
> I don't see what is so hard.  With multiple assigners, one mechanism
> is to divy up the name space so that each assigner gets their own

Sure, it's easy to devise schemes for distributing it IF you are
starting the whole namespace from scratch.

By your model, then, in order for ISBNs to be used in URN space, they
would have to be _assignable_ by some distributable, published
mechanism that ensures automatic assignment is unique (and satisfies
every other criterion that the _developers_ of that namespace have
for their own purposes).

I, however, have been operating on the assumption that URNs should be
globally and publicly _resolvable_, while perhaps only privately _assigned_.
I.e., I still can't assign an ISBN (URN) if I am not a publisher having
signed whatever necessary agreements.

> or resolution; they decide that themselves.  You, and others, want to
> somehow *check* that the scheme they will be using will be following
> the rules before you give them their NID authority.  I don't think

The proposed work is to develop a system for globally unique, persistent
identifiers.

If we have _no_ requirements that participating namespaces produces either
unique or persistent identifiers, then what's the point?  I agree that
it is difficult to _ensure_ that namespaces do adhere to this, but if
we don't even make the effort to require it, well...!

> I want to set up a 'path' NID, and a 'http' NID.  Would you deny me?

We can discuss this again when the NID requirements draft is closer to 
being complete.

>  > If a namespace authority doesn't have the ability to manage its space,
>  > we will wind up with multiply-assigned and otherwise bogus URNs.
> 
> And you want to impose on the naming authority that they somehow avoid
> the hassles for the benefit of the world.  Doesn't the naming
> authority have a strong enough incentive without any external
> impositions?  Why will people choose to use URNs if they dont

If the na doesn't want to do this -- htere are plenty of other mechanisms
for producing identifiers.  URLs, for example...  I hear they can 
do virtually everything we're proposing for URNs...

> understand the benefit of avoiding the hassles in the first place?
> But if they do, then why do we need to step in to impose our vision of
> order?

Because some people _do_ feel the need for this order -- and that's
why they're participating in this process.

> But indeed, it becomes very complex to decide whether the unique id
> rule is being obeyed.  In the general case, how do we decide whether
> two objects are really the same and so can have the same name?  I
> don't think we want to get involved in making all those decisions.  We
> must delegate that decision.  Therefore, the problem of persistent
> registration becomes simple: it's not our problem.

Yes -- and I believe the NID requirements draft contains verbiage to
the effect that "different" is defined on a per namespace basis.  Namespaces
may choose to delgate that decision furhter down the food chain.

> We should delegate to naming authorities the decision as to whether
> they are following the naming rules to the extent that they feel is
> justified and desirable to their users.

I think this is effectively what I've just said -- so we agree on some
level.

The difference is that I believe namespaces, _when_proposed_ as_URN_namespaces,
should "agree" to adhere to some baseline requirements.  

Leslie.

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

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

From: "Ryan Moats" <[email-masked]>
To: "Dan Connolly" <[email-masked]>, "Daniel LaLiberte" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 31 Mar 97 13:32:55 
Priority: Normal
Subject: Re: [URN] urn: prefix is a brand name?
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Sun, 30 Mar 1997 13:27:37 -0600 (CST), Daniel LaLiberte wrote:

>Dan Connolly writes:
> > I found another one of the motivations for the urn: prefix,
> > (thanks for the pointer to the WAIS archive!)
> > and it worries me more than any of the other so far:
> > 
> > On Tue, 05 Nov 1996 23:16:17 -0500, Keith Moore wrote:
> > >This is why URNs need a URN: prefix -- because a lot of the value in
> > >having a URN name space with those properties is so *humans* can
> > >recognize a URN when they see it.
>
>We got to that point after my persistent (ha!) arguments that "urn:"
>doesn't mean much else.  Not everyone agrees with Keith on this point,
>of course.
>
>Ironically, Keith and others also argue for semantically meaningless
>numeric URNs and a higher layer of human friendly identifiers, so humans
>will hopefully never see the "urn:" prefix.

I have a little free time to devote to this, although I do have the gripe that
WG last call on this (urn syntax) has already passed...

Reasons that come to my mind for having "urn:" (I don't claim that anybody
else needs to agree with these...):

1. URNs are NOT URLs.

2.  As a corollary to #1, using the same space for URN NIDs and URL
schemes leads to greater collisions than keeping the spaces separate.  
For example, I can see a collision occurring between the "cid:" URL scheme
and a namespace of resources set up by some criminal investigation division
(The fact that there are multiple CID organizations in the US attached to
various police departments is an issue for the URN NID space
by itself).  Keeping these two spaces separate allows each to
deal with its own collisions and not worry about the other space.

3. Currently (based on my interpretation of URL schemes, your mileage may
vary), each and every URL scheme has a "resolution" "protocol" tied to it.
The URN working group is proposing that initially there be a set of "resolution"
"protocol(s)" for URNs tending toward a single resolution protocol.  All
of these are independent of the URN NID.  Using
"urn:" at the beginning of the URN provides a syntactic handle for 
browsers to recognize URNs as being distinct from URLs.

3a. (#3 has the result that URN-aware browsers do not have to be
modified if a new NID is defined as compared to what is required for
supporting a new URL scheme.  An addition to the "family" of resolution
protocols for URNs would require browser modification , but the direction
is for less URN resolution protocols rather than more).

Ryan Moats

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-resolution-services-00.txt
Date: Mon, 31 Mar 1997 09:35:39 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A New 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     : URN Resolution Services                                 
       Author(s) : M. Mealling, R. Daniel
       Filename  : draft-ietf-urn-resolution-services-00.txt
       Pages     : 6
       Date      : 03/28/1997

Fetching the resource identified by a Uniform Resource Identifier (URI) [3]
is only one of the operations that can be performed on a URI. We might ask 
for a list of other identifiers that are aliases for the original URI, a 
bibliographic description of the resource the URI denotes, etc. Because of 
the diverse nature of resources on the network, it may be difficult (or 
impossible) to offer all those operations, therefore a means of indicating 
what services are and are not supported by a given resolver must be 
specified. This memo gives an initial set of those operations, and the 
requirements that must be met when those operations are encoded in a 
protocol.                                                                  

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-resolution-services-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-resolution-services-00.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-resolution-services-00.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-resolution-services-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-nid-req-01.txt
Date: Mon, 31 Mar 1997 09:35:36 -0500
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     : Namespace Identifier Requirements for URN Services      
       Author(s) : R. Iannella, P. Faltstrom
       Filename  : draft-ietf-urn-nid-req-01.txt
       Pages     : 3
       Date      : 03/27/1997

Services that offer to resolve Uniform Resource Names implicitly require 
that they support a persistent and reliable service for an indeterminate 
length of time. This draft outlines the requirements for any such service 
that wishes to participate as a Namespace Identifier.                      

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-nid-req-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-nid-req-01.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-nid-req-01.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-nid-req-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 31 Mar 1997 03:09:39 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Daniel LaLiberte <[email-masked]>
Cc: "Ron Daniel, Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] Relative URNs considered harmful
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Daniel LaLiberte wrote:
> Ron Daniel, Jr. writes:
>  > During the earlier set of discussions my view on relative
>  > URNs changed from "unnecessary but probably harmless" to
>  > "unnecessary and probably harmful". Let me explain why.

I'll buy that check digits and relative URIs don't mix.
For the ISBN: scheme, we have to pick one. This
is a tradeoff between human-friendliness vs. functionality:
check digits imporove man-machine reliability, while hierarchical
names support scalable resolution, as Daniel says.

(R. Daniel, Daniel L, and Daniel C. -- lots of Dan's around here! :-)

> --------------
> 
> Now for the main reason that I believe relative URNs should be
> supported.  First, the reason is not so much for support of relative
> URNs themselves.  As much as they are useful, they are not essential
> since full URNs and relative URLs can be used too.  The real reason is
> that because relative URNs (of the hierarchical kind) require a
> publically visible hierarchy, that same hierarchy can be used by
> clients to support more scalable resolution.

That's my intuition too: there's a note in the NAPTR draft
about "the number of DNS queries approach one" that seems
VERY important.

I really want to see the details of the statistical
argument behind it.

> A principle I stated earlier that you agreed to is that with an ever
> increasing number of users, more of the work of resolving identifiers
> must be done by clients or servers near the clients. ...

Absolutely!

To put it another way: hierarchy is necessary to exploit
locality of reference, which is essential to scalability.

On the other hand, as I start to grok NAPTR fully, I realize
that it's about dynamically extending the URI naming conventions:

-----------------
http://services.bunyip.com:8000/research/ietf/urn-bof/urnframework.txt
draft-ietf-daigle-urnframework-00.txt

the Namespace ID is used to 
determine the _syntactic_ interpretation of the Namespace Specific
String to
the extent of extracting the Naming Authority information.
-----------------

Hmmm... all this regexp stuff is cool, but in order
to exploit locality of reference, we have to be able to
parse addresses from the other direction: from the
leaves toward the root. I'm suddenly perplexed as
to how to do that with NAPTR.

> With a hierarchically structured name space, resolution of an
> identifier can proceed by first looking up information in local caches
> about resolvers or RDSs for the most specific known subspace
> corresponding to some prefix of the identifier.  Only then do we need
> to ask remote servers to resolve the remainder, or look up resolvers,
> or whatever needs to be done.

DNS is one obvious example of this principle in action.
The COM Compose Moniker is another example:

----------------
http://www.microsoft.com/oledev/olecom/Ch11.htm#GenericComposite

Generic Composite Moniker-IMoniker::BindToObject

 Binding to a generic composite works in a right-to-left manner.
 Conceptually, the generic composite merely forwards the bind
 request onto its last piece, along the way informing that piece 
of the moniker to its left in the composite. The last piece, if it
 needs to,
 recursively binds to the object to its left. In practice, binding 
to a generic composite itself has to handle the recursive call on
the left-hand object, as was described in IMoniker::BindToObject.
-----------------

> Until there is a strong enough argument
> for how non-hierarchical name spaces can support scalable resolution,
> I would hesitate to disallow hierarchical name spaces.

That makes a lot of sense.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

From: Daniel LaLiberte <[email-masked]>
Date: Mon, 31 Mar 1997 01:36:24 -0600 (CST)
To: "Ron Daniel, Jr." <[email-masked]>
Cc: Dan Connolly <[email-masked]>, [email-masked]
Subject: [URN] Relative URNs considered harmful
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > During the earlier set of discussions my view on relative
 > URNs changed from "unnecessary but probably harmless" to
 > "unnecessary and probably harmful". Let me explain why.

My position has been that support for relative URNs is necessary,
but not for the reasons you argue against.  First, I'll argue against
your position and then put forward my own.

 > Unnecessary:
 > This is not the key point of controversy, but let me dispose of
 > it quickly.
 > 
 > Relative URLs came about for two reasons. The first was concision,
 > a reasonable consideration since we were all creating HTML my hand
 > using our editors. (Many of us still do, so this point has some
 > weight). The second reason was to make it easier to move connected
 > sets of resources from one site to another. If the links were relative,
 > there was less patching to do.
 > 
 > Since URNs are defined to be location independent, it is not the
 > documents that need to be edited if we want to move a bunch of
 > resources from one location to another. Therefore, the most important
 > reason for relative URLs does not apply to URNs.

Given the continued existence of relative URLs, I would agree that
relative URNs are not as necessary regarding the niche filled by
relative URLs.  However, you seem to be assuming that relative URLs
will be phased out to be replaced by URNs once they are available.  I
don't think so for a couple reasons.

First, what you called concision will still be significant, depending
on the lengths of URNs.  There is also the matter of other kinds of
convenience.  If one must go through some naming authority to first
assign names for all the parts of a structured document, this would be
more inconvenient than many people will tolerate.  If relative URLs
are easier to create and use than URNs, then people will continue to
use them.

Second, relative URLs will not lose their location-independence just
because URNs exist.  Once a document is found via some identifier,
whether a location or a name, the context of that document provides
all the info needed to find the other documents referenced via
relative URLs.  See below for more on how that is done.

But that is an argument for why relative URLs will continue to exist.
Part of the argument for why relative URNs will be useful is
similar.  Certainly a relative URN can be just as concise as a
relative URL.  And given a context for interpretation of a relative
URN, there is no problem in their use as another form of "location
independent" identifiers.  But there is another reason why
relative URNs will be useful which has to do with scalability.
See below for that argument.

 > Probably Harmful:
 > This will be more contentious, but here goes. This argument depends
 > on an observation:
 > 
 > Observation - a resource may have more than one URN.

It is good to remind people that a resource may have more than one
URN.  Some people have the mistaken belief that URNs will solve the
problem of knowing, by simple inspection, whether two different
identifiers are for the same resource.

 > We have used the weather map as one example of a resource having, at
 > least temporarily, two URNs.

I like that example.

 > [...]

 > All of these identifiers are reasonable candidates for URN namespaces.
 > If we were to follow Dan's suggestion of using "/" for hierarchy,

For clarification, both Dan Connolly and myself have suggested this.

 > (and our already-agreed upon use of "urn:") we would have

BTW, "urn:" *was* optional up until some unknown time.  Last mention I
heard of this optionality was a couple months ago when Karen Sollins
was arguing for why it causes ambiguity in the resolution process.  My
response to that got too close to the URN-URL debate and I was told to
stop.

So when was the official decision made to require "urn:"?

 >     urn:isbn:0/679/45446/2
 >     urn:upc:9/780679/454465  
 >     urn:lc:96/34802
 > 
 > The problem with relative URNs is that there is no consistent hierarchy
 > across all identification schemes.

There doesn't need to be one hierarchy for all schemes.  In fact, it
is usual for there to be separate hierarchies for each scheme, if
there is a hierarchy at all, and only rarely will there be any overlap,
unless there is some transition in progress.  Clearly relative URNs
cannot be relative to multiple incompatible URN contexts at the same
time.  But this is not a problem for relative URNs because the *one*
context for their interpretation should be known to the author or
provider of the document, and this context should be made known to the
client.

 > Assuming Le Carre's work referred
 > to another using the relative identifier "4", what does that mean?

It would mean the one thing that is appropriate, and nothing more.
More on that below.

 > Is it
 >     urn:isbn:0/679/45446/4    // An illegal ISBN since we have only
 >                               // munged the check character.

So the ISBN hierarchy we guessed at doesn't work because of embedded
check chars.  One of two things can be done.  Give up on ISBN as a
hierarchy, or further map the name space to remove the check character
to make it a proper hierarchy.  Or perhaps the check character can
always be appended as part of the last component, not the last
component itself.  e.g. 45446,4 or whatever is appropriate - I don't
grok the ISBN notation.

But perhaps ISBN doesnt help as a hierarchy anyway because higher
levels (prefixes of the path) never represent reasonable, useful
collections.  If there is hardly ever any reason to refer to other
members of a collection with a relative URI, then there is no point in
making the name space hierarchical.  More on semantic organization below.

 >     urn:upc:9/780679/4        // This might work, except that once again
 >                               // the check character has probably been munged.
 >                               // I haven't read the UPC rules lately, I think
 >                               // the initial "9" is the check character.

Then the name space would have to be mapped to something that worked
hierarchically.  But, again, only if it is useful.

 >     urn:lc:96/4               // this might work

Seems a bit short for a unique ID.  

 > Other possibilities are to take the URL that was used to fetch the resource
 > (assuming there was one) and use the relative identifier "4" in conjunction
 > with it.

If there was a URL involved in actually fetching the resource, and
if the relative URI rules are followed and it is determined that that
URL is what should be used for the base, then so be it.

 > The difficulty of correctly dealing with check characters is only one
 > of the problems with relative URNs. The big point is that there is no
 > uniform hierarchy across all namespaces, and without one it is unsafe
 > to do relative URI processing. We have to know the original identifier the
 > new one is relative to.

We have to know the intended identifier or context that any relative
identifier is relative to.  Yes.  This is not a problem.  This is by
design.

Even without relative URNs, the same potential problem arises for
relative URLs when the same resource may be accessed by different
URLs, each with incompatible hierarchies.  For example, a symbolic
link to a document may create a second access path to the same document,
and relative URLs within the document may be correct relative to one
path but not the other.  (I can be more explicit in this example if
you want.)  The solution is that in such a situation, the document
should have a BASE specification of some kind to say which path
is correct.

 > The last time we took up this topic, Dan LaLiberte presented the very
 > nice set of rules that are used in relative URL processing to answer
 > this question. Lets go through those and see if they apply to URNs.

And I clarified the rules regarding chains of indirections.

 > From: Daniel LaLiberte 
 > Date: Fri, 31 Jan 1997 16:34:21 -0600 (CST)
 > >... finding the base URI ...
 > >Use the first one that succeeds:
 > >
 > >1. Use the explicit base URI from the document content, if any.
 > >2. Use the explicit base URI from the encapsulating entity, if any.
 > >   (e.g. http response message, another document, etc)
 > >3. Use the URI used to retrieve the entity, if any.
 > >4. Otherwise the base URI is undefined.
 > >
 > >Step 3 should be clarified: If there is no explicit base URI
 > >found by step 1 and 2, we should use the *last* URI used
 > >to retrieve the entity, not the first or some intermediate.  This
 > >applies both for a chain of URL redirections or for a URN that is
 > >resolved into a URL.  Roy Fielding pointed this out to me when I
 > >thought it should be the first URI used, or perhaps the last
 > >permanent redirect.
 > 
 > Step one seems dodgy for our example, we have the equivalent of three
 > BASE tags. (Don't tell me there should be only one, the book was printed
 > with three.)

I can only tell you there must be only one.  We do not have the
equivalent of three BASE tags.  If you still think so, then you
haven't understood the rules.  If there are multiple URNs that a
document is accessed by, and the document contains relative URNs, then
the author or creator of the document must have one of those name
spaces in mind when using relative URNs.  Which one it is should be
specified in the BASE tag.

This doesn't mean the other URNs will not work.  They will work, and
when a relative URN is encountered, the appropriate context will be
known and used instead of the URN you accessed the document by.
Problem solved.

 > Steps 2 and 3 suffer from the same problem. Over long time scales, there is
 > no telling what sort of URI will be used to fetch the thing. Assuming
 > that it will have the same hierarchy as the original seems dangerous.
 
Maybe it is now clear where you misunderstood.  If steps 2 or 3 are
used, then the same answer as above applies.  If relative URNs are
used by an author knowing that they are intended to be persistent,
then the author is essentially promising that the hierarchy implied by
those relative URNs will persist.  Relative URNs correspond to full
URNs and a promise of persistence is a promise either way.  

Note that this concern about a possibly changing hierarchy should be
divorced from issues of filesystem organization, as I argued in
earlier messages.  I'll dig that out if you want it repeated.

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

Now for the main reason that I believe relative URNs should be
supported.  First, the reason is not so much for support of relative
URNs themselves.  As much as they are useful, they are not essential
since full URNs and relative URLs can be used too.  The real reason is
that because relative URNs (of the hierarchical kind) require a
publically visible hierarchy, that same hierarchy can be used by
clients to support more scalable resolution.  I'll explain.

A principle I stated earlier that you agreed to is that with an ever
increasing number of users, more of the work of resolving identifiers
must be done by clients or servers near the clients.  If, in
attempting to resolve a name, we have no clues about where to start
other than at the top of the URN space, because the naming authority
is not previously known, then we must go to the top to find out about
the naming authority.  Once we know where that naming authority is and
have info on its associated resolvers, we can resolve other URNs that
have the same naming authority starting with the same resolvers.  But
if there is no subdivision of this naming authority's name space that
is visible to clients, then all future resolutions of names in the
name space must go through the very same resolvers.  Those resolvers
will become increasingly busy in proportion to the number of users and
URNs in that space.  Caches of documents will only help for those
individual documents, but every document in the same space is
independent of every other document since there are no collections or
subspaces within the space to start the resolution from.

With a hierarchically structured name space, resolution of an
identifier can proceed by first looking up information in local caches
about resolvers or RDSs for the most specific known subspace
corresponding to some prefix of the identifier.  Only then do we need
to ask remote servers to resolve the remainder, or look up resolvers,
or whatever needs to be done.

Maybe you didn't intend to argue against hierarchical name spaces
but only against relative URNs.  Well, once you have hierarchical
name spaces, then relative URNs come for free.  The only overhead
is the same as for relative URLs - being clear about the context.

There may actually be another way to get a similar kind of scalable,
mostly local resolution without a visible hierarchy (and thus without
support for relative URNs).  Instead of extracting structure from
the identifier, the client must do a sequence of transformations of
the identifier into intermediate states of some kind until ultimately
the resource is found.  If the intermediate states are also
identifiers, then this is equivalent to a sequence of indirections.
These transformations can be done locally based on locally cached code
that directs the transformation (such as regular expressions or Java
appets).  But to be scalable, it must be the case that we can reuse
previously retrieved transformation code, otherwise we will be always
asking remote servers for the appropriate code, and nothing will have
been gained.  This seems possible, if the name space is effectively,
though not visibly, organized, but there is another overriding
concern.

In order for any caching to useful in the first place, there must
be some locality of reference to take advantage of.  Locality of
reference means that the next reference to something new is similar to
previous references.  "Similar to" means semantically related or some
how related in a way that is meaningful to the human user.  You don't
typically read publication #97-1489 just because you have read
#97-1488 unless there is some relationship between the two.  If your
next reference is completely independent from previous references,
there is likely to be no information in local caches to help you.

So if there is to be some semantic organization of the name space to
promote caching, then hierarchy is one common way things are
organized.  The hierarchy may not be visible in identifiers, and
may only be in an invisible hierarchy of transformations, but I don't
understand the advantage of always and only remaining invisible.
If you are thinking along these lines, please explain.

A matrix space is another way to organize things, but I haven't
thought enough about it.

So yes, I hope we can come to consensus on the issue of relative URNs.
We should agree that they must be allowed, along with allowing
hierarchial name spaces.  Until there is a strong enough argument
for how non-hierarchical name spaces can support scalable resolution,
I would hesitate to disallow hierarchical name spaces.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

From: Daniel LaLiberte <[email-masked]>
Date: Sun, 30 Mar 1997 13:51:36 -0600 (CST)
To: "Ron Daniel, Jr." <[email-masked]>
Cc: Dan Connolly <[email-masked]>, [email-masked]
Subject: [URN] name-ness
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Let's continue this in private mail, but I just want to state that my
position is slightly different.  The name-ness of an identifier is, I
agree, not a property of the identifier, but it is a property of how
it is resolved.  That resolution may result in another identifier, and
thus we have your relationship.  But the resolution may instead result
in something other than another identifier, such as a URC or the
resource itself.  In general, what makes an identifier have the
name-ness property is that it can continue to be resolved (to the same
resource) if it is still resolvable.  If it can't be resolved, the
identifier may still be useful as an identity for comparison purposes.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

From: Daniel LaLiberte <[email-masked]>
Date: Sun, 30 Mar 1997 13:27:37 -0600 (CST)
To: Dan Connolly <[email-masked]>
Cc: [email-masked]
Subject: [URN] urn: prefix is a brand name?
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Dan Connolly writes:
 > I found another one of the motivations for the urn: prefix,
 > (thanks for the pointer to the WAIS archive!)
 > and it worries me more than any of the other so far:
 > 
 > On Tue, 05 Nov 1996 23:16:17 -0500, Keith Moore wrote:
 > >This is why URNs need a URN: prefix -- because a lot of the value in
 > >having a URN name space with those properties is so *humans* can
 > >recognize a URN when they see it.

We got to that point after my persistent (ha!) arguments that "urn:"
doesn't mean much else.  Not everyone agrees with Keith on this point,
of course.

Ironically, Keith and others also argue for semantically meaningless
numeric URNs and a higher layer of human friendly identifiers, so humans
will hopefully never see the "urn:" prefix.

I think the real value of "urn:" has nothing to do with the notion of
names, but that it is associated with a new resolution mechanism, the
NAPTR mechanism. And the reason this is valuable is that it is very
hard to deploy any new resolution mechanism whatsoever.  But once
deployed, this mechanism is general enough that it can be applied to
all URIs, so the prefix might as well have been "uri:".

I recognize that this association between "urn:" and the NAPTR
mechanism is contrary to the intent of the working group, but intent
is irrelevant compared to actual practice.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

From: Daniel LaLiberte <[email-masked]>
Date: Sun, 30 Mar 1997 12:58:02 -0600 (CST)
To: Leslie Daigle <[email-masked]>
Cc: Patrik Faltstrom <[email-masked]>, [email-masked]
Subject: [URN] Hierarchical ownership of name spaces
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Leslie Daigle writes:
 > Thanks, Dan, for a lot of comments [...]

You are welcome. Only trying to help.

 > > Who registers a name space if anyone can, in fact, resolve identifiers
 > > in the name space?  Does someone "own" the name space?  Some name
 > 
 > Some entity is going to have to take responsibility for the namespace,
 > in one fashion or another. This is what, to my way of thinking, makes
 > URN namespaces more closely related to TLDs than to URL schemes.

The entity that takes responsibility for the definition of a name
space could be something like IETF or W3C that is a cooperative
effort, and part of that definition is how to delegate ownership to
authorities.  In fact, that is what you are trying to do in defining
the "URN" scheme.  On the other hand, any subtree of an HTTP URL is
setup and hopefully maintained by some entity,
e.g. http://union.ncsa.uiuc.edu/.  The 'edu' part is maintained very
publically, the 'uiuc' part much less publically, the 'ncsa' part even
less so, and I maintain the 'union' part myself.  So for both URNs and
URLs (the others are much like HTTP), there are some higher levels of
public cooperation, and lower levels that are more privately owned.

 > > What is so hard about managing the NID registration process?
 > 
 > If by "NID registration process" you mean the process of registering
 > names within a NID (and not the process of creating a new NID),

Yes.  I suppose even that is ambiguous.  I meant to distinguish
name registration from name resolution.

 > I'd like to disagree here. It certainly _can_ be tricky, in a
 > namespace that is to guarantee global uniqueness and may have
 > multiple assigners.

I don't see what is so hard.  With multiple assigners, one mechanism
is to divy up the name space so that each assigner gets their own
unique part.  Another mechanism is to do it in a centralized manner
from one name space, and provide a simple service that increments a
number to generate a unique id, or if more meaningful ids are desired,
checks whether a particular id is already in use before authorizing
it.  The volume of registration requests is far below the volume of
resolution requests, so there is not really a scalability question to
deal with for most name spaces.  On the other hand, OMG might wish to
set up a name space for CORBA objects, in which case, many more
objects might need ids that will ever be used.  In that case,
delegation of the registration process works far better than
centralization.

 > I.e., the point is not to just find A way to
 > come up with unique names, it's to accommodate many namespaces as
 > HAVE this ability.

I don't understand what you mean by accommodate.  We don't have to
determine how NID authorities will in fact do their name registration
or resolution; they decide that themselves.  You, and others, want to
somehow *check* that the scheme they will be using will be following
the rules before you give them their NID authority.  I don't think
that checking is desirable.  You become a target for all kinds of
legal hassles.  Nor is it not practical since you would never know
that all of your criteria are necessary or sufficient?  The questions
will always outnumber the answers until you decide to delegate.

I want to set up a 'path' NID, and a 'http' NID.  Would you deny me?

 > If a namespace authority doesn't have the ability to manage its space,
 > we will wind up with multiply-assigned and otherwise bogus URNs.

And you want to impose on the naming authority that they somehow avoid
the hassles for the benefit of the world.  Doesn't the naming
authority have a strong enough incentive without any external
impositions?  Why will people choose to use URNs if they dont
understand the benefit of avoiding the hassles in the first place?
But if they do, then why do we need to step in to impose our vision of
order?

These are not easy questions and I don't mean to suggest they are.  At
issue is the very same kind of question people deal with when
considering whether welfare should be controlled by the federal
government or delegated to the states.  The best answer is usually
some kind of compromise.  My belief is that central control should
generally only be imposed where distributed control fails to be
sufficient.

 > >  >   - One URN should never be reused for a different resource (where
 > >  >     "different" is defined as in previous paragraph by the namespace).
 > > 
 > > This is persistent registration.  Not at all difficult.
 > 
 > I'm not sure I see what you mean here.  Someone who is proposing a
 > namespace must agree to not reassign URNs.  It's a requirement,
 > it's hard to enforce (my favourite example of "Today's weather in
 > Montreal" gif vs.  "Weather in Montreal on Mar 28/97" gif -- same
 > binary file, different object -- different names).

What I first meant by "not at all difficult" is that it is trivial to
create a new id that you know has never been used before.

But indeed, it becomes very complex to decide whether the unique id
rule is being obeyed.  In the general case, how do we decide whether
two objects are really the same and so can have the same name?  I
don't think we want to get involved in making all those decisions.  We
must delegate that decision.  Therefore, the problem of persistent
registration becomes simple: it's not our problem.

 > > There is another way to deal with all this much more simply: in a
 > > nutshell, delegate hierarchically and let each authority deal with
 > > meeting the requirements.  Anything more invasive is asking for
 > > trouble.
 > 
 > Again, I think I've missed part of your point -- what is to be delegated
 > to whom in the hierarchy (and are we talking about the same hierarchy)?  

The hierarchy I am talking about is the same one Karen mentioned in
her recent RDS requirements proposal.  It is a hierarchy of naming
authorities.  It can appear in an identifier between the first and
second colon as a hierarchical naming authority id, or after the
second colon as a hierarchical path, or before the first colon if we
allow hierarchical scheme names.  The hierarchy might not appear in an
identifier at all, but only be visible in a chain of resolution steps,
each one delegating to the next.

We should delegate to naming authorities the decision as to whether
they are following the naming rules to the extent that they feel is
justified and desirable to their users.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Date: Sat, 29 Mar 1997 21:51:41 PST
From: Larry Masinter <[email-masked]>
Organization: PARC
To: "Ron Daniel, Jr." <[email-masked]>
Cc: Dan Connolly <[email-masked]>, [email-masked]
Subject: Re: [URN] Relative URNs considered harmful
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Only one of the many sources of the "base" URL for relative references
is "the URL of the document itself". And only one of the many sources
of relative references are "within the document".

"Please give me frob and its embedded images" might be done with
relative naming, but it's probably useful to work out the details
of naming of collections and composite objects and at least
decide if the URN for chapter 1 should have any syntactic
relationship to the URN for the book before claiming 
to be "done" with URNs. (How *else* would you refer to
chapter one of ISBN 0-679-45446-2? <ISBN:0-679-45446-2#chapter=1>?)

Larry

Larry
--
http://www.parc.xerox.com/masinter

Date: Sat, 29 Mar 1997 14:37:35 -0700
To: Dan Connolly <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 02:39 AM 3/29/97 -0600, Dan Connolly wrote:

>I hope I can convince you that the "locator-ness" or an
>one identifier (L) or the "name-ness" of another identifier (N)
>isn't a property of the identifiers themselves, but rather a
>relationship between them.

Well, you can try, but I have to warn you that I find it
valuable to distinguish between names and addresses.

Also, if you want to try to change my mind on that subject,
this list is not the place to do it, because that distinction
is axiomatic to this group.

I'll send you another message out of band to tell you why I think
that axiom is justified.
>This leads to my criticism of L2L and N2N: what is it
>that I learn about l1 with respect to l2
>when a service says L2L(l1) = l2 that I would not learn
>from I2I(l1) = l2?

You learn that l2 is not a URN, since the I2I(l1) may return either
a URL or a URN.

>But I do think that only one equivalence relation is needed,
>not three. I think I made a better argument above.

I'm sorry, but unless we change the axioms of this working
group, I don't see how we can get away from the need to specify
the desired output format. That means that we need I2N, I2L and
I2I.

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: Sat, 29 Mar 1997 14:37:33 -0700
To: Dan Connolly <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: [URN] Relative URNs considered harmful
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 01:58 PM 3/28/97 -0600, Dan Connolly wrote:
>But do you see the technical benefits of exploiting the
>URI hierarchy syntax? It allows the use of relative
>URLs. It remains to be seen whether they would be used
>in the ISBN context as much as they are in the http:
>and ftp: contexts. But the technical benefit is there.

Awhile back this group started to discuss relative URNs.
Although that discussion has peetered out, no conclusion
was reached. Now that the various people have had a chance
take a breath and regroup their arguments, I'll take
Dan Connolly's message as a springboard to resume them.
Perhaps we will come to consensus on the point and settle it.

During the earlier set of discussions my view on relative
URNs changed from "unnecessary but probably harmless" to
"unnecessary and probably harmful". Let me explain why.

Unnecessary:
This is not the key point of controversy, but let me dispose of
it quickly.

Relative URLs came about for two reasons. The first was concision,
a reasonable consideration since we were all creating HTML my hand
using our editors. (Many of us still do, so this point has some
weight). The second reason was to make it easier to move connected
sets of resources from one site to another. If the links were relative,
there was less patching to do.

Since URNs are defined to be location independent, it is not the
documents that need to be edited if we want to move a bunch of
resources from one location to another. Therefore, the most important
reason for relative URLs does not apply to URNs.

Probably Harmful:
This will be more contentious, but here goes. This argument depends
on an observation:

Observation - a resource may have more than one URN.
We have used the weather map as one example of a resource having, at
least temporarily, two URNs. Another example is more telling. Pick
a recently-published book from your shelf. Chances are excellent that
it will have at least two, and probably three, separate identifiers.
The first book I've grabbed is "The Tailor of Panama" by Le Carre. (Ok,
sue me for my reading tastes).  It has the identifiers:
   ISBN  0-679-45446-2
   UPC   9 780679 454465  
   LC    96-34802

Essentially all books currently pulished will have the first two.
The last is the Lib. Congress Card Number. As part of the "Cataloging
in Publication" effort, many books will be printed with the third.
(Look on the title page of the book you grabbed to see if has "CIP"
on it somewhere. That's the Cataloging In Publication stuff.)

All of these identifiers are reasonable candidates for URN namespaces.
If we were to follow Dan's suggestion of using "/" for hierarchy,
(and our already-agreed upon use of "urn:") we would have
    urn:isbn:0/679/45446/2
    urn:upc:9/780679/454465  
    urn:lc:96/34802

The problem with relative URNs is that there is no consistent hierarchy
across all identification schemes. Assuming Le Carre's work referred
to another using the relative identifier "4", what does that mean?
Is it
    urn:isbn:0/679/45446/4    // An illegal ISBN since we have only
                              // munged the check character.
    urn:upc:9/780679/4        // This might work, except that once again
                              // the check character has probably been munged.
                              // I haven't read the UPC rules lately, I think
                              // the initial "9" is the check character.
    urn:lc:96/4               // this might work

Other possibilities are to take the URL that was used to fetch the resource
(assuming there was one) and use the relative identifier "4" in conjunction
with it.

The difficulty of correctly dealing with check characters is only one
of the problems with relative URNs. The big point is that there is no
uniform hierarchy across all namespaces, and without one it is unsafe
to do relative URI processing. We have to know the original identifier the
new one is relative to.

The last time we took up this topic, Dan LaLiberte presented the very
nice set of rules that are used in relative URL processing to answer
this question. Lets go through those and see if they apply to URNs.

From: Daniel LaLiberte 
Date: Fri, 31 Jan 1997 16:34:21 -0600 (CST)
>... finding the base URI ...
>Use the first one that succeeds:
>
>1. Use the explicit base URI from the document content, if any.
>2. Use the explicit base URI from the encapsulating entity, if any.
>   (e.g. http response message, another document, etc)
>3. Use the URI used to retrieve the entity, if any.
>4. Otherwise the base URI is undefined.
>
>Step 3 should be clarified: If there is no explicit base URI
>found by step 1 and 2, we should use the *last* URI used
>to retrieve the entity, not the first or some intermediate.  This
>applies both for a chain of URL redirections or for a URN that is
>resolved into a URL.  Roy Fielding pointed this out to me when I
>thought it should be the first URI used, or perhaps the last
>permanent redirect.

Step one seems dodgy for our example, we have the equivalent of three
BASE tags. (Don't tell me there should be only one, the book was printed
with three.)

Steps 2 and 3 suffer from the same problem. Over long time scales, there is
no telling what sort of URI will be used to fetch the thing. Assuming
that it will have the same hierarchy as the original seems dangerous.

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: Sat, 29 Mar 1997 03:26:26 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: [email-masked]
Subject: [URN] urn: prefix is a brand name?
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

I found another one of the motivations for the urn: prefix,
(thanks for the pointer to the WAIS archive!)
and it worries me more than any of the other so far:

On Tue, 05 Nov 1996 23:16:17 -0500, Keith Moore wrote:
>This is why URNs need a URN: prefix -- because a lot of the value in
>having a URN name space with those properties is so *humans* can
>recognize a URN when they see it.

In effect, this says that urn: is intended to act as a sort
of trusted brand name, kinda like "RFC" in a way.

It seems to me that DUNS and ISBN already have that brand
name trust, and adding urn: on the front doesn't really
add anything.

The RFC brand name is based on the tradition of excellence
and the process of the IETF. It's trust in the IETF
as an institution. (Ironically, I gather that the term
'RFC' is being decommissioned because of misuse...)

Is this working group attempting to give urn: the same sort
of status? Are we setting the IETF up to be the institution
that guarantees that identifiers are managed well and
work reliably? I suppose that's what the NID requirements
document is all about. It delegates the bulk of the
work of operating the namespace, but squarely places ultimate
responsibilty on the IETF to review new NIDs.

But what about enforcement? Once a NID is registered, what's
to prevent it from running amok or going away?

It seems to me that draft-nid-req is making a commitment
on behalf of the IETF (or IANA) to maintain the urn: brand name
in perpetuity. I don't believe the IETF is the sort of
organization that can do that. Maintaining registries of
technical details like protocol port numbers is one thing,
but sitting at the root of the world's information hierarchy
is quite another. The IAHC says folks need $5M of liability
insurance to do that sort of thing.

By the way... Is the procss for registering a subdomain of .urn.net
the same as the process of allocating a new NID? If so,
that would seem to break the independence of namespaces
from resolution mechanisms.

If not, what are the
rules for the administration of the .urn.net domain?
It seems to me that the .urn.net is going to be more
relevant, since new records in .urn.net propagate
automatically, as opposed to traditional standards
deployment from NID registrations.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Sat, 29 Mar 1997 02:39:15 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: "Ron Daniel, Jr." <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Ron Daniel, Jr. wrote:
> At 04:06 PM 3/28/97 -0600, Dan Connolly wrote:
> >there seem to be
> >five sorts of things: names (N), locations (L), identifers (I),
> >resource instances (R) and URCs (C). It seems like there are only
> >finitely many interesting permutations.

Forget I said this. My argument doesn't even convince me any more.

> >If the list is extensible, it's extremely important to
> >specify what to do when you find an unknown operation and in
> >general, how new operations get deployed.

> (We may need to mandate that clients MUST NOT try to deal with unknown
> services, it was probably an unspoken assumption of mine).

Yes: write it down.

> >Yes, there are very useful _extrinsic_ distinctions between names
> >and addresses: external to the identifier, there might be
> >information that suggests it can be resolved or not, etc.

> OK, here I think we can agree. I don't see a lot of useful difference
> between L2L and N2L, so the operations of I2L, I2N, I2C, I2R (and their
> plural forms) may be sufficient. We can also have I2I, I2Is for when
> we don't need to maintain the distinction on the output.

I hope I can convince you that the "locator-ness" or an
one identifier (L) or the "name-ness" of another identifier (N)
isn't a property of the identifiers themselves, but rather a
relationship between them. If a service says N2L(N) = L, then
it's claiming that "L is a locator for N," not that L is
a locator in all contexts. L might also be a name with respect to
some other identifier L2 in another context.

Now... how to do that... I think I can only appeal to
design aesthetics, e.g. minimalism.

This leads to my criticism of L2L and N2N: what is it
that I learn about l1 with respect to l2
when a service says L2L(l1) = l2 that I would not learn
from I2I(l1) = l2?

> >RFC1630 is informational, not standards track. I suggest you
> >cite either the url syntax draft, or RFC1808, which I expect
> >will be updated/replaced by the ultimate url syntax draft.
> 
> The problem is that RFC 1630 sets the model of URIs being the
> superset of URNs and URLs. The other documents you specify
> standardize URLs. I am unaware of a standards-track URI
> specification.

Ironic, no? I hope and expect that the URL syntax document
and the URN syntax document will be merged into a URI
syntax document.

> You really mean that there's
> >no relationship whatsoever between the N2L and the L2N operations?
> 
> None that I wish to specify.
> 
> ... I would be more inclined to warn client implementors that
> they should not assume it.

If that's your intent, I think you need to be explicit. The
names suggest that they're inverses.

> > It seems clear to me that if n is a URN
> >and l is a URL, then you can be certain that I2I(n) won't
> >return l and vice versa.
> 
> That is not at all clear to me. In fact, the converse is what seems
> clear to me. If we say "map this I to another I", and we say that
> Ns and Ls are both instances of I, then we should expect either as
> a result.

You're right. I don't know what I was thinking.

> >> >> 4.10 I2I (URI to URI):
> [Dan states he thinks it is unneeded and wants to...]
> >try yet another argument:
> >
> >Suppose we had relations:
> >       N2N <: URN x URN
> >and
> >       L2L <: URL x URL
> >
> >If the intersection of URNs and URLs is empty (fair assumption?)
> >then N2N and L2L don't intersect. So one relation I2I that
> >is the union of L2L and N2N holds all the information from
> >both relations without creating any ambiguity.
> 
> OK, here's the gap in our models. You seem to assume that URNs
> and URLs are partitioned to such an extent that providing a URN
> (or URL) as an input to I2I automatically restricts the output of
> the operation to the input type. I don't.

Aha... yes, that argument is garbage: it assumes an overly
narrow notion of I2I.

But I do think that only one equivalence relation is needed,
not three. I think I made a better argument above.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Sat, 29 Mar 1997 02:07:00 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Leslie Daigle <[email-masked]>
Cc: [email-masked]
Subject: Rationale for urn: requested [was: [URN] draft-ietf-urn-nid-req-01.txt]
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Leslie Daigle wrote:
>If you have an idea of a specific
> paragraph that belongs in a specific document, do _please_ make the
> suggestion to the list.

I suggest that section 2. "Syntax" of
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-syntax-04.txt

reflect the rationale for the urn: prefix. I don't have specific
wording to suggest because I don't understand the rationale.

Your message is the closest thing I've seen to evidence to
support this design. (Thank you! Finally!) But...

> Specifically, there were people who said they _needed_ the syntactic
> cue for their purposes  of using URNs, and no one who said they could
> not deal with it.

Sigh... I can sympathize with this. I'm guilty of chairing
enough meetings with this sort of compromise. But I really
don't like it, and I want to be really sure that the
choices were carefully considered, and that the resolution
is explicitly written down in the specs.

> Some of the desire for having the syntactic cue are for resolution
> reasons (e.g., being able to hand that _class_ of identifiers to a specific
> proxy that knows about existing RDS's),

I find this idea of a urn: proxy worrisome: the intent of the
URI design was that clients should be able to send _all_ unknown
URI schemes to a "default proxy." That Netscape 2.x, for example,
recognizes and proxies urn: but not isbn: is a hack and a kludge.

> and some are for weighting
> clues (e.g., prefer URNs to URLs).  _Yes_, you could keep a table fo which
> identifier was which type, but that's an implementation answer, and does
> not seem to be what general concensus said people wanted.

You can also keep these sorts of "hints" outside the identifier.
For example, HTML has separate attributes for HREF= and URN=.

So I don't find any of that evidence compelling.

I haven't read the entire URN-WG archive, but I have read much
of it, plus all of the following:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-syntax-04.txt
http://www.acl.lanl.gov/URN/http_res.txt
http://www.bunyip.com/research/ietf/urn-bof/urnframework.txt
http://www.netlib.org/utk/projects/rcds/rcds-tr/

and a bunch of other stuff, and I haven't found these
implementors' claims that the urn: cue is necessary or even useful.

> This issue was specifically brought up at the meeting in San Jose, and
> was documented in the minutes.   See
> 
>         http://www.bunyip.com/research/ietf/urn-ietf/sanjose.txt

As I wrote in another message: I did that: but the minutes only
state the conclusion. They don't give any of the evidence or reasons.

And anyway, in the IETF, the consensus at an IETF meeting
isn't binding: all official business is conducted via email.
(At least that's my understanding. Please correct me if
I'm wrong.)

> (by the way -- http://www.bunyip.com/research/ietf/urn-ietf  also
> contains the text of the group's charter).

Thanks for the URL! I'd like to see a few more of them flying
around here. Finding drafts etc. in email archives is kinda tedious.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Fri, 28 Mar 1997 21:37:28 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

One thing I want to flag...

On Fri, 28 Mar 1997, Dan Connolly wrote:
> Karen R. Sollins wrote:
> >  Hence there is a certain burden of
> > proof on the proposer of an identification (URN) namespace that does
> > not hold true for a location (URL) namespace.
> 
> Hmm... OK, if there are some process rules that we believe
> will result in more persistent, reliable names, then it's
> worth writing them down.
> 
> I think it's a contractual issue, and not worth specifying in
> a technical sense. But that's just my intuition, and in the
> case of process, the relevant question is whether the participants
> of the IETF are willing to standardize some contractual
> properites. It seems that you/they/we are, so away we go...

True, it's not technical in the sense that it won't affect code.  But,
it _is_ an important component of the technical architecture in that it
is also a statement of what we think this system can and cannot support.
I.e., we will give persistent, unique, global names as long as input
meets X, Y, and Z criteria.

> 
> 	URN:ISBN:4534-345-345
> 
> which syntactically binds the name to the URN process contract,
> it seems sufficient to write
> 
> 	ISBN:23423-234-234
> 
> and have the ISBN scheme specification say "this scheme
> conforms to the URN process contract."

This issue was specifically brought up at the meeting in San Jose, and
was documented in the minutes.   See

	http://www.bunyip.com/research/ietf/urn-ietf/sanjose.txt

(by the way -- http://www.bunyip.com/research/ietf/urn-ietf  also
contains the text of the group's charter).

Specifically, there were people who said they _needed_ the syntactic
cue for their purposes  of using URNs, and no one who said they could
not deal with it.

Some of the desire for having the syntactic cue are for resolution
reasons (e.g., being able to hand that _class_ of identifiers to a specific
proxy that knows about existing RDS's), and some are for weighting
clues (e.g., prefer URNs to URLs).  _Yes_, you could keep a table fo which
identifier was which type, but that's an implementation answer, and does
not seem to be what general concensus said people wanted.

> If not, please somebody explain why not, and write it
> up in a spec, and let's review it.

It has been discussed ad nauseum, and was put to bed with the syntax
document following the San Jose meeting.  If you have an idea of a specific
paragraph that belongs in a specific document, do _please_ make the
suggestion to the list.

If you think there is more to be discussed here about the issue, I will
ask you to first forward your agruments to me, and if there is new material
we can take the discussion to the list.

Thanks!
Leslie.

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

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

Date: Fri, 28 Mar 1997 21:21:38 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: "Ron Daniel, Jr." <[email-masked]>, Patrik Faltstrom <[email-masked]>, [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Fri, 28 Mar 1997, Dan Connolly wrote:
> I'm happy to see the URN-WG concern itself only with URI
> schemes that seem like names. But I'm not happy with URLs
> and URNs being gratuitously incompatible.

Incompatibilities are not gratuitous -- this list discussed many of
those issues  a couple of months ago. Ryan Moats put together a
WAIS-indexed archive of the [email-masked] mailing list, 
accessible via http://ds.internic.net/ds/urnwais.html, if you missed that
thread.

> If there is to be a registry of URI schemes, I just want
> one of them. (and I think automating it in the .urn.net
> domain is a cool idea!)

BTW, do bear in mind NAPTR is an experimental _implementation_ of the proposed
architecture.  

> letter, then the case of the rest of the identifier doesn't
> matter... or something like that. In any case, let's have
> one syntax debate, not two.

Hmmm.  I assume these remarks were addressed to the URL process list, which
I removed from the CC line.  If not, see archives..

Leslie.

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

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

Date: Fri, 28 Mar 1997 21:10:26 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: [email-masked], Patrik Faltstrom <[email-masked]>
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

I didn't see anyone having replied to your first comments about mailing
lists...

On Fri, 28 Mar 1997, Dan Connolly wrote:
> 	[email-masked] -->
> 		??? (defunct URI WG; anything else?)

When the URI WG was shut down, it was suggested that hte [email-masked] 
mailing list be kept open for any UR* business that seemed to span
across (or lie outside of) existing UR? subgroups.  It's a catch-all
mailing list when no other will do.  I've taken it off the cc list
here, because this matter falls within the URN wg.

Leslie.

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

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

Date: Fri, 28 Mar 1997 21:05:31 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: Patrik Faltstrom <[email-masked]>, [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Thu, 27 Mar 1997, Daniel LaLiberte wrote:
> Regardless of whether it is a new newspace or an existing one, there
> is a separation between the definition of the name space and the
> resolution service(s) for that space.

Thanks, Dan, for a lot of comments sorting out where the paper fails
to distinguish between the two, or balances over to focusing on
resolution issues.

A few comments...

> Who registers a name space if anyone can, in fact, resolve identifiers
> in the name space?  Does someone "own" the name space?  Some name

Some entity is going to have to take responsibility for the namespace,
in one fashion or another. This is what, to my way of thinking, makes
URN namespaces more closely related to TLDs than to URL schemes.

>  >   - Demonstrated experience in managing an established namespace
>  >     system is essential.    
> 
> What is so hard about managing the NID registration process?

If by "NID registration process" you mean the process of registering
names within a NID (and not the process of creating a new NID), I'd
like to disagree here. It certainly _can_ be tricky, in a namespace
that is to guarantee global uniqueness and may have multiple assigners.
I.e., the point is not to just find A way to come up with unique
names, it's to accommodate many namespaces as HAVE this ability.

If a namespace authority doesn't have the ability to manage its space,
we will wind up with multiply-assigned and otherwise bogus URNs.

>  >   - One URN should never be reused for a different resource (where
>  >     "different" is defined as in previous paragraph by the namespace).
> 
> This is persistent registration.  Not at all difficult.

I'm not sure I see what you mean here.  Someone who is proposing a namespace 
must agree to not reassign URNs.   It's a requirement, it's hard to
enforce (my favourite example of "Today's weather in Montreal" gif vs.
"Weather in Montreal on Mar 28/97" gif -- same binary file, different
object -- different names).

> There is another way to deal with all this much more simply: in a
> nutshell, delegate hierarchically and let each authority deal with
> meeting the requirements.  Anything more invasive is asking for
> trouble.

Again, I think I've missed part of your point -- what is to be delegated
to whom in the hierarchy (and are we talking about the same hierarchy)?  

Leslie.

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

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

Date: Fri, 28 Mar 1997 16:50:20 -0700
To: Dan Connolly <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 04:06 PM 3/28/97 -0600, Dan Connolly wrote:
>Ron Daniel, Jr. wrote:

>there seem to be
>five sorts of things: names (N), locations (L), identifers (I),
>resource instances (R) and URCs (C). It seems like there are only
>finitely many interesting permutations. 

Sure, but this argument rests on two assumptions:
  1) There are only five things
  2) only some permutations are interesting

The second one is not crucial, its only a compactness sort of thing.
I'm not really comfortable with the idea of stating that our information
universe is composed out of 5 elements.  Maybe it is, but I suspect not.
Just as N and L are specializations of I, we could look for specializations
of R (versions, translations,... spring to mind). Do we need to distinguish
them? If we set extension rules we can argue that later and cope with the
stuff for our immediate needs now.

>Say... that reminds me: what about C2R, C2I, C2N, C2L?

Yeah, they would be useful, but I am not ready to propose
something on how to handle all the problems of dealing with
format and schema differences of the incoming URC, specifying
the format and schema for the outgoing URC (or type for
resources, etc.), and the real bear of the query language
that the '2' expands into. I wanted to get the quick wins
out of this and deal with the harder stuff some other time.

>If the list is extensible, it's extremely important to
>specify what to do when you find an unknown operation and in
>general, how new operations get deployed. I'll
>have to look at the NAPTR draft etc. to be sure this
>is covered.

NAPTR can handle this 2 ways. I prefer the first. Servers advertise
the services they can provide, clients know the ones they can support.
So, there is no backward incompatability problem with servers offering
new services, clients know they can't handle them and don't ask for them.
(We may need to mandate that clients MUST NOT try to deal with unknown
services, it was probably an unspoken assumption of mine). The only
problem is if we don't have a controlled list of the services, in that
case we could have incompatible interpretations of the same label. Michael's
document probably needs to be augmented with an IANA list.

If this is not satisfactory, then the second way is to use a new flag
to indicate the presence of extended service definitions. The NAPTR spec
states that clients MUST ignore records with an unknown flag. However,
we could burn a lot of flags if the extensions come in dribs and drabs.

>> >Note that N and L are both URIs. Hence my second point:
>> >the distinction between URNs and URLs isn't necessary.
>> 
>> Yes and no. Both are URIs, so an I2I method would suffice at that level.
>> However, this group distinguishes between names and addresses.
>
>Yes, there are very useful _extrinsic_ distinctions between names
>and addresses: external to the identifier, there might be
>information that suggests it can be resolved or not, etc. I just
>object to a separation of the space of URL schemes and
>the space of URN schemes and to the separation of URL syntax
>from URN syntax.

I'll take that up in a seperate message. For now I will assume we
continue to distinguish between the two, and we want a syntactic
handle (urn:) to aid in the quick discrimination of them.

>> If I have
>> a name and want to get an address, we need an N2L operation.
>
>I don't dispute the utility of a N2L operation: I just don't
>see any reason to restrict the input to URNs.

OK, here I think we can agree. I don't see a lot of useful difference
between L2L and N2L, so the operations of I2L, I2N, I2C, I2R (and their
plural forms) may be sufficient. We can also have I2I, I2Is for when
we don't need to maintain the distinction on the output.

>> >> 4.2 N2Ls (URN to URLs)
>> >> This operation is used to map a single URN to 0 or more URLs.
>> >
>> >
>> >This one becomes:
>> >       Given a URI N, Return a set of URIs L[i] such that there
>> >       is a link from N to L[i] of type "N2L" for each i.
>> 
>> I'm sorry Dan, but I really don't see the benefit of your suggested
>> rewordings.
>
>It's mostly a matter of taste.

Actually I should have revisited my remark after I had gotten further into
your reply. When you suggest the generic relationship thing then the
notation offers some benefit.

>But there is a little substance
>to it: I expect this document to specify not just black-box
>operations, but also some properties of those operations that
>relate the operations to each other.

But the notation doesn't state those properties, it only states
that a link of type "N2L" or whatever exists. The description of
properties still has to be supplied. We can look int providing
such descrption of properties in the revision of the draft.

>For example, there seems to be, latent in the services-01 draft,
>a relation
>	N2L <: URI x URI
>that relates the N2L and the N2Ls operations: if computing
>N2L(n) yields l, then the pair (n,l) is in the N2L relation;
>meanwhile, if N2Ls(n) yields l[i], then (n, l[i]) is in the N2L
>relation for each i. This connection is implied by the naming
>etc., but not specified explicitly anywhere.

Agreed. Such notation is not my normal mode of expression, but
the next version of the draft should state this one way or another.

>RFC1630 is informational, not standards track. I suggest you
>cite either the url syntax draft, or RFC1808, which I expect
>will be updated/replaced by the ultimate url syntax draft.

The problem is that RFC 1630 sets the model of URIs being the
superset of URNs and URLs. The other documents you specify
standardize URLs. I am unaware of a standards-track URI
specification. 

[On the subject of metadata schemas, formats, ...]

>> THTTP says that people should use format negotiation if they want
>> a partiular format. We are not defining the one true URC format.
>
>Sure... but the MIME type of the result isn't the same as
>the schema.

Whoops. Of course. My error.

> Lots of metadata schemas can be represented
>as text/sgml. Or do you intend to fold the mime-type axis
>and the schema axis into one?

Certainly not. Somewhere there is a statement that IMTs are not to
represent schemas.

I had been assuming that the URC return format would indicate the
schema it followed. If we need to extend the model so that the
client can ask the server to provide the URC in a particular
schema, I think we need some serious discussion on that topic.

>And about PICS... it specifies ways to encode metadata
>requests into HTTP GET operations. Seems to me THTTP is
>doing the same thing. If they can do it the same way,
>that seems like a Good Thing. I still haven't gotten
>around to THTTP yet.

and I haven't gotten around to catching up on the latest stuff
with PICS. However, I doubt they are the same ways. THTTP is
not intended to be standards-track. A real standards-track
document on how to use HTTP to talk with a resolver should
probably make I2L, I2C, ... into new methods. THTTP is a
trivial way to do it with GET. It lets us do experiments now
with NAPTR, which is a more serious proposal. (It is also
targeted for experimental, but for different reasons).

>> >Something that I think should be specified: is L2N expected
>> >to be the inverse of N2L?
>> 
>> Nope. If a resource has multiple URNs and URLs, I don't think we should
>> mandate any particular behavior on the part of resolvers to make stronger
>> mappings between the identifiers.
>
>I said 'expected,' not mandated. You really mean that there's
>no relationship whatsoever between the N2L and the L2N operations?

None that I wish to specify.

I expect resolvers to do a variety of things with N2L. They may
try to return the "closest" URL to the client, or one at random,
etc. Given that a resolver has a set of URNs and URLs for a single
resource, I don't want to require that n = L2N(N2L(n)), and I
don't particularly want to suggest it as expected behavior. In
fact, I would be more inclined to warn client implementors that
they should not assume it.

>> >> 4.8 L2Ls (URL to URLs)
>> >> This operation is used to discover URLs that are considered equal to
each
>> >> other.
>> >
>> >This one is clearly supposed to be an equivalence relation.
>> >If N2N is also an equivalence relation, then I don't understand
>> >the distiction.
>> 
>> See earlier discussions on names vs. addresses.
>
>I don't see that it applies. Could you elaborate?

Its just a simple permutation of N and L. We added the I2L and other
operations with I at the last minute. With your recent suggestions
we will probably use I2N and I2L instead of N2N, N2L, N2I, L2L, N2N, L2I.

>If there's an I2I operation, why is L2L necessary? why is
>N2N necessary?

Because we want control over the output forms of the I. Sometimes
we want an address and sometimes we want a name. Distinguishing the
input types doesn't seem so important since they can be self-describing
because of the URN prefix.

> It seems clear to me that if n is a URN
>and l is a URL, then you can be certain that I2I(n) won't
>return l and vice versa.

That is not at all clear to me. In fact, the converse is what seems
clear to me. If we say "map this I to another I", and we say that
Ns and Ls are both instances of I, then we should expect either as
a result.

>The relationship between two URLs that are equivalent 
>is identical to the relationship between two URNs that
>are equivalent. What motivates three different operations
>to deal with this one relationship?

I currently think that I2L, I2N, and I2I are the minimal set if
we want to maintain the axiomatic distinction between Ns and Ls.
What do you think now?

>> >       S2D(URI S, URI T) -> set of URIs D[i]
>> 
>> Hmmm, sounds pretty good. The first question that comes up is that
>> sometimes we are happy mapping from one URI to another, and other times
>> we want to get back a specific type of URI (URN or URL). So, we need to
>> modify your earlier definition and this suggestion for the generic
>> operation.
>
>I'll buy that; so you might call them IT2I, IT2L, and IT2I.
>(for identifery/type to identifer, ...).

We may want to take this idea further in other messages, but not this one.
Its already too long.

>> >> 4.10 I2I (URI to URI):
[Dan states he thinks it is unneeded and wants to...]
>try yet another argument:
>
>Suppose we had relations:
>	N2N <: URN x URN
>and
>	L2L <: URL x URL
>
>If the intersection of URNs and URLs is empty (fair assumption?)
>then N2N and L2L don't intersect. So one relation I2I that
>is the union of L2L and N2N holds all the information from
>both relations without creating any ambiguity.

OK, here's the gap in our models. You seem to assume that URNs
and URLs are partitioned to such an extent that providing a URN
(or URL) as an input to I2I automatically restricts the output of
the operation to the input type. I don't. I assume that
a resolver has a set of URNs and a set of URLs, but that sometimes
we won't care about keeping them distinct. When we don't care,
we say "I" and either a URL or URN is fine.

>> >> 4.11 I=I (Is URI equal to URI):
>But again: the relationship between I=I and I2I should be
>specified, but isn't. For example, if I2I(x) yields y, then
>I would expect I=I(x,y) to return true, right?

Yes. We need to add these descriptions.

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: Fri, 28 Mar 1997 16:06:25 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: "Ron Daniel, Jr." <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Ron Daniel, Jr. wrote:
> Some of your comments should probably be directed to
> the THTTP draft instead.

I think so too.
 
> >My intuition says that we're after a fiarly small set
> >of primitives that doesn't need to be expanded:
> 
> I think it is fairly small, but I'm unwilling to assume it won't need
> to be expanded.

Hmm... we just disagree. Any other opinions?

I suppose the burden of proof is on me to show that the list
has an end. Hmm... I can't come up with anything
beyond an aesthetic arguments: there seem to be
five sorts of things: names (N), locations (L), identifers (I),
resource instances (R) and URCs (C). It seems like there are only
finitely many interesting permutations. In regexp terms,
the set looks like:

	[NLIRC]I?2[NLIC]s?

Say... that reminds me: what about C2R, C2I, C2N, C2L?
i.e. given a URC (aka a description or query) return
one (or a set of) resource instances, identifiers, names,
or locations? Seems like a lot of search and directory services
(and HTTP/HTML forms) offer those services. The WEBDAV
group is considering standardizing a convention for
such an operation in HTTP.

Anyway...

If the list is extensible, it's extremely important to
specify what to do when you find an unknown operation and in
general, how new operations get deployed. I'll
have to look at the NAPTR draft etc. to be sure this
is covered.

> >Note that N and L are both URIs. Hence my second point:
> >the distinction between URNs and URLs isn't necessary.
> 
> Yes and no. Both are URIs, so an I2I method would suffice at that level.
> However, this group distinguishes between names and addresses.

Yes, there are very useful _extrinsic_ distinctions between names
and addresses: external to the identifier, there might be
information that suggests it can be resolved or not, etc. I just
object to a separation of the space of URL schemes and
the space of URN schemes and to the separation of URL syntax
from URN syntax.

> If I have
> a name and want to get an address, we need an N2L operation.

I don't dispute the utility of a N2L operation: I just don't
see any reason to restrict the input to URNs.
The N2L operation captures the very useful
"located-at" relation, e.g. document X is located at Y. But
is there some reason to disallow something like the following?

	N2Ls(ftp://ds.internic.net/rfc/rfc1866.txt)

Seems awfully useful to me to find all the replicas/variants of
rfc1866 known to some service. Is one of the other operations
intended to cover this question?

> >> 4.2 N2Ls (URN to URLs)
> >> This operation is used to map a single URN to 0 or more URLs.
> >
> >
> >This one becomes:
> >       Given a URI N, Return a set of URIs L[i] such that there
> >       is a link from N to L[i] of type "N2L" for each i.
> 
> I'm sorry Dan, but I really don't see the benefit of your suggested
> rewordings.

It's mostly a matter of taste. But there is a little substance
to it: I expect this document to specify not just black-box
operations, but also some properties of those operations that
relate the operations to each other.

For example, there seems to be, latent in the services-01 draft,
a relation
	N2L <: URI x URI
that relates the N2L and the N2Ls operations: if computing
N2L(n) yields l, then the pair (n,l) is in the N2L relation;
meanwhile, if N2Ls(n) yields l[i], then (n, l[i]) is in the N2L
relation for each i. This connection is implied by the naming
etc., but not specified explicitly anywhere.

There are all sorts of issues around authenticity, consistency,
freshness, and all that which fall outside the scope of this
sort of specification. But there are _some_ semantics
of the N2L and N2Ls operations that can be specified, no?

> >> All URIs shall be encoded according to the URI specification [6].
> >
> >I can't find reference 6. I'm terribly curious to know which
> >document you're citing for URI syntax.
> 
> RFC 1630 is what we normally use, I'm not sure if that is what Michael
> was intending to cite or not. (The problems with preparing a draft
> right before the deadline).

RFC1630 is informational, not standards track. I suggest you
cite either the url syntax draft, or RFC1808, which I expect
will be updated/replaced by the ultimate url syntax draft.

> >It has another parameter though: the metadata schema
> >that the URCs should conform to.
> >
> >Hmm... I'll have to look closely at THTTP to see if
> >it's gratuitiously different from PICS.
> 
> THTTP says that people should use format negotiation if they want
> a partiular format. We are not defining the one true URC format.

Sure... but the MIME type of the result isn't the same as
the schema. Lots of metadata schemas can be represented
as text/sgml. Or do you intend to fold the mime-type axis
and the schema axis into one?

And about PICS... it specifies ways to encode metadata
requests into HTTP GET operations. Seems to me THTTP is
doing the same thing. If they can do it the same way,
that seems like a Good Thing. I still haven't gotten
around to THTTP yet.

> >Something that I think should be specified: is L2N expected
> >to be the inverse of N2L?
> 
> Nope. If a resource has multiple URNs and URLs, I don't think we should
> mandate any particular behavior on the part of resolvers to make stronger
> mappings between the identifiers.

I said 'expected,' not mandated. You really mean that there's
no relationship whatsoever between the N2L and the L2N operations?

> >> 4.8 L2Ls (URL to URLs)
> >> This operation is used to discover URLs that are considered equal to each
> >> other.
> >
> >This one is clearly supposed to be an equivalence relation.
> >If N2N is also an equivalence relation, then I don't understand
> >the distiction.
> 
> See earlier discussions on names vs. addresses.

I don't see that it applies. Could you elaborate?

If there's an I2I operation, why is L2L necessary? why is
N2N necessary? It seems clear to me that if n is a URN
and l is a URL, then you can be certain that I2I(n) won't
return l and vice versa.

The relationship between two URLs that are equivalent 
is identical to the relationship between two URNs that
are equivalent. What motivates three different operations
to deal with this one relationship?

> >       S2D(URI S, URI T) -> set of URIs D[i]
> 
> Hmmm, sounds pretty good. The first question that comes up is that
> sometimes we are happy mapping from one URI to another, and other times
> we want to get back a specific type of URI (URN or URL). So, we need to
> modify your earlier definition and this suggestion for the generic
> operation.

I'll buy that; so you might call them IT2I, IT2L, and IT2I.
(for identifery/type to identifer, ...).

> >> 4.10 I2I (URI to URI):
> >> This operation is used to map any arbitrary URI to any other arbitrary URI.
> >
> >Again, I don't see the reason for more than one equivalence
> >relation.
> 
> Please reconsider this in light of this group's axiom that URNs and
> URLs are both URIs, but are not equivalent.

I see that; but it doesn't motivate more than one equivalence
relation. I'll try yet another argument:

Suppose we had relations:
	N2N <: URN x URN
and
	L2L <: URL x URL

If the intersection of URNs and URLs is empty (fair assumption?)
then N2N and L2L don't intersect. So one relation I2I that
is the union of L2L and N2N holds all the information from
both relations without creating any ambiguity.

> >> 4.11 I=I (Is URI equal to URI):
> >> This operation is used to determine whether two given URIs are
> considered to
> >> be equal by the server being asked the question.
> >
> >And again.
> 
> Um, are you sure about this Dan? This isn't requesting that a mapping
> be performed, its a predicate on the existance of such a mapping.

Ah... no, I was confused. I see now.

But again: the relationship between I=I and I2I should be
specified, but isn't. For example, if I2I(x) yields y, then
I would expect I=I(x,y) to return true, right?

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Fri, 28 Mar 1997 15:00:42 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Karen R. Sollins wrote:
>  Hence there is a certain burden of
> proof on the proposer of an identification (URN) namespace that does
> not hold true for a location (URL) namespace.

Hmm... OK, if there are some process rules that we believe
will result in more persistent, reliable names, then it's
worth writing them down.

I think it's a contractual issue, and not worth specifying in
a technical sense. But that's just my intuition, and in the
case of process, the relevant question is whether the participants
of the IETF are willing to standardize some contractual
properites. It seems that you/they/we are, so away we go...

But it seems perfectly feasible, to me, for the connection
between a URI and this URN process contract to be
outside the identifier itself. That is, rather than

	URN:ISBN:4534-345-345

which syntactically binds the name to the URN process contract,
it seems sufficient to write

	ISBN:23423-234-234

and have the ISBN scheme specification say "this scheme
conforms to the URN process contract."

If not, please somebody explain why not, and write it
up in a spec, and let's review it.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Fri, 28 Mar 1997 14:48:55 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: "Ron Daniel, Jr." <[email-masked]>
Cc: Patrik Faltstrom <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Ron Daniel, Jr. wrote:
> At 03:13 AM 3/28/97 -0600, Dan Connolly wrote:
> >See also, RFC1630 (informational)
> 
> Gee Dan, when I read 1630 it says things like:
> 
> "For existing Internet access protocols, it is necessary in most
> cases to define the encoding of the access algorithm into something
> concise enough to be termed address. URIs which refer to objects
> according to existing protocols are known as "Uniform Resource
> Locators" (URL)s ..."
> 
> and
> 
> "There is currently a drive to define a space of more persistent names
> than any URLs. These "Uniform Resource Names" are the subject of an
> IETF working group discussions."  (The group he was referring to was
> URI-WG. They are now being discussed in the more tightly focused URN-WG).
> 
> Tim drew a pretty clear distinction between address and names.
> Addresses had a mapping to Internet Protocols, names did not.

But he didn't distinguish between the space of addressing schemes
and the space of naming schemes. The value of keeping those
spaces together is incredibly high: the aspect of the web
from which it derives its tremenous value is it universal
information space.
 
> The URN-WG's charter is based on that distinction, so any followups
> should drop it from the CC list.

I'm happy to see the URN-WG concern itself only with URI
schemes that seem like names. But I'm not happy with URLs
and URNs being gratuitously incompatible.

If there is to be a registry of URI schemes, I just want
one of them. (and I think automating it in the .urn.net
domain is a cool idea!)

I want shared syntax rules too: if case-insensitivity is
critical for reliability (and I could easily agree that
it is), then let's make URLs case insensitive. I know zillions
of users will thank us. Or perhaps we can come up with
some convention where if the URI scheme starts with a capital
letter, then the case of the rest of the identifier doesn't
matter... or something like that. In any case, let's have
one syntax debate, not two.

I'm sorry if my comments are out of order with respect to
the existing URN-WG charter (I can't find the URL WG
charter); but the URL specs are in revision,
and I see a clear opportunity to finally write down the
rules for the space of uniform resource identifiers.
This is the sort of architectural integrity that the IETF
is all about, no?

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Fri, 28 Mar 1997 14:38:23 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Patrik Faltstrom <[email-masked]>
Cc: [email-masked], Cecilia Preston <[email-masked]>
Subject: Reasons for URN:? [was: [URN] draft Bibliographic Identifiers to URNs]
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Patrik Faltstrom wrote: 
> On Fri, 28 Mar 1997, Dan Connolly wrote:
> > Cecilia Preston wrote:
> > > Example: URN:ISBN:0-395-36341-1
> > Huh? Why the URN:? Why not just ISBN:0-395-36341-1?

> We have been through this a bizillion times, and at the last IETF we
> concluded that the URN: _must_ be there because of the functional
> differences on what a URL and a URN is.

I have been party to many of the "bizillion" debates, and I
have yet to see a coherent argument. I just keep hearing
"we have to because... well... we just have to."

> We can _NOT_ start this debate again.

If there's really a good argument for the urn: prefix,
then somebody should be prepared to write it down in
a specification and defend it. I am doing my level
best to read the relevant documents, and I don't see it
anywhere.

I think there's some really good work going on in this
working group, and I'm doing my best to ensure the quality
of the results by carefully reviewing the documents. I'm
really glad to see ISBN numbers formally integrated into
the web, and I think NAPTR is really cool. But the value
of having URLs and URNs share the same space of schemes
and the same syntactic space
is SO great that I will defend it vigorously until
convinced that the cost of splitting them is justified.

>  Sorry if I sound harch Dan, but you
> have to look in the email archives for argumentation, and see the minutes
> from the San Jose IETF.

Yes, it's up to me to read the archives etc. I'm doing my best.

OK, here's what I see:

-------------
ftp://ftp.ietf.org/ietf/urn/urn-minutes-96dec.txt

URN: should this be optional.  Please see the later discussion on 
this for the consensus.  

...

Open Discussion:

URN:  There was a question of rough consensus on the problem of 
whether to require urn:.  The room seems to indicate that urn: 
should be required on any part of the urn that was shipped around 
the Internet.  Whether or not implementors would use urn: was 
left up to them for their own local products, but in transmission 
the urn: would be required.  The problem with urn: seems to be at 
the user interface and user services level.  Don't confuse human 
friendly names with internal representation.
--------------

Sorry, I still don't see the agrument that leads to the
conclusion that urn: is necessary.

> > I guess I've got problems with the
> > draft-ietf-urn-nid-req. Basically: why is it a different
> > document from the URL process document? But that's fodder
> > for another message.
> 
> It is different because we have different requirements on the NID than a
> URL scheme. Maybe we can use the same process, but different requirements?

It seems to me that different URI schemes will have different
characteristics: some will be fast and break a lot, and
some will be slow but more reliable. Some schemes won't
have any resolution mechanisms at all. Some will cost a lot,
and some will be free. Great.

But why separate the list of URL schemes from the list of
URN schemes? Each scheme defines a contract between the
community that uses the naming scheme. Folks enter the
contract or not voluntarily.

I don't mean to dismiss the URN requirements, but I think
it's a horrible kludge to make two lists (URL schemes
vs. URN schemes) when one list will do just fine. And
the same goes for syntax: we need one URI syntax, not
one for URLs and a different one for URNs. If there's
something wrong with the URL syntax, let's fix it,
rather than gratuitously creating another world.

> This was something I argued with Tim about 1992 already, and I have been
> arguing about this since...as the others being in Stockholm/Helsinki when
> this was discussed: Peter Deutsch, Chris Weider, Mark McCahill, Alan
> Emtage, Tim, Joyce Reynolds, Anders Gillner et.al.

So? If there's one lesson I've learned from my IETF/web standards
experience, it's that until the arguments are captured in
a document and the document is ratified, there's no reason
to expect them to stop.

> We others basically
> wanted to have some things fixed in HTTP/HTML _BEFORE_ it was sent to
> "the masses":
> 
>   + The ability of _not_ having stateless connections on top of TCP
>     between a client and a server.

These are begin hammered out in the HTTP 1.1, HTTP state management
specs. Keeping the session ID in the URL is also a viable option.

>   + The ability of formatting www-pages in a better way (look at TeX)
>     because people want tables, windows (what is now frames) and the
>     ability of changing fonts, sizes, layout commands like putting things
>     side by side.

See:

Cascading Style Sheets, level 1 
     17 December 1996, Håkon W. Lie and Bert Bos 
http://www.w3.org/pub/WWW/TR/REC-CSS1-961217.html

Positioning HTML Elements with Cascading Style Sheets 
     31 January 1997, Robert Stevahn, Scott Furman, Scott Isaacs 
http://www.w3.org/pub/WWW/TR/WD-positioning

>   + The problem that you don't know what you are fetching in HTTP until
>     the HTML header arrives, i.e. you have to start fetching before you
>     see what you get. Look at ol' Gopher+ and the attributes in the
>     links.....

Metadata hints about what sort of information is at the
other end of a link is being addressed. For example, there
are TYPE attributes on the STYLE and OBJECT tags:

http://www.w3.org/pub/WWW/TR/WD-style
http://www.w3.org/pub/WWW/TR/WD-object

> I see that the same things are still discussed and many are fixed in new
> versions of HTML/HTTP...
> 
> Anyway, I just wanted to point out that these things that start to get
> discussed over and over again has been discussed forever...and they will
> probably always be discussed forever.

A published, ratified specification can go a long way toward
resolving these debates.

> Can anyone write an FAQ? Until we have one, we can not blame _anyone_ for
> asking these questions over and over again.

I want more than a FAQ: I want the urn: prefix decision
defended in a standards-track document. Otherwise,
the high quality IEFT design principles including
minimalism demand that it be tossed out.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Fri, 28 Mar 1997 13:58:49 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Cecilia Preston <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] draft Bibliographic Identifiers to URNs
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Cecilia Preston wrote:
> >> Example: URN:ISBN:0-395-36341-1
...
> >Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
> >make more sense.
> >
> 
> You are imposing your hierarchical
>path name model into a space that is
> defined by community to have hyphens and had done so since the mid 1960's.
> 
> Furthermore it is not up to the URN community to direct the use of that
> part of the space, that is up to the Namespace ID.  Please remember that
> this document is intended to illustrate how existing namespaces schemes can
> work within the URN syntax.

Hmm... I can see the social benefits of using the syntax
that the community is familiar with.

But do you see the technical benefits of exploiting the
URI hierarchy syntax? It allows the use of relative
URLs. It remains to be seen whether they would be used
in the ISBN context as much as they are in the http:
and ftp: contexts. But the technical benefit is there.

And it's not _my_ model -- it's the IETF standard model,
per RFC1808. (well... proposed standard). And I'm
not imposing it; I'm suggesting it.

If this working group has explicitly considered the costs
and benefits of both sides, and as a result, chosen
to go with the human-friendly syntax rather than the
syntax that exploits URL hierarchy, then I think that
deserves mention in the specification.

I suggest the following wording:

	NOTE: The ISBN space is hierarchical, and RFC1808
	(and RFC1630) might suggest that the '/' character
	be used to separate parts of the name. However,
	the value of doing so is not evident, and is believed
	to be significantly less than the value of using
	the '-' syntax that the community is familiar with.

	Using the '-' syntax, visual comparison of ISBN URNs
	with printed ISBN numbers is easier. And the '-' syntax
	facilitates copy-and-paste from extant ISBN numbers
	in ASCII, which generally use the '-' syntax.

I am being told that these issues have been debated at length
and resolved -- but I can't find the results in the relavent
documents. Let's get these arguments written down. That's the
way to stop blabber-mouths like myself from bringing them
up again and again!

The irony of the argument behind using '-' rather than '/'
is that it directly conflicts with the charter of this
working group:

===========
http://www.bunyip.com/research/ietf/urn-ietf/

Although the framework will allow URNs to
be defined that vary in terms of degree of scalability
and persistance, ensuring "user friendliness" of all resultant
identifiers is beyond the
scope of this group. 
===========

I disagree with that part of the charter: the "user friendliness"
aspects of identifiers have a tangible impact on the reliability
of the network infrastructure and on the deployment of
these technologies. For that reason, they should be carefully
considered.

I suppose comments on the charter are somewhat out of order.
I apologize, and I will try to take them up in the right
venue. But I just wanted to write them down before I forget.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-nid-req-00.txt
Date: Fri, 28 Mar 1997 10:16:40 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A New 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     : Namespace Identifier Requirements for URN Services      
       Author(s) : R. Iannella, P. Faltstrom
       Filename  : draft-ietf-urn-nid-req-00.txt
       Pages     : 3
       Date      : 03/27/1997

Services that offer to resolve Uniform Resource Names implicitly require 
that they support a persistent and reliable service for an indeterminate 
length of time. This draft outlines the requirements for any such service 
that wishes to participate as a Namespace Identifier.                      

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-nid-req-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-nid-req-00.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-nid-req-00.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-nid-req-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 28 Mar 1997 12:02:28 -0700
To: Dan Connolly <[email-masked]>, [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 01:52 AM 3/28/97 -0600, Dan Connolly wrote:
>Short version:
>	(1) I suggest link types be integrated into this
>	design and
>	(2) as a result, I think that URLs and URNs can
>	be used interchangeably
>	(3) I think N2C needs another parameter to
>	specify the schema of the URC.

Short version of my reply:

1)
A few of your responses assume a much stronger link to HTTP than is
appropriate for this document. HTTP is only one of the protocols that
coud be used for a client to converse with a resolver. Z39.50, HDL,
... are others. Some of your comments should probably be directed to
the THTTP draft instead.

2)
The Name/Location thing comes up again. This group's charter is based
on the model that there is a distinction. Therefore that distinction is
axiomatic in our deliberations. So, some of your suggestions, such as
replacing N2L, L2N, ... with a single I2I operation need to be
re-examined in that light.

3)
I like the suggestions about considering part/whole and generic/specific
relations in addition to the generalized equivalance relation.

>Details:
>Michael Mealling wrote:
>> This memo gives an initial set of those operations, and the
>> requirements that must be met when those operations are encoded in a
>> protocol.
>
>"intial set" gives me the willies. Do you mean to imply
>that you'll specify the rest of the list some day? If so,
>say so.

The intent is that others may want to add operations later.

>Are the names of these operations expected to be used
>literally in extensible fields in protocols?

No, when someone proposes to use a new protocol for URN resolution, they
need to specify how these operations are mapped to tht protocol. It may
be literal use of the names, it may be something else.

>My intuition says that we're after a fiarly small set
>of primitives that doesn't need to be expanded:

I think it is fairly small, but I'm unwilling to assume it won't need
to be expanded.

>Note that N and L are both URIs. Hence my second point:
>the distinction between URNs and URLs isn't necessary.

Yes and no. Both are URIs, so an I2I method would suffice at that level.
However, this group distinguishes between names and addresses. If I have
a name and want to get an address, we need an N2L operation.

>> 4.2 N2Ls (URN to URLs)
>> This operation is used to map a single URN to 0 or more URLs.
>
>
>This one becomes:
>	Given a URI N, Return a set of URIs L[i] such that there
>	is a link from N to L[i] of type "N2L" for each i.

I'm sorry Dan, but I really don't see the benefit of your suggested
rewordings.

>> All URIs shall be encoded according to the URI specification [6].
>
>I can't find reference 6. I'm terribly curious to know which
>document you're citing for URI syntax.

RFC 1630 is what we normally use, I'm not sure if that is what Michael
was intending to cite or not. (The problems with preparing a draft
right before the deadline).

>> 4.5 N2C (URN to URC)
>...
>> URCs (Uniform Resource Characteristics) are descriptions of other
resources.
>> This request allows the client to obtain a description of the resource
>> identified by a URN, as opposed to the resource itself or simply the
>> resources URLs.
>
>FYI, the PICS spec gives an example of this operation:
>	http://www.w3.org/pub/WWW/PICS/labels.html#Requesting
>
>It has another parameter though: the metadata schema
>that the URCs should conform to.
>
>Hmm... I'll have to look closely at THTTP to see if
>it's gratuitiously different from PICS.

THTTP says that people should use format negotiation if they want
a partiular format. We are not defining the one true URC format.
In the absence of format negotiation, the resolver is free to send back
the URC info in any format it pleases. PICS, SOIF, whatever. Other
protocols, such as Z39.50, may have a different take on the matter.
 
>> 4.6 N2Ns (URN to URNs)
>The relationship you're talking about seems to be
>the generic/specific relationship, which is VERY useful,
>along with part/whole and a few others.

Yeah, we can talk about this.

>>  The result shall
>> be encoded in a text/uri-list IMT.
>
>s/shall/should/, no?

Agreed.  Perhaps even "may".

>> 4.7 L2Ns (URL to URNs)
>
>> This operation is used to discover the URN associated with a particular
URL.
>
>"the URN"? So this relationship is expected to be functional?
>I think that's fine, as long as it's a conscious decision.

An overstatement. Since we have N2Ns, we should say "discover A URN" not
"discover THE URN".

>Something that I think should be specified: is L2N expected
>to be the inverse of N2L?

Nope. If a resource has multiple URNs and URLs, I don't think we should
mandate any particular behavior on the part of resolvers to make stronger
mappings between the identifiers.

>> 4.8 L2Ls (URL to URLs)
>> This operation is used to discover URLs that are considered equal to each
>> other.
>
>This one is clearly supposed to be an equivalence relation.
>If N2N is also an equivalence relation, then I don't understand
>the distiction.

See earlier discussions on names vs. addresses.

>As I suggested above, I think the essentail ones are:
>	EQV : equivalence in any sense, as long as it's
>		reflexive, symmetric, and transitive. This can be
>		used for alias detection etc.
>	G2S/S2G: generic-to-specific and the converse.
>		transitive (and antisymmetric, I think).
>	P2H/H2P: part-to-whole, whole-to-part. transitive
>		and antisymmetric.
>		This sort
>		of metadata is repeatedly requested by
>		search service providers who want to
>		know when texi2html-chapter2 and
>		texi2html-chapter3 are children of
>		the same root.

I think these are good suggestions.

>Each of these is a special case of:
>	Given a URI S and a URI T, return a set of URIs D[i]
>	such that there's a link from S to D[i] of type T
>	for each i.
>
>These special cases are worth making exception,
>(since full URLs for N2L and EQV would probably waste a lot of
>bytes in DNS!) I suggest another operation for the general
>case:
>
>	S2D(URI S, URI T) -> set of URIs D[i]

Hmmm, sounds pretty good. The first question that comes up is that
sometimes we are happy mapping from one URI to another, and other times
we want to get back a specific type of URI (URN or URL). So, we need to
modify your earlier definition and this suggestion for the generic
operation.

>> 4.9 L2C (URL to URC):
>> This operation is used to retrieve the URC for a given URL
>
>How is this distinct from N2C?

I2C might be very reasonable. Anyone have any scenarios where we need
to maintain the distinction between N and L when fetching metadata?
Hmmmm - there will be times when some metadata applies to the version
of the resource at a particular location, but that is still covered by
a generic I2C operation.

>> 4.10 I2I (URI to URI):
>> This operation is used to map any arbitrary URI to any other arbitrary URI.
>
>Again, I don't see the reason for more than one equivalence
>relation.

Please reconsider this in light of this group's axiom that URNs and
URLs are both URIs, but are not equivalent.

>> 4.11 I=I (Is URI equal to URI):
>> This operation is used to determine whether two given URIs are
considered to
>> be equal by the server being asked the question.
>
>And again.

Um, are you sure about this Dan? This isn't requesting that a mapping
be performed, its a predicate on the existance of such a mapping.

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: Fri, 28 Mar 1997 13:14:57 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Dan,

Let's step back a little, say to the URN requirements doc (and I
believe the IRL requirements doc).  There is a need to identify where
something is (and perhaps also how to get there, but that's another
story).  Where something is can be used to identify it as long as it
won't move and nothing else will be put in its place for the period
over which one wants to identify it.  As soon as one of those things
changes we need to be able to do one of two things, either notify
anyone who might want to access it in the future of the new identity
reflected in the new location or separate identity from location.
Since the identities may often be embedded in a potentially very large
number of immutable objects, separating the two concepts seems like
the best reasonable alternative.  Hence there is a certain burden of
proof on the proposer of an identification (URN) namespace that does
not hold true for a location (URL) namespace.  The URN namespace must
demonstrate adequately that the names will be persistent and
non-reassignable over a long enough period to serve the function of
being an identifier as we've defined it.  Hence, the process documents
for URN namespaces and URL namespaces should be somewhat different
from each other.  They also will be rather similar in many ways - no
problem.  It is the differences that justify the two separate
documents.  If there aren't differences, the documents need to be
fixed.  Due to a day job that has kept my nose to the grindstone day
and night weekdays and weekends for the last several weeks, I haven't
yet had a chance to read the flood of new documents, so I can't
comment on the specific documents, except to say that they SHOULD be
different and if they aren't, they need to be fixed.

			Karen

Date: Fri, 28 Mar 1997 10:38:57 -0700
To: Dan Connolly <[email-masked]>, Patrik Faltstrom <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 03:13 AM 3/28/97 -0600, Dan Connolly wrote:

>Patrik Faltstrom wrote:
>> A namespace is definitely not the same thing as a URL scheme.

>A namespace definitely IS the same thing as a URL scheme.
>
>I don't have any logical argument, but I can cite the
>intent of the designer of URLs:
[...]
>See also, RFC1630 (informational)

Gee Dan, when I read 1630 it says things like:

"For existing Internet access protocols, it is necessary in most
cases to define the encoding of the access algorithm into something
concise enough to be termed address. URIs which refer to objects
according to existing protocols are known as "Uniform Resource
Locators" (URL)s ..."

and

"There is currently a drive to define a space of more persistent names
than any URLs. These "Uniform Resource Names" are the subject of an
IETF working group discussions."  (The group he was referring to was
URI-WG. They are now being discussed in the more tightly focused URN-WG).

Tim drew a pretty clear distinction between address and names.
Addresses had a mapping to Internet Protocols, names did not.

The URN-WG's charter is based on that distinction, so any followups
should drop it from the CC list.

Regards,

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: Fri, 28 Mar 1997 10:16:15 -0700
To: Dan Connolly <[email-masked]>, [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] draft Bibliographic Identifiers to URNs
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 02:00 AM 3/28/97 -0600, Dan Connolly wrote:
>Cecilia Preston wrote:
>> Example: URN:ISBN:0-395-36341-1
>
>Huh? Why the URN:? Why not just ISBN:0-395-36341-1?

Because the overwhelming consensus of the URN working group was that
the URN: prefix was necessary.

>Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
>make more sense.

The URN requirements document states that we need to be able
to grandfather legacy namespaces.  It seems that simple syntactic
transformations (prefix with "urn:namespace-id:" and %encode
any characters outside a limited set) comes a lot closer to
meeting that requirement than changing the syntax of the
identifer to make a closer fit to URL syntax.

Second, the URN-WG has not yet reached consensus on the desirability
of relative URNs. Until then, the syntax document says that unencoded
slashes SHOULD NOT be used. 

>I guess I've got problems with the
>draft-ietf-urn-nid-req. Basically: why is it a different
>document from the URL process document? But that's fodder
>for another message.

Because we operate under the model that there are two forms of
URI - URNs and URLs. URNs MUST NOT contain resolution-system
specific information, such as ports, protocols, etc.

Regards,

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: Fri, 28 Mar 1997 08:21:01 -0800
To: Dan Connolly <[email-masked]>
From: Cecilia Preston <[email-masked]>
Subject: Re: [URN] draft Bibliographic Identifiers to URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Cecilia Preston <[email-masked]>

Dan,

You wrote:

>> Example: URN:ISBN:0-395-36341-1
>
>Huh? Why the URN:? Why not just ISBN:0-395-36341-1?
>
>Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
>make more sense.
>

You are imposing your hierarchical = path name model into a space that is
defined by community to have hyphens and had done so since the mid 1960's.

Furthermore it is not up to the URN community to direct the use of that
part of the space, that is up to the Namespace ID.  Please remember that
this document is intended to illustrate how existing namespaces schemes can
work within the URN syntax.

--Cecilia

Cecilia M. Preston

Preston & Lynch
PO Box 8310
Emeryville, CA 94662
510-547-3207
[email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-req-frame-01.txt
Date: Fri, 28 Mar 1997 10:13:32 -0500
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     : Requirements and a Framework for URN Resolution Systems 
       Author(s) : K. Sollins
       Filename  : draft-ietf-urn-req-frame-01.txt
       Pages     : 18
       Date      : 03/26/1997

This document addresses the issues of the discovery of local URN resolver 
services that in turn will directly translate URNs into URLs and URCs.  The
document falls into three major parts, the assumptions underlying the work,
the requirements in order to be a viable Resolver Discovery Service or RDS 
to help in finding URN resolvers, and a framework for designing RDSs.  The 
requirements fall into three major areas: evolvability, usability, and 
security and privacy.  An RDS that is compliant with the framework will not
necessarily be compliant with the requirements.  Compliance with the 
requirements 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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-01.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-01.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-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 28 Mar 1997 12:32:09 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: [email-masked], Cecilia Preston <[email-masked]>
Subject: Re: [URN] draft Bibliographic Identifiers to URNs
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Fri, 28 Mar 1997, Dan Connolly wrote:

> Cecilia Preston wrote:
>
> > Example: URN:ISBN:0-395-36341-1
> 
> Huh? Why the URN:? Why not just ISBN:0-395-36341-1?
> 
> Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
> make more sense.

We have been through this a bizillion times, and at the last IETF we
concluded that the URN: _must_ be there because of the functional
differences on what a URL and a URN is. Several different argumentation
rounds have been going on weather it is possible to _technically_ use them
interchangeable, but the conclusion in the URN working group is that the
URN: should be there.

We can _NOT_ start this debate again. Sorry if I sound harch Dan, but you
have to look in the email archives for argumentation, and see the minutes
from the San Jose IETF.

> I guess I've got problems with the
> draft-ietf-urn-nid-req. Basically: why is it a different
> document from the URL process document? But that's fodder
> for another message.

It is different because we have different requirements on the NID than a
URL scheme. Maybe we can use the same process, but different requirements?

You also say

>> A namespace is definitely not the same thing as a URL scheme. Two
>> different things, but the _process_ can be similar, just like the
>> processes defined for MIME-types.
>
> Hmm... argument by assertion. I can play that game too:
> A namespace definitely IS the same thing as a URL scheme.
>
> I don't have any logical argument, but I can cite the
> intent of the designer of URLs:

This was something I argued with Tim about 1992 already, and I have been
arguing about this since...as the others being in Stockholm/Helsinki when
this was discussed: Peter Deutsch, Chris Weider, Mark McCahill, Alan 
Emtage, Tim, Joyce Reynolds, Anders Gillner et.al. We others basically
wanted to have some things fixed in HTTP/HTML _BEFORE_ it was sent to
"the masses":

  + The ability of _not_ having stateless connections on top of TCP
    between a client and a server.
  + The ability of formatting www-pages in a better way (look at TeX)
    because people want tables, windows (what is now frames) and the
    ability of changing fonts, sizes, layout commands like putting things
    side by side.
  + The problem that you don't know what you are fetching in HTTP until
    the HTML header arrives, i.e. you have to start fetching before you
    see what you get. Look at ol' Gopher+ and the attributes in the
    links.....

I see that the same things are still discussed and many are fixed in new
versions of HTML/HTTP...

Anyway, I just wanted to point out that these things that start to get
discussed over and over again has been discussed forever...and they will
probably always be discussed forever.

Can anyone write an FAQ? Until we have one, we can not blame _anyone_ for
asking these questions over and over again.

Am I getting old?

   Patrik

Date: Fri, 28 Mar 1997 03:13:22 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Patrik Faltstrom <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Patrik Faltstrom wrote:

> > Is it really necessary/useful to go through this exercise twice?
> 
> A namespace is definitely not the same thing as a URL scheme. Two
> different things, but the _process_ can be similar, just like the
> processes defined for MIME-types.

Hmm... argument by assertion. I can play that game too:
A namespace definitely IS the same thing as a URL scheme.

I don't have any logical argument, but I can cite the
intent of the designer of URLs:

-------------
http://www.w3.org/pub/WWW/DesignIssues/Naming.html
TimBL, circa 1990

The WWW scheme uses a prefix to give the addressing sub-scheme, and
then a syntax dependent on the prefix used, in order to be open to any
new naming systems. 
--------------

See also, RFC1630 (informational) and TimBL's more recent writings:
http://www.w3.org/pub/WWW/DesignIssues/NameMyth.html
including a very intersting and relavent bit
about "Naming: A social and contracual Issue."

As a trump card, I'll play occam's razor, which places
the burden on you to show that they're different.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

To: [email-masked]
Path: usenet
From: Dan Connolly <[email-masked]>
Newsgroups: w3c.urn
Subject: Re: [URN] I-D ACTION:draft-ietf-urn-naptr-04.txt
Date: Fri, 28 Mar 1997 03:01:27 -0600
Organization: World Wide Web Consortium
Lines: 53
Nntp-Posting-Host: beach.w3.org
To: [email-masked]
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

[email-masked] wrote:
>        Title     : Resolution of Uniform Resource Identifiers using the
>                    Domain Name System
>        Author(s) : R. Daniel, M. Mealling
>        Filename  : draft-ietf-urn-naptr-04.txt
>        Pages     : 14
>        Date      : 03/21/1997

This NAPTR stuff is cool: it's an interesting point in
the design space between the old path: scheme and MX
records.

A few comments:

>In conjunction
>with a long TTL for *.urn.net records, the average number of probes to
>DNS for resolving DUNS URNs would approach one.

I would very much like to see the full argument behind that
sentence -- it appeals to my intuition, but I want to
study the details. Are they available somewhere?

>      sprintf(key, "%s.urn.net", extractNS(URN));

er... where's the specificaiton of extractNS? That seems
absolutely critical to the whole thing, and yet I don't
see it specified anywhere except the three examples
(which I assume are non-normative, per standards tradition).

Based on the examples, the algorithm seems to be
"grab the stuff before the :; if it's urn:,
grab everything up to the _next_ :."

Why the special case for the urn: prefix? I seem to
be asking that a lot. But I'm just applying occam's
razor: unless there's a darn good reason for special-casing urn:,
we should not.

Hmm... whoever administers urn.net seems to be able
to introduce new URL schemes at will. That should
certainly be discussed in the URL process document!

I thought I
saw a document specifying the policies for urn.net,
but I can't seem to find it now.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Fri, 28 Mar 1997 09:33:14 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Fri, 28 Mar 1997, Dan Connolly wrote:

> > Introduction:
> > =============
> > 
> > The Uniform Resource Name (URN) Working Group has defined mechanisms
> > for both the syntax [4] and resolution of URNs [1,2]. An framework
> > for URN discovery systems has also been outlined [3]. This draft
> > discusses and recommends the requirements for entities that wish
> > to act as Namespace Identifiers (NIDs) within the URN system.
> 
> Making new NIDs seems exactly analagous to the process of making
> new URL schemes.
>
> Compare with:
> 
> ------------
> http://www.imc.org/draft-masinter-url-process
>    This document provides guidelines for the definition of new URL
>    schemes and describes the process by which they are registered.
> ------------

I think I and Renato should have looked at this document closer before
typing in the text we wrote. I think personally that the process can be
handled the same way. I.e. handle a new NID as a new URL-scheme.

> Is it really necessary/useful to go through this exercise twice?

A namespace is definitely not the same thing as a URL scheme. Two
different things, but the _process_ can be similar, just like the
processes defined for MIME-types.

    Patrik

To: [email-masked]
Path: usenet
From: Dan Connolly <[email-masked]>
Newsgroups: w3c.urn
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Date: Fri, 28 Mar 1997 02:21:28 -0600
Organization: World Wide Web Consortium
Lines: 49
Nntp-Posting-Host: beach.w3.org
To: Patrik Faltstrom <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

I'm trying to get up to speed on all the UR* drafts
and such for Memphis. Some of this stuff is pretty exciting
(NAPTR and RRs and all that) but some of it is confusing.

First of all, what's the relationship between mailing
lists and charters?
	[email-masked] -> 
		http://www.ietf.org/html.charters/urn-charter.html
	[email-masked] -->
		??? (defunct URI WG; anything else?)
	[email-masked]
		??? (new URL syntax/process WG? Is this
		a real WG? It's not listed at:
		http://www.ietf.org/html.charters/wg-dir.html)

Now... about this document:

Patrik Faltstrom wrote:
> draft-ietf-urn-nid-req-01.txt 
>             Namespace Identifier Requirements for URN Services

> Introduction:
> =============
> 
> The Uniform Resource Name (URN) Working Group has defined mechanisms
> for both the syntax [4] and resolution of URNs [1,2]. An framework
> for URN discovery systems has also been outlined [3]. This draft
> discusses and recommends the requirements for entities that wish
> to act as Namespace Identifiers (NIDs) within the URN system.

Making new NIDs seems exactly analagous to the process of making
new URL schemes.

Compare with:

------------
http://www.imc.org/draft-masinter-url-process
   This document provides guidelines for the definition of new URL
   schemes and describes the process by which they are registered.
------------

Is it really necessary/useful to go through this exercise twice?

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

To: [email-masked]
Path: usenet
From: Dan Connolly <[email-masked]>
Newsgroups: w3c.urn
Subject: Re: [URN] draft Bibliographic Identifiers to URNs
Date: Fri, 28 Mar 1997 02:00:10 -0600
Organization: World Wide Web Consortium
Lines: 31
Nntp-Posting-Host: beach.w3.org
To: Cecilia Preston <[email-masked]>
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Cecilia Preston wrote:
> INTERNET DRAFT:Bibliographic Identifiers as URNs 3/1997

> 3.2 Encoding Considerations
> 
> Embedding ISBNs within the URN framework presents no
> particular coding problems, since all of the characters that
> can appear in an ISBN are valid in the identifier segment of
> the URN. %-encoding is never needed.
> 
> Example: URN:ISBN:0-395-36341-1

Huh? Why the URN:? Why not just ISBN:0-395-36341-1?

Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
make more sense.

I guess I've got problems with the
draft-ietf-urn-nid-req. Basically: why is it a different
document from the URL process document? But that's fodder
for another message.

But I want to be sure to get my comments out well
before Memphis.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

To: [email-masked]
Path: usenet
From: Dan Connolly <[email-masked]>
Newsgroups: w3c.urn
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Date: Fri, 28 Mar 1997 01:52:21 -0600
Organization: World Wide Web Consortium
Lines: 337
Nntp-Posting-Host: beach.w3.org
To: Michael Mealling <[email-masked]>
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Short version:
	(1) I suggest link types be integrated into this
	design and
	(2) as a result, I think that URLs and URNs can
	be used interchangeably
	(3) I think N2C needs another parameter to
	specify the schema of the URC.

Details:

Michael Mealling wrote:
> Abstract
> 
> ... We might ask
> for a list of other identifiers that are aliases for the original URI, a
> bibliographic description of the resource the URI denotes, etc.

I suggest you word that more strongly; perhaps:

	Experience suggests that the following operations
	should be supported by the network infrastructure,
	in addition to retrieval:
	
		* requesting one or more URIs which
		are aliases of a given URI, or more generally:
		which URIs are linked to a given URI

		* requesting bibliographic or other
		descriptions of a resource (aka "metadata")

And cite reports on that experience. (altavista's link:
service, PICS labels, yahoo, Engelbart's backlink
requirement, etc.) Hmm... I see that
experience is cited in the intro. Good.

> Because of
> the diverse nature of resources on the network, it may be difficult (or
> impossible) to offer all those operations, therefore a means of indicating
> what services are and are not supported by a given resolver must be
> specified.

The argument is missing a premise: that an indication
of the available services is needed by the clients.
You make that point later (based on experience), but without
it here, the conclusion after the "therefore" doesn't follow.

> This memo gives an initial set of those operations, and the
> requirements that must be met when those operations are encoded in a
> protocol.

"intial set" gives me the willies. Do you mean to imply
that you'll specify the rest of the list some day? If so,
say so.

Are the names of these operations expected to be used
literally in extensible fields in protocols?
If so, is this namespace going to be managed in perpetuity?
By IANA?

My intuition says that we're after a fiarly small set
of primitives that doesn't need to be expanded: we don't
have to cover the needs of every application-level semantic;
just the distinctions that are critical in the name service.

> Also, in subsequent conversations it became obvious that, in
> most cases, some of the operations were inappropriate or difficult for
> certain identifiers. For example, ISSNs identify books or magazines that are
> serial in nature. An operation to return the resource for an ISSN pointing
> to "Time" magazine would result in dumping hundreds of thousands of pages of
> "Time" onto a user's machine. This does not seem like a reasonable thing to
> do in the normal case.

So... don't do that. :-)

Seriously: why do we have to give the machine any extra
information to prevent it from dereferencing the Time
magazine URI? Is there some scenario when the machine
might attempt to do this?

I think I'm missing something. Point me to the relavent
reading materials if you would, please.

> The Problem
> 
> The problem, stated simply, was one of a client needing to convey to a
> service some idea of the desired operation on a URI that the client is
> currently talking about.

Hmm... I don't understand how normal protocol "opcodes"
or "verbs" or "methods" don't suffice for this. But I'll
keep reading...

> The problem was also that the server needed to
> convey to a client which network entity could perform which of the
> operations that were allowed for that particular URI.

This I agree with: some "preview" information is useful
to save round-trips in protocols.

> Any specification of a member of this set of operations MUST contain at
> least the following pieces of information with respect to its operands, its
> algorithm and its output.
> 
>    * 2.1 Operands

Hmm... the URN WG needs its own interface definition language?

Hang on: the header of this document says it's intended
to be standards track, not informational. But this
is an abstact API design, not a wire protocol.
I didn't see that in the charter for this group.
Oh well...

While the number and types of the operands is good stuff,
I think some of the specification of the operations is
missing, especially the relationship between the operations.
For example: is N2L expected to be functional? is L2N
expected to be its inverse? (details below...)

> 4.1 N2L (URN to URL)
...
> This operation is used to map a single URN to a single URL.

In effect, it defines a relation
	N2L <: URN x URL
(where x means cross-product, and <: means subset)

This is where my point about typed links comes in: a
"link type" is exactly a two-place relations between URIs.

If an N2L operation on cid:23l4kj2lk234 yields ftp://...,
that has the same semantics as:

	<link rel="N2L" href="ftp://...">

when found inside cid:23l4kj2lk234 (assuming, in this
case, that it's an HTML document.)

So I would define the N2L operation as:
	Given a URI N, Return some URI L such that there is a
	link from N to L of type "N2L".

Note that N and L are both URIs. Hence my second point:
the distinction between URNs and URLs isn't necessary.

>  The algorithm
> for this mapping is dependent on the URN namespace.

What does that mean?

> 4.2 N2Ls (URN to URLs)
> This operation is used to map a single URN to 0 or more URLs.

This one becomes:
	Given a URI N, Return a set of URIs L[i] such that there
	is a link from N to L[i] of type "N2L" for each i.

Hmm.... Is this the same link type or not?

i.e. is the N2L relation a funciton? i.e. given a URI N,
is it OK if different services return different results
for N2L(N)? If N2L is expected to be a function, then
the N2L semantics are different:

	Given a URI N, Return *the* URI L such that there is a
	link from N to L of type "N2L".

If N2L is functional, then N2Ls needs a distinct link type
if it's to ever return more than one URI:

	Given a URI N, Return a set of URIs L[i] such that there
	is a link from N to L[i] of type "N2Ls" for each i.

> All URIs shall be encoded according to the URI specification [6].

I can't find reference 6. I'm terribly curious to know which
document you're citing for URI syntax.

> 4.3 N2R (URN to Resource)

> This operation is used to return a single instance of the resource that is
> named by the URN.

This is HTTP GET (and ftp RETR, and the analagous operation
in WAIS and ...). It has the same semantics, even if you use
a different mechanism. I suggest you use "GET" in place
of "N2R". But it doesn't matter too much.

> 4.4 N2Rs (URN to Resources)

An interesting twist on GET. Cool.

> 4.5 N2C (URN to URC)
...
> URCs (Uniform Resource Characteristics) are descriptions of other resources.
> This request allows the client to obtain a description of the resource
> identified by a URN, as opposed to the resource itself or simply the
> resources URLs.

FYI, the PICS spec gives an example of this operation:
	http://www.w3.org/pub/WWW/PICS/labels.html#Requesting

It has another parameter though: the metadata schema
that the URCs should conform to.

Hmm... I'll have to look closely at THTTP to see if
it's gratuitiously different from PICS.

> 4.6 N2Ns (URN to URNs)

> While URNs are supposed to identify one and only one resource, that does not
> mean that a resource may have one and only one URN. For example, consider a
> resource that has something like "current-weather-map" for one URN and
> "weather-map-for-datetime-x" for another URN. The N2Ns service request lets
> the client obtain lists of URNs that are believed equivalent at the time of
> the request.

Hang on: the relationship between current-weather-map
and weather-map-for-datetime-x isn't an equivalence relation.
Well... if it is, that's a misleading example.

The relationship you're talking about seems to be
the generic/specific relationship, which is VERY useful,
along with part/whole and a few others.

In terms of link types, I would describe this as:

	Given a URI N, return a set of URIs M[i] such
	that there is a link from N to M[i] of type
	"S2G" for each i.

where the S2G is specified to be transitive.

This seems distinct from the equivalence relationship:

	Given a URI N, return a set of URIs M[i] such
	that there is a link from N to M[i] of type
	"EQV" for each i.

> As the weathermap example shows, some of the equivalences will
> be transitory, so the the server should convey the length of time for which
> the mapping is valid.

That's the case for all metadata, no?

>  The result shall
> be encoded in a text/uri-list IMT.

s/shall/should/, no?

> 4.7 L2Ns (URL to URNs)

> This operation is used to discover the URN associated with a particular URL.

"the URN"? So this relationship is expected to be functional?
I think that's fine, as long as it's a conscious decision.

Something that I think should be specified: is L2N expected
to be the inverse of N2L?

> 4.8 L2Ls (URL to URLs)
> This operation is used to discover URLs that are considered equal to each
> other.

This one is clearly supposed to be an equivalence relation.
If N2N is also an equivalence relation, then I don't understand
the distiction.

As I suggested above, I think the essentail ones are:
	EQV : equivalence in any sense, as long as it's
		reflexive, symmetric, and transitive. This can be
		used for alias detection etc.
	G2S/S2G: generic-to-specific and the converse.
		transitive (and antisymmetric, I think).
	P2H/H2P: part-to-whole, whole-to-part. transitive
		and antisymmetric.
		This sort
		of metadata is repeatedly requested by
		search service providers who want to
		know when texi2html-chapter2 and
		texi2html-chapter3 are children of
		the same root.

Each of these is a special case of:
	Given a URI S and a URI T, return a set of URIs D[i]
	such that there's a link from S to D[i] of type T
	for each i.

These special cases are worth making exception,
(since full URLs for N2L and EQV would probably waste a lot of
bytes in DNS!) I suggest another operation for the general
case:

	S2D(URI S, URI T) -> set of URIs D[i]

> 4.9 L2C (URL to URC):
> This operation is used to retrieve the URC for a given URL

How is this distinct from N2C?

> 4.10 I2I (URI to URI):
> This operation is used to map any arbitrary URI to any other arbitrary URI.

Again, I don't see the reason for more than one equivalence
relation.

> 4.11 N2I (URI to URI):
> This operation is used to map a URN to any other arbitary URI.

And again.

> 4.11 I=I (Is URI equal to URI):
> This operation is used to determine whether two given URIs are considered to
> be equal by the server being asked the question.

And again.

Now... on to the specs that depend on this one.

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 27 Mar 1997 17:12:48 -0600 (CST)
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked]
Subject: [URN] Requirements internet draft
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Thanks for this document.  It helps me understand where we differ.

Karen R. Sollins writes:
 > Internet Draft                                          Karen R. Sollins
 > draft-ietf-urn-req-frame-01.txt                                  MIT/LCS

 > 	Requirements and a Framework for URN Resolution Systems

 >  ... The URI working group
 > concluded that there was need for persistent, globally unique
 > identifiers, distinct from location or other semantic information;
 > these "names" provide identity, in that if two of them are "the same"
 > (under some simple rule of canonicalization), they identify the same
 > resource.

Regarding what the URI working group concluded, I think it is correct
to say we agree on the need for "persistent, globally unique
identifiers" but the controversial "distinct from location or other
semantic information" could be safely dropped.

 > Furthermore, the group decided that these "names" were
 > generally to be for machine, rather than human consumption.

I don't recall that.  In fact, I recall the opposite.  It is a
controversy, so it is not safe to claim we agreed on it.

 > One can imagine a variety human-friendly naming (HFN) schemes
 > supporting different suites of applications and user communities.

One can imagine a lot.  But I'd like to see some details and then
we can better guess whether the desirable features will come to pass.
Until then, we cannot rely on the future possibility of HFNs to solve
current problems.

 > 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
 > that helps in the resolution of a URN; we map URNs to hints as an
 > interim stage in accessing a resource.

How is a location hint really different from a redirection?
The term "hint" suggests that it is even weaker than a redirection.
Hints may include other things that help in resolution beside
the redirection.

 > 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,

Stored locally to whom?  Local to the user of a URN or local to the
document containing the URN?

 > because maintaining a
 > database of globally available, completely up-to-date location
 > information is infeasible for performance reasons.

Some people argue that it is feasible to maintain a globally
available, up-to-date database.  Depends on what you mean by
"database" and "globally available".  Is the information stored in DNS
servers a globally available database?  If you mean a single global
service, or even a single logical service that is replicated, I might
agree with you.  But the developers of the handle system would not.

If by "locally stored" you mean cached data that was previously
obtained from a global service, well, we may get better performance,
but possibly worse up-to-date-ness.

 > 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.

Redirections may become invalid when a moved resource moves again.  If
resource servers can inform RDS services of the move of a resource,
then they can also inform known places that have redirections to the
resource.

 > Hints may be found in a variety of places.  It is generally
 > assumed that a well engineered system will maintain a set of hints for
 > each URN at each location where that URN is found.

I generally assume that "hints" will be about *collections* of URNs
and not individual URNs.  This is to get reasonable scalability.

 > 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.

Hmm. "fall-back"?  I like the idea of fall-backs, of course.  But I
don't think of an RDS as the fall-back mechanism.  The RDS is the
place you get the initial information in the first place that is
cached locally, and if that data becomes obsolete, then you go back to
the RDS for the latest info.  If the RDS is merely a fall-back, then
so is every web server in the same sense, because local caches may have
obsolete info.

 > 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.

I thought the RDS only provides more hints.  Maybe they are better,
more up-to-date hints, but they are still only hints.  No guarantees.

 > 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.

This section I mostly agree with.  I hope that is not surprising to you.

 > We expect that there will be a multi-tiered naming authority
 > delegation.

I'm glad to see that.  But then what is the difference between
multi-tiered naming authority and a hierarchical name space?  The full
hierarchical name of the naming authority would presummably appear in
the URNs.

 > Furthermore, it is difficult to imagine a non-partitioned and delegated
 > global RDS, meaning that hint discovery and resolution will be
 > partitioned and delegated.  In some RDS schemes, the delegation of
 > naming authority will form a basis for delegating the management and
 > dispensing of location information.

In fact, what is called at the top level a "*Resolver* Discovery
Service" would be a RDS Discovery Service.  Repeating that
indefinitely, we have R(DS)*.  So is it mostly a resolver or mostly a
discovery service?

 > The third assumption is independence or isolation of one authority from
 > another and, at least to some extent from its parent.  Underlying much
 > of the thinking and discussion in the URI and URN working groups has
 > been the assumption that when a component delegates authority to another
 > component, the delegatee can operate in that domain independently of its
 > peers and within bounds specified by the delegation, independently of
 > the delegator.  This isolation is critically important in order to allow
 > for independence of policy and mechanism.

But the bounds specified by the delegation may be arbitrarily
restrictive, and thus possibly not at all independent.  We have to
allow that.  For other naming authorities, there may be very few
restrictions on child authorities.  I don't think it helps much to say
anything at all about the parent-child relationship here, other than
what I just said.

 > 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 just identified or
 > located by the RDS service.

Or maybe a particular RDS doesnt even know about the URN resolver or
the name space.  This may be true if it is a private resolver, private
name space or small (possibly new, possibly private) RDS.

 > 3. Requirements

I don't understand the motivation behind these RDS requirements.  If
the issue is how do we (whoever we are) decide whether a service
qualifies as an RDS, then there will always be a whole lot of
"depends" in the answer.

For example, 

 >    [R1] To support evolution of mechanisms, specifically for
 >           {R1.1] a growing set of URN schemes;

Why does any RDS need to support more than the URN schemes it wants
to support?   If an RDS is going to be used only within an intranet,
for example, it only really needs to support URN schemes that are used
inside that intranet.

 > ...  Most of these requirements are not quantifiable and hence
 > conformance is a judgment call and a matter of degree.  

I would be happy calling these guidelines rather than requirements.

 >           [R1.4] alternative RDS schemes active simultaneously;

Are you saying that one RDS must do something relative to the 
other RDS mechanisms?  The alternative RDS mechanisms seems to be
more of an issue for clients that must choose one.

 > Second, in addition to the evolution of resolution mechanisms, we
 > expect that the community will follow an evolutionary path towards the
 > separation of location information from identification.  The URN
 > requirements document suggested this path as well, and there has been
 > general agreement in much of the community that such a separation is
 > desirable.  This is a problem that the public at large has generally
 > not understood.

Actually, I find that there is an intuitive understanding by members
of the general public that a name must be looked up somewhere, and
thus it functions like a location.  

We may have trouble selling the public on a scheme that takes more
time to use, and won't pay off for dozens of years.

 > Today we see the problem most clearly with the use of
 > URLs for identification.  When a web page moves, its URL becomes
 > invalid.

When a resource disappears, its URN becomes invalid?  What does invalid
really mean?

 > ... A third alternative is that the target server supplies an
 > HTTP redirect so that the new page is provided for the client
 > automatically.  In this case, the client may not even realize that the
 > URL is no longer correct.

But the URL worked just fine - it is NOT incorrect.  Resolution does
depend on the intermediate service, but this is not different from
resolution of URNs via RDSes, other than the fact that there will be
fewer RDSes and they will be designed to be more persistent.

A new HTTP status code was added, 303, to mean "see here" (or "go
there", something like that) which causes a redirect without the
implication of "resource moved" either temporarily or permanently.

I.e. OCLC's PURL service is a perfectly adequate persistent URN
resolution service, if you trust that OCLC will be around long enough,
or if you can trust that clients will know where to lookup the PURL
resolver service after OCLC gets swallowed by Microsoft (there is no
basis in that rumor).

 > The real problem with both of these latter
 > two situations is that they only work as long as the forwarding
 > pointer can be found at the old URL.  Location information, was
 > embedded in the identifier, and the resolution system was designed to
 > depend on that location information being correct.

Yes and no. I won't repeat my whole argument here.  Ask in private
email if you want to continue this.

 > To the extent that an RDS scheme supports the separation of global
 > identification from location information it will be encouraging the
 > longer utility of the identities.

Important principle:

It is not the separation of global identification from location
information that can give identifiers their longevity.  The longevity
of identifiers comes from the persistence of the resolution (or
discovery) services together with the ability to return a redirection
as opposed to the resource itself.

(We discussed all-identifiers-are-relative previously.)  

I don't have time to finish commenting on the rest of the document
at this time.  And the above is probably sufficient for now.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

To: Patrik Faltstrom <[email-masked]>
Cc: [email-masked], [email-masked], Renato Iannella <[email-masked]>, Leslie Daigle <[email-masked]>
Subject: [URN] Re: draft-ietf-urn-nid-req-01.txt 
Date: Thu, 27 Mar 1997 13:55:59 -0500
From: Cynthia Clark <[email-masked]>
Sender: [email-masked]
Reply-To: Cynthia Clark <[email-masked]>

Hello Patrik !

Just for your information, I am currently working on your
Internet-Draft <draft-ietf-urn-nid-req-00.txt>.

I'll probably send an announcement to the entire IETF
regarding your I-D sometime tomorrow or the next day.

**** Please note that I've changed the filename version number
     from "-01" to "-00" for all brand new documents.....

See you in Memphis  :-)
       
Kind Regards,
Cynthia 
------------------------------------------------------
Cynthia Clark, IETF Internet-Drafts Administrator
E-mail Address preference:  <[email-masked]>
-------------------------------------------------------

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 27 Mar 1997 14:18:40 -0600 (CST)
To: Patrik Faltstrom <[email-masked]>
Cc: [email-masked]
Subject: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Several points in the document are actually about resolution, but as
Leslie says:

Leslie Daigle <[email-masked]> wrote:
> 	2.  This is about what it takes to define a new URN  namespace,
> 	    not what it takes to set up and run a resolver for an
> 	    existing one

Regardless of whether it is a new newspace or an existing one, there
is a separation between the definition of the name space and the
resolution service(s) for that space.

Patrik Faltstrom writes:
 >  Global Scope and Uniqueness.
 > 
 >   - The NID must be registered with IANA to ensure uniqueness and
 >     demonstrating that it meets the requirements listed in this
 >     document.

Who registers a name space if anyone can, in fact, resolve identifiers
in the name space?  Does someone "own" the name space?  Some name
spaces might be owned by a corporation or individual.  Others might be
owned collectively.  Others might be public domain, if that is
possible.  No matter who owns the name space, who is *allowed* to
resolve identifiers in the name space?  This is part of the definition
of the name space.

 >  Persistence

A fundamental mixup regarding the nature of names and resolution
becomes evident in the following.

 >   - The NID service providers must show that they intend to
 >     support the service for an indefinite period of time.

What is a NID service provider in this case?  Someone who provides the
service of registering new names or someone who resolves names at the
request of clients?  Just to be clear, I'll call them, respectively,
NID registration service and NID resolution service.  Why does a NID
registration service need to continue to exist indefinitely?  If it
stops the registration service, the only thing that happens is that
new names cannot be registered.

Another notion of persistence for identifiers is that they may
continue to be resolved indefinitely, if they are resolvable at all.
In other words, a client can always find *some* resolution service that
will resolve a particular identifier.  Thus it is the service of
*finding* a resolution service that must be persistent, not the
resolution services themselves.  So why does a NID resolution service
need to continue to exist indefinitely?

The service of *finding* a resolution service needs to be at least
as persistent as the resolution services, otherwise what is the
point of making use of the finding service?  

 >   - Support facilities must be described and how the service
 >     intends to operate, including "disaster recovery"-like
 >     operations.

Disaster recovery for the NID registration service?  Why bother?

Disaster recovery for the NID resolution service is useful, but if
there are replia services, as there should be, what is the big deal?

 >   - Demonstrated experience in managing an established namespace
 >     system is essential.    

What is so hard about managing the NID registration process?

Resolution is another matter.  Doing it scalable takes not just
experience on a small scale but the right algorithms that are
appropriate on a large (and long) scale.  One can show by arguments
that a system is scalable or not scalable.  One can also do
experiments, but there is nothing like the real thing for experience.
So how can we tell whether a system will actually work?  Who should
stand in judgement?

But why do we need to bother worrying about this.  The point of having
a service for *finding* resolution services is to allow multiple
resolution services so that some resolution services can fail and others
will fill in.

How can we ever impose on a service to promise to exist indefintely
anyway?  Such a promise would certainly be a lie.

 >   - One URN should never be reused for a different resource (where
 >     "different" is defined as in previous paragraph by the namespace).

This is persistent registration.  Not at all difficult.

 >     The URN should be persistent for all times, even though the
 >     resource goes away.

This is ambiguous, given the above.  Is this just a restatement of the
persistent uniqueness requirement, or do you mean persistent
resolution?

 >  Independence
 > 
 >   - The NID service providers must also show any relationship
 >     (both technical and administrative) that may impede on the
 >     provision of the URN service.
 >   - However, multi-party participation in the NID service is
 >     an advantage.

This sounds like you are assuming the NID name space is owned by
some party that may consist of multiple cooperating parties.

 >  Resolution

Ah, now this is definitely about resolution.

 >   - The NID service providers must produce an RFC
 >     describing the technical characteristics of the URN
 >     resolution service, including security considerations.

On the one hand, I would agree that the resolution issues should be
considered separately from the name space definition issues.  But
how do you really separate them?  In practice, the same agency is
likely to be involed in both definition and resolution.  More
importantly, the structure of the name space, assuming it is
structured, will have a lot to do with how identifiers are resolved.

 >   - The NID service providers may elect not to have the
 >     resolution service publically available.

Ah, a public *finding* service for private resolution services.
Hmm, how will this sit with the anarchists among us?

Leslie again:
> 	3.  If we are unlucky, this is about as difficult and subjective as 
> 	    iTLDs.  "Enforcement" will require judgement.

No question about it.  This is even more difficult and subjective than
TLDs.  It is hard enough just to deal with ownership issues.

There is another way to deal with all this much more simply: in a
nutshell, delegate hierarchically and let each authority deal with
meeting the requirements.  Anything more invasive is asking for
trouble.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

From: "Ryan Moats" <[email-masked]>
To: "Patrik Faltstrom" <[email-masked]>
Cc: "Renato Iannella" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 27 Mar 97 08:50:23 
Priority: Normal
Subject: [URN] My $0.02 on draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

While I somewhat agree with Erik, I have some slightly different takes
on this document (and therefore suggestions on where to go).  Having
set up a test URN resolver (more about this in Memphis), I have
been starting to think about what it would take to register such a beast.

First of all, I think it would be a good thing if there were an Appendix
giving a form that (when filled in) could be submitted to IANA or the
RFC editor to handle the registration of namespace identifiers.
This is based on going through the other drafts and noting
what has been put off to the namespace identifier registration document.

This form MUST include the following things:

	1. The namespace identifier name.
	2. A BNF specification of the NSS syntax
	3. A definition of what characters are reserved (in addition
	to those characters in the URN Syntax draft) and should
	be %encoded if used literally.
	4. A definition of additional lexical equivalence relations
	above and beyond those in the URN Syntax draft.
	5. A definition of what addition functional equivalence relations (to the
	lexical equivalence relations specified in the URN Syntax draft)
	6. A specification of which RDS will be used

This form SHOULD include the following things:

	A. If the NAPTR RDS is used, primary and secondary 
	nameservers for the <nid>.urn.net domain so that the NAPTR
	records for <nid>.urn.net are maintained locally by the namespace
	provider.
	B. Security consideration that might result from the use of additional
	reserved characters in #3 above.

Thinking about the whole concept of a "nid requirements document",
should this just be about requirements or should it be about registration
process?  I bring this up because my current thoughts on the registration
process look something like the following, although as far as I can tell
it hasn't been documented/discussed anywhere:

	- somebody fills out the registration template for <nid> and sends 
	  it to IANA
	- IANA approves/rejects the template
	- if the template is approved AND the NAPTR RDS will be used
	  ?somebody? (who?) puts the appropriate information into DNS
	  for <NID>.urn.net [This question boils down to: "who admisters
	  the urn.net domain"?]

Well, that's my $0.02 worth for now.  See everybody in Memphis (where
I think a bar WG on NID registration might not be a bad idea).

Ryan

From: Renato Iannella <[email-masked]>
Date: Thu, 27 Mar 1997 15:22:14 +1000 (EST)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE[2]: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Renato Iannella <[email-masked]>

Leslie Daigle <[email-masked]> wrote:
> 
> Some key points to bear  in mind:
> 
> 	1.  This is draft 00
> 	2.  This is about what it takes to define a new URN  namespace,
> 	    not what it takes to set up and run a resolver for an
> 	    existing one
> 	3.  If we are unlucky, this is about as difficult and subjective as 
> 	    iTLDs.  "Enforcement" will require judgement.

Thanks, Leslie.

We should have added some preliminary text to the posting that
outlines that this is a very early draft and we want to get
some feedback as to what are real requirements and what are not.

So, please send in your feedback and discuss at Memphis.

Cheers... Renato
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dr Renato Iannella                 http://www.dstc.edu.au/RDU/staff/ri/
DSTC Pty Ltd                                     phone://61/7-3365-4310
Gehrmann Labs, QLD, 4067, AUSTRALIA                fax://61/7-3365-4311
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc

Date: Wed, 26 Mar 1997 19:12:08 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: "Jul,Erik" <[email-masked]>
Cc: [email-masked]
Subject: RE: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Wed, 26 Mar 1997, Jul,Erik wrote:
> Much of this document seems unenforceable to me.   Examples below.

Some key points to bear  in mind:

	1.  This is draft 00

	2.  This is about what it takes to define a new URN  namespace,
	    not what it takes to set up and run a resolver for an
	    existing one

	3.  If we are unlucky, this is about as difficult and subjective as 
	    iTLDs.  "Enforcement" will require judgement.

When we discussed this before, it was suggested that one avenue is to define 
new URN namespaces through the use of RFCs (like the URL-scheme definition 
process).  This document is a step towards providing guidelines to judging and 
framing those RFC-efforts.

> By whom?  When?  How?  According to what standard?  Where stored?   By whom? 
>  for how long?  How accessed?  At what cost?  Who bears cost?  How 
> transferred?  How modified?  Who needs to know?  Why?  What will they do 
> with it?

An excellent list of questions...  draft-00 has already begun doing its
job :-)

Leslie.

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

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

Date: Wed, 26 Mar 1997 17:24:42 -0500
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: [email-masked], [email-masked], Leslie Daigle <[email-masked]>
Subject: Re: [URN] draft-urn-resolution-services-01.txt
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Michael Mealling wrote:
> 
> <a badly mangled copy of draft-urn-resolution-services-01.txt deleted>

Sorry 'bout that. Here's hoping the right copy that I just sent actually
makes it into the repository....

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Wed, 26 Mar 1997 17:19:09 -0500
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: [email-masked]
Cc: [email-masked], [email-masked], Leslie Daigle <[email-masked]>, [email-masked]
Subject: [URN] resend of draft-urn-resolution-services-01.txt
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

URN Working Group                                                   M.Mealling
INTERNET-DRAFT                                         Network Solutions, Inc.
Expires six months from March 1997                              Ron Daniel Jr.
Intended category: Standards Track              Los Alamos National Laboratory
 
                           URN Resolution Services
 
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 ds.internic.net (US East Coast), nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
 
Abstract
 
Fetching the resource identified by a Uniform Resource Identifier (URI) [3]
is only one of the operations that can be performed on a URI. We might ask
for a list of other identifiers that are aliases for the original URI, a
bibliographic description of the resource the URI denotes, etc. Because of
the diverse nature of resources on the network, it may be difficult (or
impossible) to offer all those operations, therefore a means of indicating
what services are and are not supported by a given resolver must be
specified. This memo gives an initial set of those operations, and the
requirements that must be met when those operations are encoded in a
protocol.
 
1. Introduction
 
In the course of formulating current proposals [1] regarding Uniform
Resource Names [2] it became apparent that requiring servers to deal with
all desired functions or requiring clients to deal with complicated
information returned by a server was unrealistic and a barrier to adoption.
There needed to be some way for a client to be able to pick between a server
that specialized in the complex and another that specialized in the simple
(but fast). Also, in subsequent conversations it became obvious that, in
most cases, some of the operations were inappropriate or difficult for
certain identifiers. For example, ISSNs identify books or magazines that are
serial in nature. An operation to return the resource for an ISSN pointing
to "Time" magazine would result in dumping hundreds of thousands of pages of
"Time" onto a user's machine. This does not seem like a reasonable thing to
do in the normal case.
 
The Problem
 
The problem, stated simply, was one of a client needing to convey to a
service some idea of the desired operation on a URI that the client is
currently talking about. The problem was also that the server needed to
convey to a client which network entity could perform which of the
operations that were allowed for that particular URI.
 
This problem requires we specify some well understood set of identifiers
that could identify the operation that a particular network entity either
desired or could perform. But it was also realized that an exhaustive set
would both be impossible and not very necessary. Thus, while this document
will list several operations, it will also lay out the requirments for
specifying new operations.
 
Design Criteria
 
The design criteria used to meet these requirements were fairly simple. The
need to simply identify the operation with some token and know its operands
and algorithm was seen as sufficient to meet the requirements. Thus, as with
most things simple the simple set of design criteria ended up being: simple,
extensible, generic and short.
 
As with most design requirements there are several that are at cross
purposes. Thus for anyone adding to this list these design criteria should
be kept in mind and balanced against each other.
 
2. General Specification
 
In order to provide a framework both for the specifications in this document
and for new ones to be written by others the following requirments are
placed on any documents that seek to specify new operations.
 
Any specification of a member of this set of operations MUST contain at
least the following pieces of information with respect to its operands, its
algorithm and its output.
 
   * 2.1 Operands
 
     Must contain the following pieces of information:
        o name of the operation
        o mnemonic for the operation
        o number of operands
        o type of each operand
        o format of each operand
 
   * 2.2 Algorithm Must either specify the exact algorithm for the operation
     or must specify that the algorithm is opaque and defined by the server.

   * 2.3 Output Must either specify one of the following:
        o there is no output
        o the output is undefined
        o the output itself and its content
        o the fact that the output is an object and that objects type and
          format.
 
3. Encoding The Operations
 
To be useful these operations have to be used within some system or
protocol. In many cases these systems and protocols will place restrictions
on which operations make sense and how those that do are syntactically
represented.
 
Also, a given system or protocol will have its own output formats that will
restrict the output formats of a given operation. Additionally, a given
protocol may have better solution for output than the ones given here. For
example, the N2L result may be encoded in a protocol specific manner that
causes the client to treat it as special.
 
Thus, the requirements on encoding these operations within a given system
are the following:
 
   * which subset of the operations are allowed
   * how the operator is encoded
   * how the operands are encoded
   * what the output format is
 
For those system that can use it, MIME [4] is the suggested output format.
The operations listed here use the text/uri-list Internet Media Type or IMT
[4] that is specified in Appendix A. Other system are strongly encouraged to
use this IMT. In the case where a system does not use an IMT a justification
should be given.
 
4. The Incomplete Set
 
4.1 N2L (URN to URL)
 
   * name: URN to URL
   * mnemonic: N2L
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: 1 and only one URL encoded in a text/uri-list
 
This operation is used to map a single URN to a single URL. It is used by
light weight clients that do not have the ability to select from a list of
URLs or understand a Uniform Resource Characteristic (URC). The algorithm
for this mapping is dependent on the URN namespace.
 
4.2 N2Ls (URN to URLs)
 
   * name: URN to URLs
   * mnemonic: N2LS
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: a list of 0 or more URLs encoded in a text/uri-list
 
This operation is used to map a single URN to 0 or more URLs. It is used by
a client that can pick from a list of URLs based on some criteria that is
important to the client. The client should not make any assumptions about
the order of the URLs returned.
 
No matter what the particular media type, the result MUST be a list of the
URLs that may be used to obtain an instance of the resource identified by
the URN. All URIs shall be encoded according to the URI specification [6].
 
4.3 N2R (URN to Resource)
 
   * name: URN to Resource
   * mnemonic: N2R
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: an instance of the resource named by the URN. Encoding is not
     specified.
 
This operation is used to return a single instance of the resource that is
named by the URN. The format of the output is dependent on the resource
itself.
 
4.4 N2Rs (URN to Resources)
 
   * name: URN to Resources
   * mnemonic: N2Rs
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: 0 or more instances of the resource named by the URN. Encoding
     is not specified.
 
This operation is used to return multiple instances of a resource, for
example, GIF and JPEG versions of an image. The judgment about the resources
being "the same" resides with the naming authority that issued the URN.
 
The output shall be a MIME multipart/alternative [4] message with the
alternative versions of the resource in separate body parts. If there is
only one version of the resource identified by the URN, it MAY be returned
without the multipart/alternative wrapper.
 
4.5 N2C (URN to URC)
 
   * name: URN to URC
   * mnemonic: N2C
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A Uniform Resource Characteristic. Encoding is not specified.
 
URCs (Uniform Resource Characteristics) are descriptions of other resources.
This request allows the client to obtain a description of the resource
identified by a URN, as opposed to the resource itself or simply the
resources URLs. The description might be a bibliographic citation, a digital
signature, a revision history, etc. This draft does not specify the content
of any response to a URC request. That content is expected to vary from one
server to another.
 
4.6 N2Ns (URN to URNs)
 
   * name: URN to URNs
   * mnemonic: N2Ns
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A list of URNs encoded in a text/uri-list IMT.
 
While URNs are supposed to identify one and only one resource, that does not
mean that a resource may have one and only one URN. For example, consider a
resource that has something like "current-weather-map" for one URN and
"weather-map-for-datetime-x" for another URN. The N2Ns service request lets
the client obtain lists of URNs that are believed equivalent at the time of
the request. As the weathermap example shows, some of the equivalences will
be transitory, so the the server should convey the length of time for which
the mapping is valid. The result is a list of all the URNs, known to the
server, which identify the same resource as the input URN. The result shall
be encoded in a text/uri-list IMT.
 
4.7 L2Ns (URL to URNs)
 
   * name: URN to URNs
   * mnemonic: N2Ns
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A list of URNs encoded in a text/uri-list IMT.
 
This operation is used to discover the URN associated with a particular URL.
As with all operations dealing with URNs how that URN is mapped is
completely dependent on the rules specified by the namespace.
 
4.8 L2Ls (URL to URLs)
 
   * name: URL to URLs
   * mnemonic: L2Ls
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A list of URLs encoded in a text/uri-list IMT.
 
This operation is used to discover URLs that are considered equal to each
other. As with the N2N operation "equality" is defined by the server and is
opaque to the client.
 
4.9 L2C (URL to URC):
 
   * name: URL to URC
   * mnemonic: L2C
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A URC.
 
This operation is used to retrieve the URC for a given URL. As with most
other URI mappings the mapping function is opaque. As with any other
operation that returns a URC, the output format is unspecified.
 
4.10 I2I (URI to URI):
 
   * name: URI to URI
   * mnemonic: I2I
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A URI.
 
This operation is used to map any arbitrary URI to any other arbitrary URI.
No other assertions are made about whether or not the URI exhibits
characteristics of URNs or URLs.
 
4.11 N2I (URI to URI):
 
   * name: URN to URI
   * mnemonic: N2I
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A URI.
 
This operation is used to map a URN to any other arbitary URI. No other
assertions are made about whether or not the URI exhibits characteristics of
URNs or URLs.
 
4.11 I=I (Is URI equal to URI):
 
   * name: URI = URI
   * mnemonic: I=I
   * number of operands: 2
   * type of each operand: Both operands are URIs
   * format of each operand: both operands are encoded as a URIs
   * algorithm: opaque
   * output: TRUE or FALSE
 
This operation is used to determine whether two given URIs are considered to
be equal by the server being asked the question. The algorithm used to
determine equality is opaque. No assertions are made about whether or not
the URIs exhibits characteristics of URNs or URLs.
 
6. The text/uri-list Internet Media Type
 
     [This section will be augmented or replaced by the registration of
     the text/uri-list IMT once that registration has been performed].
 
Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls,
result in a list of URIs being returned to the client. The text/uri-list
Internet Media Type is defined to provide a simple format for the automatic
processing of such lists of URIs.
 
The format of text/uri-list resources is:
 
  1. Any lines beginning with the '#' character are comment lines and are
     ignored during processing. (Note that '#' is a character that may
     appear in URIs, so it only denotes a comment when it is the first
     character on a line).
  2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
     according to the URI specification RFC[6]. Each URI shall appear on one
     and only one line.
  3. As for all text/* formats, lines are terminated with a CR LF pair,
     although clients should be liberal in accepting lines with only one of
     those characters.
  4. The order of the URIs given MUST be preserved upon retransmission. The
     client should not make any inferences about what the order of the
     returned list means.
 
In applications where one URI has been mapped to a list of URIs, such as in
response to the N2Ls request, the first line of the text/uri-list response
SHOULD be a comment giving the original URI.
 
An example of such a result for the N2L request is shown below in figure 1.
             --------------------------------------------------
 
     # urn:cid:[email-masked]
     http://www.huh.org/cid/foo.html
     http://www.huh.org/cid/foo.pdf
     ftp://ftp.foo.org/cid/foo.txt
 
                Figure 1: Example of the text/uri-list format
             --------------------------------------------------
 
7. References
 
[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
    February, 1997.
 
[2] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997.
 
[3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for
    the Expression of Names and Addresses of Objects on the Network as
    used in the World-Wide Web", T. Berners-Lee, June 1994.
 
[4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One:
    Mechanisms for Specifying and Describing the Format of Internet Message
    Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft,
    September 1993.
 
8. Security Considerations
 
Communications with a server may be of a sensitive nature. Some servers will
hold information that should only be released to authorized users. The
results from servers may be the target of spoofing, especially once
electronic commerce transactions are common and there is money to be made by
directing users to pirate repositories rather than repositories which pay
royalties to rights-holders. Server requests may be of interest to traffic
analysts. The requests may also be subject to spoofing.

9. Author Contact Information
 
Michael Mealling
Network Solutions
505 Huntmar Park Drive
Herndon, VA 22070
voice: (703)742-0400
fax: (703)742-9552
email: [email-masked]
 
Ron Daniel
Advanced Computing Lab, MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA, 87545
voice: +1 505 665 0597
fax: +1 505 665 4939
email: [email-masked]

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Wed, 26 Mar 1997 17:05:00 -0500
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: [email-masked]
Cc: [email-masked], [email-masked], Leslie Daigle <[email-masked]>
Subject: [URN] draft-urn-resolution-services-01.txt
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

URN Working Group                                                  
M.Mealling
INTERNET-DRAFT                                         Network
Solutions, Inc.
Expires six months from March 1997                              Ron
Daniel Jr.
Intended category: Standards Track              Los Alamos National
Laboratory
 
                           URN Resolution Services
 
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 ds.internic.net (US East Coast),
nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
 
Abstract
 
Fetching the resource identified by a Uniform Resource Identifier (URI)
[3]
is only one of the operations that can be performed on a URI. We might
ask
for a list of other identifiers that are aliases for the original URI, a
bibliographic description of the resource the URI denotes, etc. Because
of
the diverse nature of resources on the network, it may be difficult (or
impossible) to offer all those operations, therefore a means of
indicating
what services are and are not supported by a given resolver must be
specified. This memo gives an initial set of those operations, and the
requirements that must be met when those operations are encoded in a
protocol.
 
1. Introduction
 
In the course of formulating current proposals [1] regarding Uniform
Resource Names [2] it became apparent that requiring servers to deal
with
all desired functions or requiring clients to deal with complicated
information returned by a server was unrealistic and a barrier to
adoption.
There needed to be some way for a client to be able to pick between a
server
that specialized in the complex and another that specialized in the
simple
(but fast). Also, in subsequent conversations it became obvious that, in
most cases, some of the operations were inappropriate or difficult for
certain identifiers. For example, ISSNs identify books or magazines that
are
serial in nature. An operation to return the resource for an ISSN
pointing
to "Time" magazine would result in dumping hundreds of thousands of
pages of
"Time" onto a user's machine. This does not seem like a reasonable thing
to
do in the normal case.
 
The Problem
 
The problem, stated simply, was one of a client needing to convey to a
service some idea of the desired operation on a URI that the client is
currently talking about. The problem was also that the server needed to
convey to a client which network entity could perform which of the
operations that were allowed for that particular URI.
 
This problem requires we specify some well understood set of identifiers
that could identify the operation that a particular network entity
either
desired or could perform. But it was also realized that an exhaustive
set
would both be impossible and not very necessary. Thus, while this
document
will list several operations, it will also lay out the requirments for
specifying new operations.
 
Design Criteria
 
The design criteria used to meet these requirements were fairly simple.
The
need to simply identify the operation with some token and know its
operands
and algorithm was seen as sufficient to meet the requirements. Thus, as
with
most things simple the simple set of design criteria ended up being:
simple,
extensible, generic and short.
 
As with most design requirements there are several that are at cross
purposes. Thus for anyone adding to this list these design criteria
should
be kept in mind and balanced against each other.
 
2. General Specification
 
In order to provide a framework both for the specifications in this
document
and for new ones to be written by others the following requirments are
placed on any documents that seek to specify new operations.
 
Any specification of a member of this set of operations MUST contain at
least the following pieces of information with respect to its operands,
its
algorithm and its output.
 
   * 2.1 Operands
 
     Must contain the following pieces of information:
        o name of the operation
        o mnemonic for the operation
        o number of operands
        o type of each operand
        o format of each operand
 
   * 2.2 Algorithm Must either specify the exact algorithm for the
operation
     or must specify that the algorithm is opaque and defined by the
server.

   * 2.3 Output Must either specify one of the following:
        o there is no output
        o the output is undefined
        o the output itself and its content
        o the fact that the output is an object and that objects type
and
          format.
 
3. Encoding The Operations
 
To be useful these operations have to be used within some system or
protocol. In many cases these systems and protocols will place
restrictions
on which operations make sense and how those that do are syntactically
represented.
 
Also, a given system or protocol will have its own output formats that
will
restrict the output formats of a given operation. Additionally, a given
protocol may have better solution for output than the ones given here.
For
example, the N2L result may be encoded in a protocol specific manner
that
causes the client to treat it as special.
 
Thus, the requirements on encoding these operations within a given
system
are the following:
 
   * which subset of the operations are allowed
   * how the operator is encoded
   * how the operands are encoded
   * what the output format is
 
For those system that can use it, MIME [4] is the suggested output
format.
The operations listed here use the text/uri-list Internet Media Type or
IMT
[4] that is specified in Appendix A. Other system are strongly
encouraged to
use this IMT. In the case where a system does not use an IMT a
justification
should be given.
 
4. The Incomplete Set
 
4.1 N2L (URN to URL)
 
   * name: URN to URL
   * mnemonic: N2L
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: 1 and only one URL encoded in a text/uri-list
 
This operation is used to map a single URN to a single URL. It is used
by
light weight clients that do not have the ability to select from a list
of
URLs or understand a Uniform Resource Characteristic (URC). The
algorithm
for this mapping is dependent on the URN namespace.
 
4.2 N2Ls (URN to URLs)
 
   * name: URN to URLs
   * mnemonic: N2LS
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: a list of 0 or more URLs encoded in a text/uri-list
 
This operation is used to map a single URN to 0 or more URLs. It is used
by
a client that can pick from a list of URLs based on some criteria that
is
important to the client. The client should not make any assumptions
about
the order of the URLs returned.
 
No matter what the particular media type, the result MUST be a list of
the
URLs that may be used to obtain an instance of the resource identified
by
the URN. All URIs shall be encoded according to the URI specification
[6].
 
4.3 N2R (URN to Resource)
 
   * name: URN to Resource
   * mnemonic: N2R
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * specified. instance of the resource named by the URN. Encoding is
not
 
This operation is used to return a single instance of the resource that
is
named by the URN. The format of the output is dependent on the resource
itself.
 
4.4 N2Rs (URN to Resources)
 
   * name: URN to Resources
   * mnemonic: N2Rs
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * is not specified. instances of the resource named by the URN.
Encoding
 
This operation is used to return multiple instances of a resource, for
example, GIF and JPEG versions of an image. The judgment about the
resources
being "the same" resides with the naming authority that issued the URN.
 
The output shall be a MIME multipart/alternative [4] message with the
alternative versions of the resource in separate body parts. If there is
only one version of the resource identified by the URN, it MAY be
returned
without the multipart/alternative wrapper.
 
4.5 N2C (URN to URC)
 
   * name: URN to URC
   * mnemonic: N2C
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A Uniform Resource Characteristic. Encoding is not
specified.
 
URCs (Uniform Resource Characteristics) are descriptions of other
resources.
This request allows the client to obtain a description of the resource
identified by a URN, as opposed to the resource itself or simply the
resources URLs. The description might be a bibliographic citation, a
digital
signature, a revision history, etc. This draft does not specify the
content
of any response to a URC request. That content is expected to vary from
one
server to another.
 
4.6 N2Ns (URN to URNs)
 
   * name: URN to URNs
   * mnemonic: N2Ns
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A list of URNs encoded in a text/uri-list IMT.
 
While URNs are supposed to identify one and only one resource, that does
not
mean that a resource may have one and only one URN. For example,
consider a
resource that has something like "current-weather-map" for one URN and
"weather-map-for-datetime-x" for another URN. The N2Ns service request
lets
the client obtain lists of URNs that are believed equivalent at the time
of
the request. As the weathermap example shows, some of the equivalences
will
be transitory, so the the server should convey the length of time for
which
the mapping is valid. The result is a list of all the URNs, known to the
server, which identify the same resource as the input URN. The result
shall
be encoded in a text/uri-list IMT.
 
4.7 L2Ns (URL to URNs)
 
   * name: URN to URNs
   * mnemonic: N2Ns
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A list of URNs encoded in a text/uri-list IMT.
 
This operation is used to discover the URN associated with a particular
URL.
As with all operations dealing with URNs how that URN is mapped is
completely dependent on the rules specified by the namespace.
 
4.8 L2Ls (URL to URLs)
 
   * name: URL to URLs
   * mnemonic: L2Ls
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A list of URLs encoded in a text/uri-list IMT.
 
This operation is used to discover URLs that are considered equal to
each
other. As with the N2N operation "equality" is defined by the server and
is
opaque to the client.
 
4.9 L2C (URL to URC):
 
   * name: URL to URC
   * mnemonic: L2C
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A URC.
 
This operation is used to retrieve the URC for a given URL. As with most
other URI mappings the mapping function is opaque. As with any other
operation that returns a URC, the output format is unspecified.
 
4.10 I2I (URI to URI):
 
   * name: URI to URI
   * mnemonic: I2I
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A URI.
 
This operation is used to map any arbitrary URI to any other arbitrary
URI.
No other assertions are made about whether or not the URI exhibits
characteristics of URNs or URLs.
4.11 N2I (URI to URI):
 
   * name: URN to URI
   * mnemonic: N2I
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A URI.
 
This operation is used to map a URN to any other arbitary URI. No other
assertions are made about whether or not the URI exhibits
characteristics of
URNs or URLs.
 
4.11 I=I (Is URI equal to URI):
 
   * name: URI = URI
   * mnemonic: I=I
   * number of operands: 2
   * type of each operand: Both operands are URIs
   * format of each operand: both operands are encoded as a URIs
   * algorithm: opaque
   * output: TRUE or FALSE
 
This operation is used to determine whether two given URIs are
considered to
be equal by the server being asked the question. The algorithm used to
determine equality is opaque. No assertions are made about whether or
not
the URIs exhibits characteristics of URNs or URLs.
 
6. The text/uri-list Internet Media Type
 
     [This section will be augmented or replaced by the registration of
     the text/uri-list IMT once that registration has been performed].
 
Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns,
L2Ls,
result in a list of URIs being returned to the client. The text/uri-list
Internet Media Type is defined to provide a simple format for the
automatic
processing of such lists of URIs.
 
The format of text/uri-list resources is:
 
  1. Any lines beginning with the '#' character are comment lines and
are
     ignored during processing. (Note that '#' is a character that may
     appear in URIs, so it only denotes a comment when it is the first
     character on a line).
  2. The remaining non-comment lines MUST be URIs (URNs or URLs),
encoded
     according to the URI specification RFC[6]. Each URI shall appear on
one
     and only one line.
  3. As for all text/* formats, lines are terminated with a CR LF pair,
     although clients should be liberal in accepting lines with only one
of
     those characters.
  4. The order of the URIs given MUST be preserved upon retransmission.
The
     client should not make any inferences about what the order of the
     returned list means.
 
In applications where one URI has been mapped to a list of URIs, such as
in
response to the N2Ls request, the first line of the text/uri-list
response
SHOULD be a comment giving the original URI.
 
An example of such a result for the N2L request is shown below in figure
1.
             --------------------------------------------------
 
     # urn:cid:[email-masked]
     http://www.huh.org/cid/foo.html
     http://www.huh.org/cid/foo.pdf
     ftp://ftp.foo.org/cid/foo.txt
 
                Figure 1: Example of the text/uri-list format
             --------------------------------------------------
 
7. References
 
[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System",
draft-ietf-urn-naptr-02.txt,
    February, 1997.
 
[2] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997.
 
[3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax
for
    the Expression of Names and Addresses of Objects on the Network as
    used in the World-Wide Web", T. Berners-Lee, June 1994.
 
[4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One:
    Mechanisms for Specifying and Describing the Format of Internet
Message
    Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft,
    September 1993.
 
8. Security Considerations
 
Communications with a server may be of a sensitive nature. Some servers
will
hold information that should only be released to authorized users. The
results from servers may be the target of spoofing, especially once
electronic commerce transactions are common and there is money to be
made by
directing users to pirate repositories rather than repositories which
pay
royalties to rights-holders. Server requests may be of interest to
traffic
analysts. The requests may also be subject to spoofing.
 
9. Author Contact Information
 
Michael Mealling
Network Solutions
505 Huntmar Park Drive
Herndon, VA 22070
voice: (703)742-0400
fax: (703)742-9552
email: [email-masked]
 
Ron Daniel
Advanced Computing Lab, MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA, 87545
voice: +1 505 665 0597
fax: +1 505 665 4939
email: [email-masked]

From: [email-masked] (Jul,Erik)
To: [email-masked] ('smtp:[email-masked]')
Organization: OCLC Inc, Dublin, Ohio USA (614)764-6000
Date: Wed, 26 Mar 1997 16:45:14 -0500
Subject: RE: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: [email-masked] (Jul,Erik)

Dear All:

Much of this document seems unenforceable to me.   Examples below.

 --Erik

> Requirements:
> =============

> Given the four categories above, the requirements for each our
> now outlined.

 > Global Scope and Uniqueness.

>  - Rules on how the Namespace Specific String are allocated
>    must be documented.

By whom?  When?  How?  According to what standard?  Where stored?   By whom? 
 for how long?  How accessed?  At what cost?  Who bears cost?  How 
transferred?  How modified?  Who needs to know?  Why?  What will they do 
with it?

>  - Definitions of terms like "equal" and "different" for resources
>    must be published.

Same list of questions.

>  Persistence

 >  - The NID service providers must show that they intend to
>      support the service for an indefinite period of time.

Show?  How?  Promise?  Contract?  With whom?  How enforced?  How judged 
credible?  What is the standard for measuring intent?

> - Support facilities must be described and how the service
 >   intends to operate, including "disaster recovery"-like
>    operations.

You mean before you will let me run a URN resolver I have to satisfy some 
agency or board?

>  - Demonstrated experience in managing an established namespace
>   system is essential.

Demonstrated according to what criteria?  Who is to judge?

I'm sorry.  I think this document does not work well as a requirements 
document.  Too much is left unsaid.  How could it ever be implemented?  How 
could adherence be judged?

 --Erik

Erik Jul
[email-masked]

Date: Wed, 26 Mar 1997 16:23:58 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] Requirements internet draft
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

There are changes scattered throughout the whole document (although
very little in the framework section) based on the mailing list
discussions.  Thanks everyone!

			Karen

______________________________

Internet Draft                                          Karen R. Sollins
draft-ietf-urn-req-frame-01.txt                                  MIT/LCS
Expires September 28, 1997                                March 28, 1997

	Requirements and a Framework for URN Resolution Systems

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 local URN
resolver services that in turn will directly translate URNs into
URLs and URCs.  The document falls into three major parts, the
assumptions underlying the work, the requirements in order to be a
viable Resolver Discovery Service or RDS to help in finding URN
resolvers, and a framework for designing RDSs.  The requirements fall
into three major areas: evolvability, usability, and security and
privacy.  An RDS that is compliant with the framework will not
necessarily be compliant with the requirements.  Compliance with the
requirements 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 resolvers.  This is a
component of the realization of an information infrastructure.  In the
case of this work, that infrastructure is to be available, "in the
Internet" or globally, and hence the solutions to the problems we are
addressing must globally scalable.  In this work, we are focussing
specifically on naming of resources and resolution of those names to
the exclusion of other problems such as typing, resource access and
availability, security of the resources, etc.  Those are all important
problems, but not part of this effort.

The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736[RFC1736],

                                 - 1 -

1737{RFC1737}, and 1738[RFC1738].  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 full-qualified Domain Names or IP addresses.  Names may provide
the ability to distinguish one resource from another, by
distinguishing their "names".  Names may help to provide access to a
resource by including "location" information.  Lastly, names may have
other semantic or mnemonic information that either helps human users
remember or figure out the names, or include other semantic
information about the resource being named.  The URI working group
concluded that there was need for persistent, globally unique
identifiers, distinct from location or other semantic information;
these "names" provide identity, in that if two of them are "the same"
(under some simple rule of canonicalization), they identify the same
resource.  Furthermore, the group decided that these "names" were
generally to be for machine, rather than human consumption.  One can
imagine a variety human-friendly naming (HFN) schemes supporting
different suites of applications and user communities.  These will
need to provide mappings to URNs in tighter or looser couplings,
depending on the namespace.  It is these that will be mnemonic,
content-full, and perhaps mutable, to track changes in use and
semantics.  They may provide nicknaming and other aliasing, relative
or short names, context sensitive names, descriptive names, etc.  The
URI naming architecture as described in the introductions to RFCs 1736
and 1737 lays out three sorts of components to the naming
architecture: identifiers called Uniform Resource Names (URNs),
locators called Uniform Resource Locators (URLs) and semantic
meta-information called Uniform Resource Characteristics (URCs).  This
document focusses on part of the problem of the translation from URN
to URL and/or URC.

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
that helps in the resolution of a URN; we map URNs to hints as an
interim stage in accessing a resource.  A hint may also have
meta-information associated with it, such as an expiration_time or
certification of authenticity.  We expect that these will stay with a
hint rather than being managed elsewhere.  We will assume in all
further discussion of hints that they include any necessary
meta-information as well as the hint information itself.  Examples of
hints are: 1) the name of a resolver service that may further resolve
the URN, 2) the address of such a service, 3) a location at which the
resource was previously found.  The defining feature of hints is that
they are only hints; they may be out of date, temporarily invalid, or
only applicable within a specific locality.  They do not provide a
guarantee of access, but they probably will help in the resolution
process.  We must assume that most resolutions of URNs will be
provided by the use of locally stored hints, because maintaining a
database of globally available, completely up-to-date location
information is infeasible for performance reasons.  There are a number
of circumstances in which one can imagine that hints become invalid,
either because a resource has moved or because a different URN
resolver service has taken over the responsibility for resolution of
the URN.  Hints may be found in a variety of places.  It is generally
assumed that a well engineered system will maintain a set of hints for

                                 - 2 -

each URN at each location where that URN is found.  In addition, for
those situations in which those hints found locally fail, a
well-engineered system will provide a fall-back mechanism for
discovering further hints.  It is this fall-back mechanism, an RDS,
that is being addressed in this document.  As with all hints, there
can never be a guarantee that access to a resource will be available
to all clients, even if the resource is accessible to some.  However,
an RDS is expected to work with reasonably high reliability, and,
hence, may result in increased response time.

The remainder of this document falls into three sections.  The first
identifies several sets of assumptions underlying this work.  The next
lays out the requirements for a Resolver Discovery Service.  This
section is probably the most critical of the document, because it is
this that provides the metric for whether or not a proposed scheme for
a RDS is adequate or not.  For the reader short on time, each of the
three major subsections of the requirements section begins with a
summary list of the requirements identified in that section.  The
final section of the document lays out a framework for such RDSs.  The
purpose of this last section is to bound the search space for RDS
schemes.  One must be careful not to assume that because an RDS scheme
fits within the framework that it necessarily meets the requirements.
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 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" assumes that everything will move
over the life of a URN.  For example, resources will move from one
machine to another, because individual machines have a much shorter
lifetime than resources, generally measured in a number of years less
than a decade.  Owners of resources may move and wish their resources to
follow them.  The services themselves will move.  "Evolution" assumes
that the supporting infrastructure will evolve.  This may take the form
of entirely new transport protocols or new versions of existing
protocols.  Furthermore, services such as storage services may evolve;
it is even possible that within a human lifetime the Unix file system
model may no longer be in use!  Clearly there will be evolution of and
improvement in supporting authentication and security mechanisms.  These
are only examples.  In general, we must assume that almost any piece of
the supporting infrastructure of URN resolution will evolve.  In order
to deal with both the mobility and evolution assumptions that derive
from the assumption of longevity, we must assume that users and their

                                 - 3 -

applications can remain independent of these mutating details of the
supporting infrastructure.

The second and third assumptions are two forms of modularity: delegation
and isolation.  The delegation assumption is that an entity may
partition and pass off some of its authority or responsibility.  One of
those responsibilities is for assigning URNs; practically speaking,
there cannot be only a single authority for assigning URNs.  We expect
that there will be a multi-tiered naming authority delegation.
Furthermore, it is difficult to imagine a non-partitioned and delegated
global RDS, meaning that hint discovery and resolution will be
partitioned and delegated.  In some RDS schemes, the delegation of
naming authority will form a basis for delegating the management and
dispensing of location information.

The third assumption is independence or isolation of one authority from
another and, at least to some extent from its parent.  Underlying much
of the thinking and discussion in the URI and URN working groups has
been the assumption that when a component delegates authority to another
component, the delegatee can operate in that domain independently of its
peers and within bounds specified by the delegation, independently of
the delegator.  This isolation is critically important in order to allow
for independence of policy and mechanism.

There are a number of more specific assumptions that fall under this
rubric of isolation.  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 just identified or
located by the RDS service.  Second, it must be possible to make a
choice among RDS services, perhaps based on different underlying
internal architectures.  The reason that this is an assumption is that
there must be an evolutionary path through a sequence of core RDS
services.  Although at any given time there is likely to be only one or
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.

                                 - 4 -

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 requirements for a Resolver Discovery Service.

3. Requirements

The requirements applying to a Resolver Discovery Service or RDS
center around three important design goals: 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 requirement,
every implementation must support evolution to systems that do support
every requirement.

It is important to note that there are other requirements, not
applicable specifically to an RDS that must also be met.  A whole URN
system will consist of namespaces, the resolution information for them,
and the mapping from names in the namespaces to resolution information
(or hints).  URN schemes must meet the requirements of RFC 1737.
Resolution information, to the extent it is expressed as URLs must meet
the requirements of RFC 1736.  But this does not tell the whole story.
Although the URN working group will identify several acceptable
namespaces and the rules binding them, such as how delegation occurs,
how it is expressed in the names, how and to what extent binding to hint
information will be constrained by the namespace, in the long run a
document will be needed to guide the evaluation criteria for acceptance
of new namespaces.  These are not included in the list of requirements
below because they are not requirements for an RDS, but rather for naming
schemes themselves.

Each section below begins with a summary of the points made and discussed 
in the following discussion.  It is worth noting here that there is
some degree of overlap in the areas of requirements, such as in
allowing for the evolution of security mechanisms, etc.  Issues may
appear in more than one requirement.  It is also important to
recognize that conformance with the requirements may often be
subjective.  Most of these requirements are not quantifiable and hence
conformance is a judgment call and a matter of degree.  Lastly, the
reader may find that some of the requirements are those of general
applicability to distributed systems and some are specific to URN
resolution.  Those of general applicability are included for
completeness and are not distinguished as such.

3.1 Evolution

The requirements in the area of evolvability are:

   [R1] To support evolution of mechanisms, specifically for
          {R1.1] a growing set of URN schemes;

                                 - 5 -

          [R1.2] new kinds local URN resolver services;
          [R1.3] new authentication schemes;
          [R1.4] alternative RDS schemes active simultaneously;
   [R2] To support the separation of global identification from
        location information. 
   [R3] To allow for the support the development and deployment of
        administrative control mechanisms to manage human behavior
        with respect to limited resources. 

One of the lessons of the Internet that we must incorporate into the
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, even at this time, prior to the
deployment of any such service.  At the very least, the community and
the mechanisms proposed should be prepared for these.

First, 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.  A URN scheme will define a set of URNs that meet the URN
requirements[RFC1737], but may have further constraints on the internal
structure of the URN.  The requirements document would allow for an
overall plan in which URN schemes are free to specify parts of the URN
that are left opaque in the larger picture.  In fact, a URN scheme may
choose to make public the algorithms for any such "opaque" part of the
URN.  For example, although it may be unnecessary to know the structure
of an ISBN, the algorithm for understanding the structure of an ISBN has
been made public.  Other schemes may either choose not to make their
algorithms public, or choose a scheme in which knowledge of the scheme
does not provide any significant semantics to the user.  In any case, we
must be prepared for a growing number of URN schemes.

Often in conjunction with a new URN scheme, but possibly independently
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.  In any case, 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

                                 - 6 -

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, there will always be threats to it, and so
we must always be prepared to move on to newer and better schemes, as
the old ones become too easily spoofed or guessed.

Lastly, in terms of mechanism, although we may develop and deploy a
single RDS scheme initially, we must be prepared for that top level
model to evolve.  Thus, if the RDS model supports an apparently
centralized (from a policy standpoint) scheme for inserting and
modifying authoritative information, over time we must be prepared to
evolve to a different model, perhaps one that has a more distributed
model of authority and authenticity.  If the model has no core but
rather a cascaded partial discovery of information, we may find that
this becomes unmanageable with an increase in scaling.  Whatever the
core of the model, we must be prepared for it to evolve with changes in
scaling, performance, and policy constraints such as security and cost.

Second, in addition to the evolution of resolution mechanisms, we
expect that the community will follow an evolutionary path towards the
separation of location information from identification.  The URN
requirements document suggested this path as well, and there has been
general agreement in much of the community that such a separation is
desirable.  This is a problem that the public at large has generally
not understood.  Today we see the problem most clearly with the use of
URLs for identification.  When a web page moves, its URL becomes
invalid.  Suppose such a URL is embedded in some page, stored in long
term storage.  There are three possible outcomes to this scenario.
One possibility is that the client is left high and dry with some
message saying that the page cannot be found.  Alternatively, a
"forwarding pointer" may be left behind, in the form of an explicit
page requesting the client to click on a new URL.  Although this will
allow the client to find the intended page, the broken link cannot be
fixed because the URL is embedded in a file outside of the client's
control.  A third alternative is that the target server supplies an
HTTP redirect so that the new page is provided for the client
automatically.  In this case, the client may not even realize that the
URL is no longer correct.  The real problem with both of these latter
two situations is that they only work as long as the forwarding
pointer can be found at the old URL.  Location information, was
embedded in the identifier, and the resolution system was designed to
depend on that location information being correct.  There are few
cases in which we can expect such information to remain valid for a
long time, but in many cases references need to have long lifespans.
Most documents are only useful while their references still function.
To the extent that an RDS scheme supports the separation of global
identification from location information it will be encouraging the
longer utility of the identities.

A third evolutionary requirement 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 the

                                 - 7 -

service.  Ideally, the service would be providing exactly what the
customers wanted and they in turn would not request more support than
they need.  Since we will always be in a situation in which some
service provision resources will be in short supply, some form of
policy controls will always 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.  An effective solution to this problem would be a
mechanism such as a pricing policy.  This pricing policy has the dual
effect of both encouraging conservative use of resources and
collecting revenue for the improvement and maintenance of the system.
We can also imagine administrative policy controls with the force of
laws or other social pressures behind them, but with no technical
mechanism enforcing or enabling them.  As technology changes and the
balance of which resources are in short supply changes, the mechanisms
and policies for controlling their use must evolve as well.

3.2 Usability and Feature Set Requirements

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

   * The publisher
      [R4] URN to hint resolution must be correct and efficient with
           very high probability;
      [R5] Publishers must be able to select and move among URN
           resolver services to locate their resources;
      [R6] Publishers should be able to arrange for multiple access
           points for their location information;
      [R7] Publishers must be able to provide for both long-lived and
           short-lived hints;
      [R8] It must be relatively easy for publishers to specify to the
           management and observer their hint information as well as
           any security constraints they need for their hints.
   * The client
      [R9] The interface to the RDS must be simple, effective, and
           efficient;
      [R10] The client and client applications must be able to understand
           the information stored in and provided by the RDS easily,
           in order to be able to make informed choices.
   * The management
      [R11] The management of hints must be as unobtrusive as possible,
           avoiding using too many network resources;
      [R12] The management of hints should allow for administrative
           controls that encourage certain sorts of behavior deemed
           necessary to meet other requirements;
      [R13] The configuration and verification of configuration of
           individual RDS servers must be simple enough not to
           discourage configuration and verification.

Usability can be evaluated from three distinct perspectives: those of a
publisher wishing to make a piece of information public, those of a

                                 - 8 -

client requesting URN resolution, and those of the provider or manager
of resolution information.  We will separately address the usability
requirements 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 also 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 resolver services, the
architecture for resolver services specified within the IETF should
not result in a scenario in which changing from one resolver service
to another is an expensive operation.

The publisher should be able to arrange for multiple access points to a
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.  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 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 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.

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 to install hint

                                 - 9 -

information.  The publisher must be able not only to express hints, but
also to verify that what is being served by the manager is correct.
Furthermore, to the extent that there are security constraints on hint
information, the publisher must be able to both express them and verify
compliance with them easily.

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.

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 to the extent that there is a commitment for provision of such
security; this is addressed below.

The management of hints must be as unobtrusive as possible. First, its
infrastructure (hint storage servers and distribution protocols) should
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.

                                 - 10 -

Second, in order to make hint management feasible, there may need to
be a system for administrative incentives and disincentives such as
pricing or legal restrictions.  Recovering the cost of running the
system is only one reason for levying charges.  The introduction of
payments often has a beneficial impact on social behavior.  It may be
necessary to discourage certain forms of behavior that when out of
control have serious negative impact on the whole community.  At the
same time, any 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 requirement 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 requirement,
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 Requirements

SUMMARY: Security and privacy requirements can be identified as some
degree of protection from threats.  These requirements are all stated
in terms of possibilities or options for users of the service to
require and utilize.  Hence they are requirements for the availability
of functionality, but not for the use of it.  We recognize that all
security is a matter of degree and compromise.  These may not satisfy
all potential customers, and there is no intention here to prevent
them from building more secure servers with more secure protocols to
suit their needs.  These are intended to satisfy the needs of the
general public.

   [R14] It must be possible to create authoritative versions of a hint
         with access-to-modification privileges controlled;
   [R15] It must be possible to determine the identity of servers or avoid
         contact with unauthenticated servers;
   [R16] It must be possible to reduce the threat of denial of service
         by broad distribution of information across servers.

                                 - 11 -

   [R17] It must be possible within the bounds of organization policy
         criteria to provide at least some degree of privacy for
         traffic.
   [R18] 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;
   [R19] 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.  

A good place to begin is with the early work of Voydock and Kent
[VK83].  They identify unauthorized release of information as a
passive attack, and all three of unauthorized modification of
information, denial of service, and spurious association initiation as
active attacks.  An intruder at any protocol layer can attack at any
of the links or computational elements (hosts, routers, etc.) at that
layer.  Attacks at one layer can be achieved by subverting or
attacking the lower layers.  An unauthorized release of information is
a violation of privacy or confidentiality.  This may be achieved by a
release of the information itself.  Additional passive threats are
from secondary information through traffic analysis or other
violations of transmission security, such as noticing lengths and/or
sources and destinations of traffic.  Moving to the active threats,
unauthorized modification of information can be partitioned into
problems with authenticity, integrity and ordering.  Denial of service
may take the form of discarding information before it reaches its
destination or some degree of delay in delivering information.
Finally, spurious association may occur when a previous legitimate
association initiation is played back or an initiation is made under
false identity.  Security measures may take the form of either
detection or prevention of each of these threats.  Within the scope of
this work, we must identify those threats that are both of concern and
that we expect to be able to mediate.  Of these threats the prevention
of passive attacks is known to be a particularly difficult problem to
address in the general case.

Of these threats, the passive threats to privacy or confidentiality
and the active threats of authenticity and integrity are probably the
most important to consider here.  To the extent that spurious
association causes threats to the privacy, authenticity, or integrity
with respect to information within servers managing data, it is also
important.  Because updates to hint information are idempotent, at
least with short periods of time, we will set aside the problems of
ordering for this analysis.  Denial of service is probably the most
difficult of these areas of threats both to detect and to prevent, and
we will therefore set it aside for the present as well, although it
will be seen that solutions to other problems will also mitigate some
of the problems of denial of service.  Furthermore, because this is

                                 - 12 -

intended to be provide a global service to meet the needs of a variety
of communities, the engineering tradeoffs will be different for
different clients.  Hence the requirements are stated in terms of,
"It must be possible..."  It is important to note that the
information of concern here is hint information, which by nature is
not guaranteed to be correct or up-to-date; therefore, it is unlikely
to be worth putting too much expense into the correctness of hints,
because there is no guarantee that they are still correct anyway.  But
the exact choice of degree of privacy, authenticity, and integrity
must be determined by the needs of the client and the availability of
services from the server.

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

The first approach to URN resolution is to discover local hints.  In
order for hints to be discovered locally, they will be as widely
distributed to what is considered to be local for every locale.  The
drawback of such wide distribution is the wide distribution of
updates, causing network traffic problems or delays in delivering
updates.  An alternative model would concentrate hint information in
servers, thus requiring that update information only be distributed to
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 other a fake owner of the information or a fake server to the
extent that servers exchange updates with each other.  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 goals for our security model:

* 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. 

                                 - 13 -

* 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 data.

* 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 is a more difficult problem to address.  It may be a
double-edged sword; for example, an organization may consider it
critically important that its competitors not be able to read its
traffic, while it may also consider it important to be able to monitor
exactly what its employees are transmitting to and from whom, for a
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 will 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.

The other 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 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

                                 - 14 -

case because the identity of the final recipient is known (i.e. the
URN server).

4. The Framework

With these assumptions and requirements in mind, one can conclude with a
general framework within which RDS designs will 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 requirements.  Such an evaluation must be performed separately.
It is also understood that there may be RDS services that do not meet
the requirements in clearly identified ways.  This may be true
especially with early plans and experiments.  For example, although a
careful threat analysis may have been done to understand security
requirements, not all those security requirements may be addressed, in
order to use existing facilities to allow for early deployment for
experimentation purposes.  All such lack of compliance should be clearly
documented.

The design of the framework is based on a simple assumption about the
syntax of a URN a documented in RFC-XXX[RFCXXX}.  This assumed syntax
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 probably 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 the NID alone or in conjunction with some extraction from the
NSS (for the top level naming authority name) is to be used to

                                 - 15 -

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 private 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
 				  +----------+		  +----------+
 				  |private   |		  |private   |
                                  |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

                                 - 16 -

scheme.  Second, it leaves open the location of the computations
engendered by the rules.  Third, it leaves open the possibility that
partitioning (distribution) of the RDS database need not be on the
same boundaries as 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.  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 between 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 N RDS schemes.  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.  Such a situation should
probably be avoided, if possible.

This framework is presented in order to suggest to RDS scheme
designers a direction in which to start designing.  It should be
obvious to the reader that adherence to this framework will in no way
guarantee compliance with the requirements or even assumption
described in Sections 2 and 3.  These must be reviewed independently
as part of the design process.  There is no single correct design that

                                 - 17 -

will meet these requirements.  Furthermore, it is assumed that
preliminary proposals may not meet all the requirements, but should be
expected to itemized and justify any lack of compliance.

5. Acknowledgments

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

6. References

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

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

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

[RFCXXX] Moats, Ryan, "URN Syntax", currently available as
draft-ietf-urn-syntax-04.txt, March, 1997.

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

7. Contact information:

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

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

This Internet Draft expires on September 28, 1997.

                                 - 18 -

Date: Wed, 26 Mar 1997 22:04:04 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: [email-masked]
Cc: [email-masked], Renato Iannella <[email-masked]>, Leslie Daigle <[email-masked]>
Subject: [URN] draft-ietf-urn-nid-req-01.txt
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

INTERNET DRAFT                                             Renato Iannella
draft-ietf-urn-nid-req-01.txt                                 DSTC Pty Ltd
25 March, 1997                                            Patrik Faltstrom
                                                             Tele2/Swipnet

            Namespace Identifier Requirements for URN Services

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).

    This draft expires 25 September, 1997.

Abstract:
=========

Services that offer to resolve Uniform Resource Names implicitly
require that they support a persistent and reliable service for an
indeterminate length of time. This draft outlines the requirements for
any such service that wishes to participate as a Namespace Identifier.

Introduction:
=============

The Uniform Resource Name (URN) Working Group has defined mechanisms
for both the syntax [4] and resolution of URNs [1,2]. An framework
for URN discovery systems has also been outlined [3]. This draft
discusses and recommends the requirements for entities that wish
to act as Namespace Identifiers (NIDs) within the URN system.

The URN syntax includes the NID which acts as the scoping
indicator for the URN. The NID indicates which Namespace
the URN belongs to and gives hints to the underlying resolution
service.

Consider the following example URNs:

   urn:znet:metadata.net:dc
   urn:buns:555555:annual-report
   urn:hoptus:priv:555-ABCD

The NIDs in these cases, "znet", "buns", and "hoptus" all
act as top-level namespaces, and hence, must meet certain
guidelines to ensure meeting all the URN requirements [5].
In particular:
   - Global Scope and Uniqueness
   - Persistence
   - Independence
   - Resolution

Requirements:
=============

Given the four categories above, the requirements for each our
now outlined.

 Global Scope and Uniqueness.

  - The NID must be registered with IANA to ensure uniqueness and
    demonstrating that it meets the requirements listed in this
    document.
  - A simple and limited character set should be imposed to 
    support global access (as described in [4]).
  - Rules on how the Namespace Specific String are allocated
    must be documented.
  - Definitions of terms like "equal" and "different" for resources
    must be published.

 Persistence

  - The NID service providers must show that they intend to
    support the service for an indefinite period of time.
  - Support facilities must be described and how the service
    intends to operate, including "disaster recovery"-like
    operations.
  - Demonstrated experience in managing an established namespace
    system is essential.    
  - One URN should never be reused for a different resource (where
    "different" is defined as in previous paragraph by the namespace).
    The URN should be persistent for all times, even though the
    resource goes away.

 Independence

  - The NID service providers must also show any relationship
    (both technical and administrative) that may impede on the
    provision of the URN service.
  - However, multi-party participation in the NID service is
    an advantage.

 Resolution

  - The NID service providers must produce an RFC
    describing the technical characteristics of the URN
    resolution service, including security considerations.
  - The NID service providers may elect not to have the
    resolution service publically available.

Example:
=======

(1) urn:buns:555555:annual-report

This URN, in the namespace called "buns" is referring to the
document named annual-report, in postscript format. 

At a later stage, that resource is replaced by a text version, which
lacks the pictures, but that is ok, because the namespace has decided
that postscript format documents and text documents are considered the
same even though the figures doesn't exist in the textual version.

In the third stage, the report is removed, and replaced with a report
for a different year. This new report gets a new URN because it is
considered being a different document.

The old URN is never reused.

(2) urn:foo:bar:current-weather
    urn:foo:bar:weather/19970325

These are two URNs referring at one stage to the same resource, i.e.
on the 25th of March 1997. On the 26th of March 1997,
urn:foo:bar:current-weather is referring to the same resource as
urn:foo:bar:weather/19970326.

Conclusion:
===========

This draft has outlined the requirements for providers of
NID services for URN systems. The objective is to maintain 
a high persistence rate for URN services, and these requirements
are aimed at ensuring a high level of service stability.

References:
===========

[1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
    February, 1997.

[2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
    draft-ietf-urn-http-conv-01.txt, February 1997

[3] Karen R Sollins, "Requirements and a Framework for URN Resolution
    Systems", draft-ietf-urn-req-frame-00.txt, November 1996

[4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997.

[5] Karen R Sollins & Larry Masinter, "Functional Requirements for
    Uniform Resource Names", RFC1737, December 1994

Security Considerations
=======================

It is a requirement that it in the definitions of a namespace are
included sections on security covering for example:

  + Spoofing of servers
  + Verification of responses

Because a namespace can decide that a resolution service is not
publically available, it is possible to use firewall installations and
other traffic limiting constructions to diconnect the namespace from
the global Internet.

Author Contact Information:
===========================

Renato Iannella
DSTC Pty Ltd
Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072
voice:  +61 7 3365 4310
fax:    +61 7 3365 4311
email:  [email-masked]

Patrik Faltstrom
Tele2/Swipnet
Borgarfjordsgatan 16
P.O. Box 62
S-164 94 Kista
SWEDEN
voice:  +46-5626 4000
fax:    +46-5626 4200
email:  [email-masked]

Date: Wed, 26 Mar 1997 00:04:18 -0700
To: "Karen R. Sollins" <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] comments on Sollins' requirements draft
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 05:54 PM 3/24/97 -0500, Karen R. Sollins wrote:
>Ron,
>
>[...] here's what you said:
>
>
>   This implicit establishment of the security policy that must be obeyed
>   by URN resolvers shows up in several other places. There are many
>   sentences where you say that something "must" exist which I would
>   like to change to saying "must be capable of supporting". For example
>   you say that "There needs to be an authoritative version of each hint,
>   and it must support change control limited only to those principals
>   with the right to modify it". I would prefer a different wording:
>   "Each resolution hint shall have an authoritative instance. It
>   must be possible to restrict changes to the authoritative hint
>   according to the security policy of the organization issuing the hint.
>   Propagation of changes to the authoritative version to any sites mirroring
>   it must be capable of being carried out in a fashion consistent with
>   the security policy governing the operation of the mirroring service."
>   (Actually, I would prefer something less awkward, but I digress. :-)
>
>And my questions are:
>
>1) What did you mean by "resolution hint"?  My suspicion is that you
>meant a hint that leads to a resolution server, and I will assume that
>for my real question, but I realized that I'd better be sure we're on
>the same wavelength.

I think it applies to both information that isused to find a resolver
and information at the resolver that gets us to the resource.

>2) Is it necessary (and this a question you could have asked of me as
>well) that there be an authoritative version of every hint?
>Personally I don't think so.  I believe that there may be hints that
>are intended just to be helpful, but non-authoritative.  I make a copy
>of a resource and make it available to anyone who cares to use it.  I
>put a hint out.  I may not want to be viewed as "authoritative" in any
>way and it certainly doesn't come from anyone who has authority over
>the resource.

That's not what I said. I said that the *hint* has an authoritative
instance, not that the hint *was* authoritative for the resource. For
example, if you have put up a local copy of a resource, and issue a hint
telling people where to find that copy, and I copy your hint, I have a
non-authoritative version of the hint. You have issued the authoritative
version of the hint that gets people to your local copy of the resource.

However, with that clarification out of the way, I'm not positive that
every hint needs to have an authoritative version although I suspect
that is the case.

>(I think not, so in that sense, I think both of us went
>overboard a little.)

Overboard? Us?  Surely not!  ;-)
 
Saying "may" instead of "must" seems the appropriate thing to do
right now.

>3)  as I read your
>suggested re-writing the RDS must provide whatever security policy
>each organization wants (with no restrictions) for its hints.

Clearly this is impossible. However, I think that we can make a
good stab at providing the tools that are needed in most reasonable
security policies. For example, if an RDS proposal required all
transactions to be encrypted with DES, I would find that objectionable.
If it allowed transactions to be encrypted using an arbitrary
encryption technique, that would be fine. Then we could use specialized
encryption algorithms.

>believe that we can only take a less restrictive position and say that
>there are certain policies and levels of security that an RDS can
>provide and an organization can choose among them.

There are certain tools, such as signatures, key-exchanges, and
encryption. For any of these tools there are a set of algorithms
that could be used (DES vs. IDEA for encryption, etc.). RDS proposals
should provide a set of tools, and indicate a way for different algorithms
for those tools to be identified. Basic tools are well-known and most
security policies (not all) can be built from them.

Actually saying there are pre-defined policies and levels is different.
That is telling me a lot more about what I must and must not do, and
it is *totally* objectionable to my organization. We have particular
procedures we must follow. They will never be proposed as IETF standards.
Nevertheless, they are built on general tools, such as key exchange
and encryption. 

>If these [security policies and levels] do not
>provide the degree and type of security that the organization feels it
>needs then I guess they won't use our service.

Karen, security policies change at organizational boundries. Nobody is
going to use an RDS that mandates how they will and will not secure
their information.

>But, I don't believe
>that we can make the unconditional requirement that says, "It must be
>possible to restrict changes to the authoritative hint according to
>the security policy of the organization issuing the hint."  Is that
>really what you meant to say?

With the understanding that not all security policies can be implemented,
yes.

>4) One last minor question about the following sentence, "Propagation
>of changes to the authoritative version to any sites mirroring it must
>be capable of being carried out in a fashion consistent with the
>security policy governing the operation of the mirroring service."
>Shouldn't this                                 ^^^^^^^^^
>
>be "mirrored"?

Probably.

Regards,
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: Tue, 25 Mar 1997 07:19:26 -0800
To: [email-masked]
From: Cecilia Preston <[email-masked]>
Subject: [URN] draft Bibliographic Identifiers to URNs
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: Tue, 25 Mar 1997 13:23:00 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Leslie Daigle <[email-masked]>
Cc: [email-masked]
Subject: [URN] Experimental Baby Namespace stuff...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Leslie-

Under the "agenda" stuff, I'm putting the finishing touches on the
experimental "baby" namespace stuff I've been working on, so I'd
like 5-15 minutes in Memphis just to announce it.

Ryan

Date: Tue, 25 Mar 1997 12:58:39 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] I-D CUTOFF deadline
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Just a reminder to all people who have promised or otherwise intended
to send in material to be discussed at the Memphis URN meeting -- the
deadline to submit I-D's is TOMORROW, at 5pm (EST).  

I'm holding my breath....

Leslie.

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

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

Date: Mon, 24 Mar 1997 17:54:00 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] comments on Sollins' requirements draft
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Ron,

I am pulling a bit out of a message you sent out shortly after I put
out the requirements doc, because it brings up several questions.  In
general the rest of what you said was a good set of points and I'm
working on them.  Meanwhile, here's what you said:

   This implicit establishment of the security policy that must be obeyed
   by URN resolvers shows up in several other places. There are many
   sentences where you say that something "must" exist which I would
   like to change to saying "must be capable of supporting". For example
   you say that "There needs to be an authoritative version of each hint,
   and it must support change control limited only to those principals
   with the right to modify it". I would prefer a different wording:
   "Each resolution hint shall have an authoritative instance. It
   must be possible to restrict changes to the authoritative hint
   according to the security policy of the organization issuing the hint.
   Propagation of changes to the authoritative version to any sites mirroring
   it must be capable of being carried out in a fashion consistent with
   the security policy governing the operation of the mirroring service."
   (Actually, I would prefer something less awkward, but I digress. :-)

And my questions are:

1) What did you mean by "resolution hint"?  My suspicion is that you
meant a hint that leads to a resolution server, and I will assume that
for my real question, but I realized that I'd better be sure we're on
the same wavelength.

2) Is it necessary (and this a question you could have asked of me as
well) that there be an authoritative version of every hint?
Personally I don't think so.  I believe that there may be hints that
are intended just to be helpful, but non-authoritative.  I make a copy
of a resource and make it available to anyone who cares to use it.  I
put a hint out.  I may not want to be viewed as "authoritative" in any
way and it certainly doesn't come from anyone who has authority over
the resource.  Or, in another circumstance, I am the authority for a
resource and the network has become partitioned so that both the
"authoritative resolution server" for my resource and my storage
system from which it is available are not accessible.  I reach a
temporary agreement with a friend to make my resource available
non-authoritatively for a short while and provide non-authoritative
resolution to this non-authoritative copy, until the network is fixed.
I may want to get the hints for this out as quickly and simply as
possible, which may mean non-authoritatively.  Should we disallow
that?  (I think not, so in that sense, I think both of us went
overboard a little.)

3) If I assume that the answer to question 1 is that a "resolution
hint" is a hint for a resolution service, then as I read your
suggested re-writing the RDS must provide whatever security policy
each organization wants (with no restrictions) for its hints.  I
believe that we can only take a less restrictive position and say that
there are certain policies and levels of security that an RDS can
provide and an organization can choose among them.  If these do not
provide the degree and type of security that the organization feels it
needs then I guess they won't use our service.  But, I don't believe
that we can make the unconditional requirement that says, "It must be
possible to restrict changes to the authoritative hint according to
the security policy of the organization issuing the hint."  Is that
really what you meant to say?

4) One last minor question about the following sentence, "Propagation
of changes to the authoritative version to any sites mirroring it must
be capable of being carried out in a fashion consistent with the
security policy governing the operation of the mirroring service."
Shouldn't this                                 ^^^^^^^^^

be "mirrored"?

			Karen

Date: Mon, 24 Mar 1997 08:38:31 -0700
To: "Karen R. Sollins" <[email-masked]>, [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] question #4 - benefits to provider as criterion
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 05:52 PM 3/23/97 -0500, Karen R. Sollins wrote:

>Should it be a requirement (or suggestion) that there be some benefit
>accruing to a provider who supports a server providing some part of an
>RDS system?

Once again, I think this is outside the scope of a RDS requirements document.

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  

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-04.txt
Date: Mon, 24 Mar 1997 09:58:51 -0500
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     : Resolution of Uniform Resource Identifiers using the 
                   Domain Name System                                      
       Author(s) : R. Daniel, M. Mealling
       Filename  : draft-ietf-urn-naptr-04.txt
       Pages     : 14
       Date      : 03/21/1997

Uniform Resource Locators (URLs) are the foundation of the World Wide Web, 
and are a vital Internet technology. However, they have proven to be 
brittle in practice. The basic problem is that URLs typically identify a 
particular path to a file on a particular host. There is no graceful way of
changing the path or host once the URL has been assigned. Neither is there 
a graceful way of replicating the resource located by the URL to achieve 
better network utilization and/or fault tolerance. Uniform Resource Names 
(URNs) have been hypothesized as a adjunct to URLs that would overcome such
problems. URNs and URLs are both instances of a broader class of 
identifiers known as Uniform Resource Identifiers (URIs). 

The requirements document for URN resolution systems[15] defines 
the concept of a "resolver discovery service". This document describes 
the first, experimental, RDS.  It is implemented by a new DNS Resource 
Record, NAPTR (Naming Authority PoinTeR), that provides rules for 
mapping parts of URIs to domain names.  By changing the mapping 
rules, we can change the host that is contacted to resolve a URI. 
This will allow a more graceful handling of URLs over long 
time periods, and forms the foundation for a new proposal for 
Uniform Resource Names.

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-naptr-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-04.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-naptr-04.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-naptr-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 24 Mar 1997 09:35:09 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: "Jul,Erik" <[email-masked]>
Cc: "Karen R. Sollins" <[email-masked]>, "','" <[email-masked]>
Subject: RE: [URN] question #4 - benefits to prov
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Mon, 24 Mar 1997, Jul,Erik wrote:
> I would suggest that you not get into the marketing of URN resolvers.  It 
> seems completely inappropriate for an engineering document.  If the system 

I agree quite strongly that the engineering document should not attempt
to be a marketing effort.

		AND

I think it is important to be sure we have some sense of possible ways
in which the engineered system will be attractive to all levels of users,
so that we don't create a beautifully crafted, unusable system.

Leslie.

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

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

From: [email-masked] (Jul,Erik)
To: [email-masked] (Karen R. Sollins), [email-masked] (',')
Organization: OCLC Inc, Dublin, Ohio USA (614)764-6000
Date: Mon, 24 Mar 1997 08:19:47 -0500
Subject: RE: [URN] question #4 - benefits to prov
Sender: [email-masked]
Reply-To: [email-masked] (Jul,Erik)

Karen:

>My intuition is that it would be good to say something suggestive
>rather than hard and fast.

I would suggest that you not get into the marketing of URN resolvers.  It 
seems completely inappropriate for an engineering document.  If the system 
works, the marketplace will find room for it (and by "marketplace" I don't 
necessarily mean "for profit," but rather the marketplace of willing users 
and willing providers).

 --Erik

Erik Jul
[email-masked]

Date: Sun, 23 Mar 1997 17:52:10 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] question #4 - benefits to provider as criterion
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>
Question:

Should it be a requirement (or suggestion) that there be some benefit
accruing to a provider who supports a server providing some part of an
RDS system?

Background:

The problem is the following.  It costs any provider something to put
up a server providing some of the RDS service.  So the question arises
whether or not it would be a good idea to encourage the designers of
a specific RDS system to design it in such a way that the provider who
puts up a server that will benefit the community as a whole, also gets
some more specific benefits for his/her own community.  For example,
it might be the case that any particular server could caching for
specific sets of clients, thus giving them better service.  It might
also be that a particular server, in addition to serving part of the
global namespace might have a certain number of resources set aside to
mirror information for its local community.  The point is that if we
encourage, or at least make positive noises about enabling such
capabilities, communities might be more likely to participate because
they get some direct benefit as well as the ability to help support
and enhance the community at large.

Comment:

My intuition is that it would be good to say something suggestive
rather than hard and fast.  I would make it vague because we can't
know what benefits might accrue for any particular engineering design,
and don't want to restrict that in any way.  So, this would be more in
the way of a recommendation than a requirement.  And I don't feel at
all strongly about this.  It is more a matter of getting designers to
think about what it will take to coax people to put up the servers
that will be needed to make the infrastructure viable.

			Karen

Date: Thu, 20 Mar 1997 14:05:08 -0700
To: "Karen R. Sollins" <[email-masked]>, [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] question #3 - management of usage
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 06:49 PM 3/18/97 -0500, Karen R. Sollins wrote:
>Question: 
>The question really is two part: are controls needed on the behavior
>of customers of the RDS and if so, what sorts of mechanisms should be
>mentioned, given that any such mechanism will need to be incorporated
>into the protocols?
[...]
>Comment:
>I have no strong opinions about this subject other than to believe in
>the tragedy of the commons, given no pressure on individuals to behave
>otherwise.

I agree with your comment about the first part of the question. If there
are no bounds whatsoever on user behavior then we are going to see
lots of uses we would consider inappropriate and detrimental to the
orderly operation of the system.

I don't agree with the assumption in the second part of the question that
"any such mechanism will need to be incorporated into the protocols".
Registering a domain name in .com does not happen for free. But that
is not wired into the DNS protocol specification, it is handled by
separate administrative functions. (Those functions were set up
in other documents, but not in any requirements DNS needed to meet).

I certainly think that the RDS requirements document should state that
any proposed RDS MUST NOT preclude the establishment of a control
mechanism. I'm considerably less certain about it even saying that
mechanisms proposed for consideration as an Internet standard MAY
include such mechanisms.

To indulge in an example, the problem is one of policy boundaries.
Just as I adamantly believe that this group cannot specify a security
policy for all URN resolvers, we cannot specify a "control" policy.
You mention pricing as one way of limiting behavior. If the DOE labs
set up a system for the resolution of classified URNs, we are not going
to rely on setting prices on classified documents to prevent "need-to-know"
violations. Usage will limited and monitored in other ways, and
inappropriate use may result in involuntary relocation to Levenworth KS.
The precise methods for limiting and monitoring behavior are not
the sort of thing that can or should appear in an Internet standard.

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: Wed, 19 Mar 1997 23:14:44 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] DRAFT agenda for URN meeting in Memphis
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Here's a tentative draft of the agenda for the Memphis meeting.  As
it happens, we will have shipped off a number of documents to 
take a step along the way to becoming RFCs, and have a small crop of new
documents to offer for review at the meeting  -- the agenda is based
on the expectation that editors will be able to submit drafts by the
cutoff time next week.

We have specific holes in the area of _namespaces_ -- I keep hearing 
rumours that various people are working on various possibilities.  I'd
like to hear from anyone who _is_ working on such, particularly if you
would like some airtime at the Memphis meeting!

Also, if anyone has something they would like to put on the agenda, please
let me know now.

Cheers!
Leslie.

----------------------------------------
IETF URN Working Group
----------------------------------------

Agenda for Thursday, April 10, 1997 (0900-1130), Memphis, Tennessee.

Status review:  
        . Status of documents
        . Progress on WG milestones

Discussion of document-specific issues: 
        . Requirements & Framework for URN Resolution [Karen]
	. Namespace Requirements [Patrik]
	. URN Resolution Services [Michael]
	. Any feedback on the IETF last call for Syntax...

Other issues: 
        . Namespaces...

Closing:
	. Revise WG milestones

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

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

Date: Tue, 18 Mar 1997 18:49:45 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] question #3 - management of usage
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>
Aside:

This question brings up a point that Ron Daniel made to me recently.
He suggested that we use abbreviation RDS for Resolution Discovery
Service, rather than UDS.  I am completely comfortable with that.  It
means that the abbreviation doesn't have "U" in it, which is probably
a GOOD thing.  Also, the full name is shorter.  So, I will use that in
this message and await comments, if any.  If there are none, the
change will

Question: 
The question really is two part: are controls needed on the behavior
of customers of the RDS and if so, what sorts of mechanisms should be
mentioned, given that any such mechanism will need to be incorporated
into the protocols?

Background:
In architecting a component of the infrastructure, we generally design
for scalability, but there are always some constraints.  For example,
a RDS may be intended to provide mappings from sets of URNs to
resolution servers.  It may not be intended to map every URN
individually into an RDS.  To engineer a global service that would map
every URN separately and could provide any kind of tracking of changes
seems unnecessarily difficult.  In addition, one might want to
engineer for a certain level of update traffic.  Then the question
that arises is how to cause users to behave approximately as expected.
In the document I suggested a payment scheme of some sort.  Ron
suggested that there were other alternatives, such as administrative
control, although I don't quite understand how that would scale and
distribute.  Hence the question to be addressed here.

Comment:
I have no strong opinions about this subject other than to believe in
the tragedy of the commons, given no pressure on individuals to behave
otherwise.

			Karen

Date: Tue, 18 Mar 1997 16:22:33 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] re URN hints
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Terry,

What I am learning from your comments is that I have a bit of
rewriting on this topic.  Your point is well-taken and heard.

			Thanks,
			Karen

From: [email-masked] (Leslie Daigle)
Date: Mon, 17 Mar 1997 19:35:18 -0500
To: [email-masked]
Subject: [URN] Updated Last Call on NAPTR
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Ron sent around a note last week with the revised version of the NAPTR
document (http://www.acl.lanl.gov/URN/naptr.txt).

In the interest of being able to send this off to the A-D to be moved
forward as Experimental, I'd like to ask this group for final comments,
if any.

As I think Ron did address most issues, and this document has been 
circulating for a few days already (and, as I am travelling towards the
end of the week :-)    I'd like to say that, if there are no further comments
of major import by the end of Wednesday, we'll send this off to the
A-D.

By the way, on the subject of Trivial HTTP  which should also be moved,
it is my understanding that Ron has no further edits to make and it will
go at the same time, unless I hear that people think otherwise...

Cheers!
Leslie. 

-- 

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

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

Date: Mon, 17 Mar 1997 14:31:28 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] re URN hints
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Karen writes:
>Hints, as I defined them in the document, are the things that URNs are
mapped into.  Without them we don't have much of a resolution
service.  So, I'm a little puzzled here.
    
If we're talking about draft-ietf-urn-req-frame-00.txt, I don't see
"the things that URNs are mapped into."  On page 1 I see a description
of hints as "something that helps in the resolution of a URN," to wit,
metadata about the URN.  I repeat, I do not see that we need to say
anything at all about this metadata at this point.

Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
       specializing in Web publishing, SGML, and the DocBook DTD 
                   http://www.sonic.net/~tallen/
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Mon, 17 Mar 1997 14:23:14 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Re URN question #2
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   My preference would be to omit all discussion of hints.  We will
   find a place for them when we get to URCs; we might do well not to
   complicate the URN documents with them now.

   I am not opposed to hinting systems, but as we don't have them
   deployed yet we can afford to leave this issue to the future.

   Regards,
     Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
	  specializing in Web publishing, SGML, and the DocBook DTD 
		      http://www.sonic.net/~tallen/
     A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Terry,

Hints, as I defined them in the document, are the things that URNs are
mapped into.  Without them we don't have much of a resolution
service.  So, I'm a little puzzled here.

			Karen

Date: Mon, 17 Mar 1997 14:23:14 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Re URN question #2
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>
Status: R

   My preference would be to omit all discussion of hints.  We will
   find a place for them when we get to URCs; we might do well not to
   complicate the URN documents with them now.

   I am not opposed to hinting systems, but as we don't have them
   deployed yet we can afford to leave this issue to the future.

   Regards,
     Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
	  specializing in Web publishing, SGML, and the DocBook DTD 
		      http://www.sonic.net/~tallen/
     A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Terry,

Hints, as I defined them in the document, are the things that URNs are
mapped into.  Without them we don't have much of a resolution
service.  So, I'm a little puzzled here.

			Karen

Date: Fri, 14 Mar 1997 14:57:50 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] Re URN question #2
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

My preference would be to omit all discussion of hints.  We will
find a place for them when we get to URCs; we might do well not to
complicate the URN documents with them now.

I am not opposed to hinting systems, but as we don't have them
deployed yet we can afford to leave this issue to the future.

Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
       specializing in Web publishing, SGML, and the DocBook DTD 
                   http://www.sonic.net/~tallen/
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Fri, 14 Mar 1997 15:31:43 -0700
To: "Karen R. Sollins" <[email-masked]>, [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] question #2 - lifetime of hints
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

At 04:18 PM 3/14/97 -0500, Karen R. Sollins wrote:
>Question:
>=========
>Is there a need for a distinction between long-term (long lifetime)
>and short-term (short lifetime) hints and, if so, should that be
>expressed as a requirement in the resolution requirements doc?
[...]
>So, my
>reaction to this topic is that there are a couple of kinds of
>meta-information about hints that will be particularly useful,
>specifically lifetime or expiry time and certification, so they ought
>to be mentioned in the requirements doc, but that the architectural
>requirements for the discovery service should not be changed in any
>way by these other than to support their exchange.

It seems possible to construct a resolver discovery system that works
yet does not provide this information. However, it seems that the lack
of the ability to convey such auxillary information indicates a high
probability of the system being broken in some fundamental way.

So, my current opinion on this topic is that the requirements draft
needs to say that resolver discovery mechanisms SHOULD allow
metadata (such as expiry dates, formats, ...) on names, resolver
locations, resolution protocols, ... to be conveyed. Not MUST but
SHOULD.

You might also want to take a look in the archives for Bob Briscoe's
messages on the subject of resolution system lifetime information for
more ammo on this subject.

Regards,

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: Fri, 14 Mar 1997 16:18:54 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] question #2 - lifetime of hints
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Question:
=========
Is there a need for a distinction between long-term (long lifetime)
and short-term (short lifetime) hints and, if so, should that be
expressed as a requirement in the resolution requirements doc?

Background:
===========
To date, the only place that hints are discussed at any length is in
the requirements document.  I suspect that we all agree that different
hints will have different lifetimes, or perhaps probabilistic
lifetimes.  In fact, one way of expressing this might be half-life.
Certainly there will be some hints such as those that reflect a
temporary fix to a temporary problem ("our server is down, so use
server X for the next hour").  Others, such as the authoritative
resolution service for technical reports from MIT's Laboratory for
Computer Science is likely to last for some period of years.  The
question is whether it is important architecturally to distinguish
these and whether that should be done in this requirements document.

Soapbox:
========
Rather than pros and cons, I'll just give you my opinion and wait for
others.  This question is phrased this way because someone brought it
up this way in a previous discussion.  There is some benefit to being
able to express something about expiry date, but I wouldn't let it
complicate the architecture of the whole discovery service.  We need
that to be as simple and efficient as possible.  There is a related
piece of information that may be at least as useful, certification.
This is a certificate identifying the source of the hint.  Hints may
be certified by the resource itself (or it's owner/manager), by an
alternative authority (for example, the storage service that is
maintaining a mirrored copy of the resource), or may not certified.
Even anonymous hints may be useful, but in many cases it is important
and/or useful to know whether and by whom a hint is certified.  So, my
reaction to this topic is that there are a couple of kinds of
meta-information about hints that will be particularly useful,
specifically lifetime or expiry time and certification, so they ought
to be mentioned in the requirements doc, but that the architectural
requirements for the discovery service should not be changed in any
way by these other than to support their exchange.

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: [URN] Last Call: URN Syntax to Proposed Standard
Date: Fri, 14 Mar 1997 09:59:09 -0500
Sender: [email-masked]
Reply-To: The IESG <[email-masked]>

 The IESG has received a request from the Uniform Resource Names Working
 Group to consider "URN Syntax" <draft-ietf-urn-syntax-04.txt> for the
 status of Proposed Standard.

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action.  Please send any comments to the
 [email-masked] or [email-masked] mailing lists by March 28, 1997

Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-04.txt
Date: Fri, 14 Mar 1997 09:22:12 -0500
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     : URN Syntax                                              
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-syntax-04.txt
       Pages     : 7
       Date      : 03/12/1997

Uniform Resource Names (URNs) are intended to serve as persistent, 
location-independent, resource identifiers. This document sets forward the 
canonical syntax for URNs.  A discussion of both existing legacy and new 
namespaces and requirements for URN presentation and transmission are 
presented.  Finally, there is a discussion of URN equivalence and how to 
determine it.                                                              

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-syntax-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-04.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-syntax-04.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-syntax-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 13 Mar 1997 00:08:02 -0500
To: Bob Briscoe <[email-masked]>
From: Andrew Watson <[email-masked]>
Subject: [URN] Re: The IETF Uniform Resource Names Working Group invites your comments
Cc: "Kindel, Charlie" <[email-masked]>, [email-masked], [email-masked] (Leslie Daigle)
Sender: [email-masked]
Reply-To: Andrew Watson <[email-masked]>

Bob,

You wrote:

> Leslie Daigle, the co-chair of the IETF URN working group has asked me to
> invite you two to comment on a problem I have just thrown into the IETF
> URN working group. Alternatively can you forward this to someone with the
> time and equivalent expertise to look into this?

Thanks for forwarding this. I'm tied up at an OMG technical gathering all
this week, but I'll take a look and get back to you with a response early
next week.

                            Regards,

                                 Andrew
 Andrew Watson                               Tel:    +1 508 820 4300
 Object Management Group,                    Fax:    +1 508 820 4303
 492 Old Connecticut Path                    Email:  [email-masked]
 Framingham, MA 01701, USA                   http://www.omg.org/~andrew

From: "Ronald E. Daniel" <[email-masked]>
Date: Wed, 12 Mar 1997 14:52:09 -0700 (MST)
To: [email-masked]
Subject: [URN] NAPTR -04
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Here is the latest version of the NAPTR draft, revised to accomodate
comments recieved during the working group's internal last call period.

=====

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-naptr-04.txt                 Los Alamos National Laboratory
                                                          Michael Mealling
                                                   Network Solutions, Inc.
                                                            13 March, 1997

                Resolution of Uniform Resource Identifiers
                       using the Domain Name System

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).

    This draft expires 26 Sept., 1997.

Abstract:
=========

Uniform Resource Locators (URLs) are the foundation of the World Wide
Web, and are a vital Internet technology. However, they have proven to
be brittle in practice. The basic problem is that URLs typically
identify a particular path to a file on a particular host. There is no
graceful way of changing the path or host once the URL has been
assigned. Neither is there a graceful way of replicating the resource
located by the URL to achieve better network utilization and/or fault
tolerance. Uniform Resource Names (URNs) have been hypothesized as a
adjunct to URLs that would overcome such problems. URNs and URLs are
both instances of a broader class of identifiers known as Uniform
Resource Identifiers (URIs).

The requirements document for URN resolution systems[15] defines the concept
of a "resolver discovery service". This document describes the first,
experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR
(Naming Authority PoinTeR), that provides rules for mapping parts of URIs
to domain names.  By changing the mapping rules, we can change the host
that is contacted to resolve a URI. This will allow a more graceful
handling of URLs over long time periods, and forms the foundation for a
new proposal for Uniform Resource Names.

In addition to locating resolvers, the NAPTR provides for other naming
systems to be grandfathered into the URN world, provides independence
between the name assignment system and the resolution protocol system,
and allows multiple services (Name to Location, Name to Description,
Name to Resource, ...) to be offered.  In conjunction with the SRV RR,
the NAPTR record allows those services to be replicated for the purposes
of fault tolerance and load balancing.

Introduction:
=============

Uniform Resource Locators have been a significant advance in retrieving
Internet-accessible resources. However, their  brittle nature over time
has been recognized for several years. The Uniform Resource Identifier
working group proposed the development of Uniform Resource Names to serve
as persistent, location-independent identifiers for Internet resources
in order to overcome most of the problems with URLs. RFC-1737 [1] sets
forth requirements on URNs.

During the lifetime of the URI-WG, a number of URN proposals were
generated. The developers of several of those proposals met in a series
of meetings, resulting in a compromise known as the Knoxville framework.
The major principle behind the Knoxville framework is that the resolution
system must be separate from the way names are assigned. This is in
marked contrast to most URLs, which identify the host to contact and
the protocol to use. Readers are referred to [2] for background on the
Knoxville framework and for additional information on the context and
purpose of this proposal.

Separating the way names are resolved from the way they are constructed
provides several benefits. It allows multiple naming approaches and
resolution approaches to compete, as it allows different protocols and
resolvers to be used. There is just one problem with such a separation -
how do we resolve a name when it can't give us directions to its
resolver?

For the short term, DNS is the obvious candidate for the resolution
framework, since it is widely deployed and understood. However, it is
not appropriate to use DNS to maintain information on a per-resource
basis. First of all, DNS was never intended to handle that many
records. Second, the limited record size is inappropriate for catalog
information. Third, domain names are not appropriate as URNs.

Therefore our approach is to use DNS to locate "resolvers" that can
provide information on individual resources, potentially including the
resource itself. To accomplish this, we "rewrite" the URI into a domain
name following the rules provided in NAPTR records. Rewrite rules
provide considerable power, which is important when trying to meet the
goals listed above. However, collections of rules can become difficult
to understand. To lessen this problem, the NAPTR rules are *always*
applied to the original URI, *never* to the output of previous rules.

Locating a resolver through the rewrite procedure may take multiple
steps, but the beginning is always the same. The start of the URI
is scanned to extract its colon-delimited prefix. (For URNs, the
prefix is always "urn:" and we extract the following colon-delimited
namespace identifier. [3]). NAPTR resolution begins by taking the
extracted string, appending the well-known suffix ".urn.net", and
querying the DNS for NAPTR records at that domain name.  Based on the
results of this query, zero or more additional DNS queries may be
needed to locate resolvers for the URI. The details of the conversation
between the client and the resolver thus located are outside the bounds
of this draft. Three brief examples of this procedure are given in the
next section.

The NAPTR RR provides the level of indirection needed to keep the
naming system independent of the resolution system, its protocols, and
services.  Coupled with the new SRV resource record proposal[4] there
is also the potential for replicating the resolver on multiple hosts,
overcoming some of the most significant problems of URLs. This is an
important and subtle point. Not only do the NAPTR and SRV records allow
us to replicate the resource, we can replicate the resolvers that know
about the replicated resource. Preventing a single point of failure at
the resolver level is a significant benefit. Separating the resolution
procedure from the way names are constructed has additional benefits.
Different resolution procedures can be used over time, and resolution
procedures that are determined to be useful can be extended to deal
with additional namespaces.

Caveats
=======

The NAPTR proposal is the first resolution procedure to be considered
by the URN-WG. There are several concerns about the proposal which have
motivated the group to recommend it for publication as an Experimental
rather than a standards-track RFC.

First, URN resolution is new to the IETF and we wish to gain
operational experience before recommending any procedure for the
standards track. Second, the NAPTR proposal is based on DNS and
consequently inherits concerns about security and administration. The
recent advancement of the DNSSEC and secure update drafts to Proposed
Standard reduce these concerns, but we wish to experiment with those
new capabilities in the context of URN administration.  A third area of
concern is the potential for a noticeable impact on the DNS.  We
believe that the proposal makes appropriate use of caching and
additional information, but it is best to go slow where the potential
for impact on a core system like the DNS is concerned. Fourth, the
rewrite rules in the NAPTR proposal are based on regular expressions.
Since regular expressions are difficult for humans to construct
correctly, concerns exist about the usability and maintainability of
the rules. This is especially true where international character sets
are concerned. Finally, the URN-WG is developing a requirements document
for URN Resolution Services[15], but that document is not complete. That
document needs to precede any resolution service proposals on the standards
track.

Terminology
===========

"Must" or "Shall" - Software that does not behave in the manner that this
           document says it must is not conformant to this document.
"Should" - Software that does not follow the behavior that this document
           says it should may still be conformant, but is probably broken
           in some fundamental way.
"May" -    Implementations may or may not provide the described behavior,
           while still remaining conformant to this document.

Brief overview and examples of the NAPTR RR:
============================================

A detailed description of the NAPTR RR will be given later, but to give
a flavor for the proposal we first give a simple description of the
record and three examples of its use.

The key fields in the NAPTR RR are order, preference, service, flags,
regexp, and replacement:

* The order field specifies the order in which records MUST be processed
  when multiple NAPTR records are returned in response to a single query.
  A naming authority may have delegated a portion of its namespace to
  another agency. Evaluating the NAPTR records in the correct order is
  necessary for delegation to work properly.

* The preference field specifies the order in which records SHOULD be
  processed when multiple NAPTR records have the same value of "order".
  This field lets a service provider specify the order in which resolvers
  are contacted, so that more capable machines are contacted in preference
  to less capable ones.

* The service field specifies the resolution protocol and resolution
  service(s) that will be available if the rewrite specified by the
  regexp or replacement fields is applied. Resolution protocols are
  the protocols used to talk with a resolver. They will be specified in
  other documents, such as [5]. Resolution services are operations such
  as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc.
  These will be discussed in the URN Resolution Services document[6], and
  their behavior in a particular resolution protocol will be given in
  the specification for that protocol (see [5] for a concrete example).

* The flags field contains modifiers that affect what happens in the
  next DNS lookup, typically for optimizing the process. Flags may also
  affect the interpretation of the other fields in the record, therefore,
  clients MUST skip NAPTR records which contain an unknown flag value.

* The regexp field is one of two fields used for the rewrite rules, and
  is the core concept of the NAPTR record. The regexp field is a String
  containing a sed-like substitution expression. (The actual grammar
  for the substitution expressions is given later in this draft). The
  substitution expression is applied to the original URN to determine
  the next domain name to be queried. The regexp field should be used
  when the domain name to be generated is conditional on information in
  the URI. If the next domain name is always known, which is
  anticipated to be a common occurrence, the replacement field should
  be used instead.

* The replacement field is the other field that may be used for the
  rewrite rule. It is an optimization of the rewrite process for the
  case where the next domain name is fixed instead of being conditional
  on the content of the URI. The replacement field is a domain name
  (subject to compression if a DNS sender knows that a given recipient
  is able to decompress names in this RR type's RDATA field). If the
  rewrite is more complex than a simple substitution of a domain name,
  the replacement field should be set to . and the regexp field used.

Note that the client applies all the substitutions and performs all
lookups, they are not performed in the DNS servers. Note also that it
is the belief of the developers of this document that regexps should
rarely be used. The replacement field seems adequate for the vast
majority of situations. Regexps are only necessary when portions of a
namespace are to be delegated to different resolvers. Finally, note
that the regexp and replacement fields are, at present, mutually
exclusive. However, developers of client software should be aware that
a new flag might be defined which requires values in both fields.

Example 1
---------

Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers
are identifiers for approximately 30 million registered businesses
around the world, assigned and maintained by Dunn and Bradstreet. The
URN might look like:

                 urn:duns:002372413:annual-report-1997

The first step in the resolution process is to find out about the DUNS
namespace. The namespace identifier, "duns", is extracted from the URN,
prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It
might return records of the form:

duns.urn.net
;;      order pref flags service          regexp        replacement
 IN NAPTR 100  10  "s"  "dunslink+N2L+N2C"  ""   dunslink.udp.isi.dandb.com
 IN NAPTR 100  20  "s"  "rcds+N2C"          ""   rcds.udp.isi.dandb.com
 IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R"  ""   http.tcp.isi.dandb.com

The order field contains equal values, indicating that no name
delegation order has to be followed. The preference field indicates
that the provider would like clients to use the special dunslink
protocol, followed by the RCDS protocol, and that HTTP is offered as a
last resort. All the records specify the "s" flag, which will be
explained momentarily.  The service fields say that if we speak
dunslink, we will be able to issue either the N2L or N2C requests to
obtain a URL or a URC (description) of the resource. The Resource
Cataloging and Distribution Service (RCDS)[7] could be used to get a
URC for the resource, while HTTP could be used to get a URL, URC, or
the resource itself.  All the records supply the next domain name to
query, none of them need to be rewritten with the aid of regular
expressions.

The general case might require multiple NAPTR rewrites to locate a
resolver, but eventually we will come to the "terminal NAPTR". Once we
have the terminal NAPTR, our next probe into the DNS will be for a SRV
or A record instead of another NAPTR. Rather than probing for a
non-existent NAPTR record to terminate the loop, the flags field is
used to indicate a terminal lookup. If it has a value of "s", the next
lookup should be for SRV RRs, "a" denotes that A records should sought.
A "p" flag is also provided to indicate that the next action is
Protocol-specific, but that looking up another NAPTR will not be part
of it.

Since our example RR specified the "s" flag, it was terminal. Assuming
our client does not know the dunslink protocol, our next action is to
lookup SRV RRs for rcds.udp.isi.dandb.com, which will tell us hosts that
can provide the necessary resolution service. That lookup might return:

 ;;                          Pref Weight Port Target
 rcds.udp.isi.dandb.com IN SRV 0    0    1000 defduns.isi.dandb.com
                        IN SRV 0    0    1000 dbmirror.com.au
                        IN SRV 0    0    1000 ukmirror.com.uk

telling us three hosts that could actually do the resolution, and
giving us the port we should use to talk to their RCDS server.
(The reader is referred to the SRV proposal [4] for the interpretation
of the fields above).

There is opportunity for significant optimization here. We can return
the SRV records as additional information for terminal NAPTRs (and the
A records as additional information for those SRVs). While this
recursive provision of additional information is not explicitly blessed
in the DNS specifications, it is not forbidden, and BIND does take
advantage of it [8]. This is a significant optimization. In conjunction
with a long TTL for *.urn.net records, the average number of probes to
DNS for resolving DUNS URNs would approach one. Therefore, DNS server
implementors SHOULD provide additional information with NAPTR
responses. The additional information will be either SRV or A records.
If SRV records are available, their A records should be provided as
recursive additional information.

Note that the example NAPTR records above are intended to represent the
reply the client will see. They are not quite identical to what the
domain administrator would put into the zone files. For one thing, the
administrator should supply the trailing '.' character on any FQDNs.

Example 2 
---------

Consider a URN namespace based on MIME Content-Ids. The URN might look
like this:
  
        urn:cid:[email-masked]

(Note that this example is chosen for pedagogical purposes, and does
not conform to the recently-approved CID URL scheme.)

The first step in the resolution process is to find out about the CID
namespace. The namespace identifier, cid, is extracted from the URN,
prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might
return records of the form:
 
 cid.urn.net
  ;;       order pref flags service        regexp           replacement
   IN NAPTR 100   10   ""     ""  "/urn:cid:.+@([^\.]+\.)(*)$/\2/i"    .
 
We have only one NAPTR response, so ordering the responses is not
a problem.  The replacement field is empty, so we check the regexp
field and use the pattern provided there. We apply that regexp to the
entire URN to see if it matches, which it does.  The \2 part of the
substitution expression returns the string "gatech.edu". Since
the flags field does not contain "s" or "a", the lookup is not terminal
and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR,
"gatech.edu").

Note that the rule does not extract the full domain name from the CID,
instead it assumes the CID comes from a host and extracts its domain.
While all hosts, such as mordred, could have their very own NAPTR,
maintaining those records for all the machines at a site as large as
Georgia Tech would be an intolerable burden. Wildcards are not appropriate
here since they only return results when there is no exactly matching
names already in the system. 

The record returned from the query on "gatech.edu" might look like:

gatech.edu IN NAPTR
;;       order pref flags service           regexp  replacement
  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu
  IN NAPTR 100  50  "s"  "rcds+N2C"          ""    rcds.udp.gatech.edu
  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""    http.tcp.gatech.edu

Continuing with our example, we note that the values of the order and
preference fields are equal in all records, so the client is free to
pick any record. The flags field tells us that these are the last NAPTR
patterns we should see, and after the rewrite (a simple replacement in
this case) we should look up SRV records to get information on the
hosts that can provide the necessary service.

Assuming we prefer the Z39.50 protocol, our lookup might return:
 
;;                        Pref Weight   Port Target
z3950.tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu
                     IN SRV 0    0      1000 z3950.cc.gatech.edu
                     IN SRV 0    0      1000 z3950.uga.edu

telling us three hosts that could actually do the resolution, and
giving us the port we should use to talk to their Z39.50 server.

Recall that the regular expression used \2 to extract a domain name
from the CID, and \. for matching the literal '.' characters seperating
the domain name components. Since '\' is the escape character, literal
occurances of a backslash must be escaped by another backslash. For the
case of the cid.urn.net record above, the regular expression entered
into the zone file should be "/urn:cid:.+@([^\\.]+\\.)(*)$/\\2/i".
When the client code actually receives the record, the pattern will
have been converted to "/urn:cid:.+@([^\.]+\.)(*)$/\2/i".

Example 3
---------

Even if URN systems were in place now, there would still be a
tremendous number of URLs.  It should be possible to develop a URN
resolution system that can also provide location independence for those
URLs.  This is related to the requirement in [1] to be able to
grandfather in names from other naming systems, such as ISO Formal
Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
etc.

The NAPTR RR could also be used for URLs that have already been assigned.
Assume we have the URL for a very popular piece of software that the
publisher wishes to mirror at multiple sites around the world:

     http://www.foo.com/software/latest-beta.exe

We extract the prefix, "http", and lookup NAPTR records for
http.urn.net. This might return a record of the form

http.urn.net IN NAPTR
;;  order   pref flags service      regexp             replacement
     100     90   ""      ""   "!http://([^/:]+)!\1!i"       .

This expression returns everything after the first double slash and
before the next slash or colon. (We use the '!' character to delimit the
parts of the substitution expression. Otherwise we would have to use
backslashes to escape the forward slashes, and would have a regexp in
the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).

Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR
records for that might return:

www.foo.com
;;       order pref flags   service  regexp     replacement
 IN NAPTR 100  100  "s"   "http+L2R"   ""    http.tcp.foo.com
 IN NAPTR 100  100  "s"   "ftp+L2R"    ""    ftp.tcp.foo.com

Looking up SRV records for http.tcp.foo.com would return information
on the hosts that foo.com has designated to be its mirror sites. The
client can then pick one for the user. 

NAPTR RR Format
===============

The format of the NAPTR RR is given below. The DNS type code for
NAPTR is 35.

    Domain TTL Class Order Preference Flags Service Regexp Replacement 

where:

Domain
       The domain name this resource record refers to.
TTL
       Standard DNS Time To Live field
Class
       Standard DNS meaning
Order
       A 16-bit integer specifying the order in which the NAPTR records
       MUST be processed to ensure correct delegation of portions
       of the namespace over time. Low numbers are processed before
       high numbers, and once a NAPTR is found that "matches" a URN,
       the client MUST NOT consider any NAPTRs with a higher value
       for order.

Preference
       A 16-bit integer which specifies the order in which NAPTR records
       with equal "order" values SHOULD be processed, low numbers
       being processed before high numbers.  This is similar to the
       preference field in an MX record, and is used so domain
       administrators can direct clients towards more capable hosts
       or lighter weight protocols. 

Flags
       A String giving flags to control aspects of the rewriting and
       interpretation of the fields in the record. Flags are single
       characters from the set [A-Z0-9]. The case of the alphabetic
       characters is not significant.

       At this time only three flags, "S", "A", and "P", are defined.
       "S" means that the next lookup should be for SRV records instead
       of NAPTR records. "A" means that the next lookup should be for A
       records. The "P" flag says that the remainder of the resolution
       shall be carried out in a Protocol-specific fashion, and we
       should not do any more DNS queries.

       The remaining alphabetic flags are reserved. The numeric flags
       may be used for local experimentation. The S, A, and P flags are
       all mutually exclusive, and resolution libraries MAY signal an
       error if more than one is given. (Experimental code and code for
       assisting in the creation of NAPTRs would be more likely to
       signal such an error than a client such as a browser). We
       anticipate that multiple flags will be allowed in the future, so
       implementers MUST NOT assume that the flags field can only
       contain 0 or 1 characters. Finally, if a client encounters a
       record with an unknown flag, it MUST ignore it and move to the
       next record. This test takes precedence even over the "order"
       field. Since flags can control the interpretation placed on
       fields, a novel flag might change the interpretation of the
       regexp and/or replacement fields such that it is impossible to
       determine if a record matched a URN.

Service 
       Specifies the resolution service(s) available down this rewrite
       path. It may also specify the particular protocol that is used
       to talk with a resolver. A protocol MUST be specified if the
       flags field states that the NAPTR is terminal. If a protocol is
       specified, but the flags field does not state that the NAPTR is
       terminal, the next lookup MUST be for a NAPTR. The client MAY
       choose not to perform the next lookup if the protocol is
       unknown, but that behavior MUST NOT be relied upon.

       The service field may take any of the values below (using the
       Augmented BNF of RFC 822[9]):

           service_field = [ [protocol] *("+" rs)]
           protocol      = ALPHA *31ALPHANUM
           rs            = ALPHA *31ALPHANUM
        // The protocol and rs fields are limited to 32
        // characters and must start with an alphabetic.
        // The current set of "known" strings are:
        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"

       i.e. an optional protocol specification followed by 0 or more
       resolution services. Each resolution service is indicated by
       an initial '+' character.

       Note that the empty string is also a valid service field. This
       will typically be seen at the top levels of a namespace, when it
       is impossible to know what services and protocols will be offered
       by a particular publisher within that name space.

       At this time the known protocols are rcds[7], hdl[10] (binary,
       UDP-based protocols),  thttp[5] (a textual, TCP-based protocol),
       rwhois[11] (textual, UDP or TCP based), and Z39.50[12] (binary,
       TCP-based). More will be allowed later.  The names of the
       protocols must be formed from the characters [a-Z0-9]. Case of
       the characters is not significant.

       The service requests currently allowed will be described in more
       detail in [6], but in brief they are:
             N2L  - Given a URN, return a URL
             N2Ls - Given a URN, return a set of URLs
             N2R  - Given a URN, return an instance of the resource.
             N2Rs - Given a URN, return multiple instances of the resouce,
                    typically encoded using multipart/alternative.
             N2C  - Given a URN, return a collection of meta-information
                    on the named resource. The format of this response is
                    the subject of another document.
             N2Ns - Given a URN, return all URNs that are also identifers
                    for the resource.
             L2R  - Given a URL, return the resource.
             L2Ns - Given a URL, return all the URNs that are identifiers
                    for the resource.
             L2Ls - Given a URL, return all the URLs for instances of
                    of the same resource.
             L2C  - Given a URL, return a description of the resource.

       The actual format of the service request and response will be
       determined by the resolution protocol, and is the subject for
       other documents (e.g. [5]). Protocols need not offer all
       services. The labels for service requests shall be formed from
       the set of characters [A-Z0-9]. The case of the alphabetic
       characters is not significant.

Regexp
       A STRING containing a substitution expression that is applied to
       the original URI in order to construct the next domain name to
       lookup. The grammar of the substitution expression is given in
       the next section.

Replacement
       The next NAME to query for NAPTR, SRV, or A records depending on
       the value of the flags field. As mentioned above, this may be
       compressed.

Substitution Expression Grammar:
================================

The content of the regexp field is a substitution expression. True sed(1)
substitution expressions are not appropriate for use in this application for a
variety of reasons, therefore the contents of the regexp field MUST follow the
grammar below:

  subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
  delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
                 than backslash '\'. All occurances of a delim_char in a
                 subst_expr must be the same character.)
  ere          = POSIX Extended Regular Expression (see [13], section 2.8.4)
  repl         = dns_str /  backref / repl dns_str  / repl backref
  dns_str      = 1*DNS_CHAR 
  backref      = "\" 1POS_DIGIT
  flags        = "i" 
  DNS_CHAR     = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z"
  POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref value
domain name (see RFC-1123 [14]).

The result of applying the substitution expression to the original URI MUST
result in a string that obeys the syntax for DNS host names [14]. Since it
is possible for the regexp field to be improperly specified, such that a
non-conforming host name can be constructed, client software SHOULD verify
that the result is a legal host name before making queries on it. 

Backref expressions in the repl portion of the substitution expression
are replaced by the (possibly empty) string of characters enclosed by '('
and ')' in the ERE portion of the substitution expression. N is a single
digit from 1 through 9, inclusive. It specifies the N'th backref expression,
the one that begins with the N'th '(' and continues to the matching ')'.
For example, the ERE
                   (A(B(C)DE)(F)G)
has backref expressions:
                    \1  = ABCDEFG
                    \2  = BCDE
                    \3  = C
                    \4  = F
                \5..\9  = error - no matching subexpression
                 
The "i" flag indicates that the ERE matching SHALL be performed in a
case-insensitive fashion. Furthermore, any backref replacements MAY be
normalized to lower case when the "i" flag is given.

The first character in the substitution expression shall be used as the
character that delimits the components of the substitution expression.
There must be exactly three non-escaped occurrences of the delimiter
character in a substitution expression. Since escaped occurrences of
the delimiter character will be interpreted as occurrences of that
character, digits MUST NOT be used as delimiters. Backrefs would be
confused with literal digits were this allowed. Similarly, if flags are
specified in the substitution expression, the delimiter character must not
also be a flag character. 

Advice to domain administrators:
================================

Beware of regular expressions. Not only are they a pain to get
correct on their own, but there is the previously mentioned interaction
with DNS. Any backslashes in a regexp must be entered twice in a zone
file in order to appear once in a query response. More seriously, the
need for double backslashes has probably not been tested by all
implementors of DNS servers. We anticipate that urn.net will be the
heaviest user of regexps. Only when delegating portions of namespaces
should the typical domain administrator need to use regexps.

On a related note, beware of interactions with the shell when manipulating
regexps from the command line. Since '\' is a common escape character in
shells, there is a good chance that when you think you are saying "\\" you
are actually saying "\".  Similar caveats apply to characters such as
'*', '(', etc.

The "a" flag allows the next lookup to be for A records rather than
SRV records. Since there is no place for a port specification in the
NAPTR record, when the "A" flag is used the specified protocol must
be running on its default port. 

The URN Sytnax draft defines a canonical form for each URN, which requires
%encoding characters outside a limited repertoire. The regular expressions
MUST be written to operate on that canonical form. Since international
character sets will end up with extensive use of %encoded characters,
regular expressions operating on them will be essentially impossible to
read or write by hand.

Usage
=====

For the edification of implementers, pseudocode for a client routine
using NAPTRs is given below. This code is provided merely as a
convience, it does not have any weight as a standard way to process
NAPTR records. Also, as is the case with pseudocode, it has never been
executed and may contain logical errors. You have been warned.

    //
    // findResolver(URN)
    // Given a URN, find a host that can resolve it.
    // 
    findResolver(string URN) {
      // prepend prefix to urn.net
      sprintf(key, "%s.urn.net", extractNS(URN));
      do {
        rewrite_flag = false;
        terminal = false;
	if (key has been seen) {
	  quit with a loop detected error
	}
	add key to list of "seens"
	records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'

        discard any records with an unknown value in the "flags" field.
        sort NAPTR records by "order" field and "preference" field
            (with "order" being more significant than "preference").
        n_naptrs = number of NAPTR records in response.
        curr_order = records[0].order;
        max_order = records[n_naptrs-1].order;
        
        // Process current batch of NAPTRs according to "order" field.
        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
          if (unknown_flag) // skip this record and go to next one
             continue; 
          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
          if (!newkey) // Skip to next record if the rewrite didn't match
             continue;  
          // We did do a rewrite, shrink max_order to current value
          // so that delegation works properly
          max_order = naptr[j].order;
          // Will we know what to do with the protocol and services
          // specified in the NAPTR? If not, try next record.
          if(!isKnownProto(naptr[j].services)) {
            continue;
          }
          if(!isKnownService(naptr[j].services)) {
            continue;
          }

          // At this point we have a successful rewrite and we will know
          // how to speak the protocol and request a known resolution
          // service. Before we do the next lookup, check some
          // optimization possibilities.
          
          if (strcasecmp(flags, "S")
           || strcasecmp(flags, "P"))
           || strcasecmp(flags, "A")) {
             terminal = true;
             services = naptr[j].services;
             addnl = any SRV and/or A records returned as additional info
                     for naptr[j].
          }
          key = newkey;
          rewriteflag = true;
          break;
        }
      } while (rewriteflag && !terminal);

      // Did we not find our way to a resolver?
      if (!rewrite_flag) {
         report an error
         return NULL;
      }

      // Leave rest to another protocol?
      if (strcasecmp(flags, "P")) {
         return key as host to talk to;
      }

      // If not, keep plugging
      if (!addnl) { // No SRVs came in as additional info, look them up
        srvs = lookup(type=SRV, key);
      }  

      sort SRV records by preference, weight, ...
      foreach (SRV record) { // in order of preference
        try contacting srv[j].target using the protocol and one of the
            resolution service requests from the "services" field of the
            last NAPTR record.
        if (successful)
          return (target, protocol, service);
          // Actually we would probably return a result, but this
          // code was supposed to just tell us a good host to talk to.
      }
      die with an "unable to find a host" error;
    }

Notes:
======
  -  A client MUST process multiple NAPTR records in the order specified by
     the "order" field, it MUST NOT simply use the first record that provides
     a known protocol and service combination.
  -  If a record at a particular order matches the URI, but the client
     doesn't know the specified protocol and service, the client SHOULD
     continue to examine records that have the same order. The client
     MUST NOT consider records with a higher value of order. This is
     necessary to make delegation of portions of the namespace work.
     The order field is what lets site administrators say "all requests for
     URIs matching pattern x go to server 1, all others go to server 2".
     (A match is defined as:
        1)  The NAPTR provides a replacement domain name
        or
        2) The regular expression matches the URN
     )
  -  When multiple RRs have the same "order", the client should use
     the value of the preference field to select the next NAPTR to
     consider. However, because of preferred protocols or services,
     estimates of network distance and bandwidth, etc. clients
     may use different criteria to sort the records.
  -  If the lookup after a rewrite fails, clients are strongly encouraged
     to report a failure, rather than backing up to pursue other rewrite
     paths.
  -  When a namespace is to be delegated among a set of resolvers, regexps
     must be used. Each regexp appears in a separate NAPTR RR. Administrators
     should do as little delegation as possible, because of limitations on
     the size of DNS responses.
  -  Note that SRV RRs impose additional requirements on clients.

Acknowledgments:
=================

The editors would like to thank Keith Moore for all his consultations
during the development of this draft. We would also like to thank Paul
Vixie for his assistance in debugging our implementation, and his answers
on our questions. Finally, we would like to acknowledge our enormous
intellectual debt to the participants in the Knoxville series of meetings,
as well as to the participants in the URI and URN working groups.

References:
===========

[1]  RFC-1737, "Functional Requirements for Uniform Resource Names", Karen
     Sollins and Larry Masinter, Dec. 1994.

[2]  The URN Implementors, Uniform Resource Names: A Progress Report,
     http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
     February 1996.

[3]  Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02.txt, Feb. 1997.

[4]  RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)",
     A. Gulbrandsen and P. Vixie, October 1996.

[5]  RFC-xxxx, "A Trivial Convention for using HTTP in URN Resolution",
     Ron Daniel Jr., currently available as draft-ietf-urn-http-conv-01.txt,
     Feb. 1997.

[6]  RFC-xxxx, "URN Resolution Services", ???, draft-ietf-urn-???
     (This document is on the URN-WG's list of documents to prepare, but
     has not yet been written. It will get its start from the treatment of
     resolution services in [4]).

[7]  Keith Moore, Shirley Browne, Jason Cox, and Jonathan Gettler,
     Resource Cataloging and Distribution System, Technical Report CS-97-346,
     University of Tennessee, Knoxville, December 1996

[8]  Paul Vixie, personal communication.

[9]  RFC-822, "Standard for the Format of ARPA Internet Text Messages",
     Dave H. Crocker, August 1982.  

[10] Charles Orth, Bill Arms; Handle Resolution Protocol Specification,
     http://www.handle.net/docs/client_spec.html

[11] RFC-1714, "Referral Whois Protocol (RWhois)", S. Williamson and
     M. Kosters, November 1994.

[12] Information Retrieval (Z39.50): Application Service Definition and
     Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.

[13] IEEE Standard for Information Technology - Portable Operating System
     Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std
     1003.2-1992; The Institute of Electrical and Electronics Engineers;
     New York; 1993. ISBN:1-55937-255-9

[14] RFC-1123, "Requirements for Internet Hosts - Application and Support"
     R. Braden, Oct. 1989.

[15] RFC-xxxx, "Requirements and a Framework for URN Resolution Systems",
     Karen Sollins, draft-ietf-urn-req-frame-00.txt, November 1996.

Security Considerations
=======================

  The use of "urn.net" as the registry for URN namespaces is subject to
  denial of service attacks, as well as other DNS spoofing attacks. The
  interactions with DNSSEC are currently being studied. It is expected
  that NAPTR records will be signed with SIG records once the DNSSEC
  work is deployed. 

  The rewrite rules make identifiers from other namespaces subject to
  the same attacks as normal domain names. Since they have not been
  easily resolvable before, this may or may not be considered a problem.

  Regular expressions should be checked for sanity, not blindly passed
  to something like PERL. 

  This document has discussed a way of locating a resolver, but has not
  discussed any detail of how the communication with the resolver takes
  place. There are significant security considerations attached to the
  communication with a resolver. Those considerations are outside the
  scope of this document, and must be addressed by the specifications
  for particular resolver communication protocols.

Author Contact Information:
===========================

Ron Daniel
Los Alamos National Laboratory
MS B287
Los Alamos, NM, USA, 87545
voice:  +1 505 665 0597
fax:    +1 505 665 4939
email:  [email-masked]

Michael Mealling
Network Solutions
505 Huntmar Park Drive
Herndon, VA  22070
voice: (703) 742-0400
fax: (703) 742-9552
email: [email-masked]
URL: http://www.netsol.com/

    This draft expires 26 Sept., 1997.

Date: Wed, 12 Mar 1997 14:49:12 -0700
To: [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: [URN] NAPTR changes
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Hi,

I've modified the NAPTR draft to accomodate the remarks collected during
the WG last call period. Here is a paraphrase of the comments and the
changes I made. The full copy of the -04 version of NAPTR will follow
in a seperate message.

1) Karen Sollins asked that the abstract be modified to mention that NAPTR
   is an experimental resolver disovery service.

That has been done.

2) Karen also suggested that the POSIX ERE syntax be summarized in an
   appendix to assist those who don't have a copy of the POSIX spec handy.

I took another look at the POSIX ERE specification. I do not think that I
can accurately summarize it in a reasonable amount of time, short of
repeating it verbatim. The probability of coming up with something that is
not quite interoperable is too high.

If someone wants to implement a NAPTR-handling system, there are a number of
free and commercial regular expression packages they can use. Or, if they
insist on rolling their own, they can do an inter-library loan of the
spec. Given the availability of this material, I don't believe that failure
to provide such a summary presents a serious impediment to implementation.
Further, I think interoperability is better served by having people rely on
the real specification.

3) Karen also suggested that the security considerations section was
   not detailed enough. In a different message, Ed Lewis suggested that it
   was probably OK.

I have added one paragraph to that section which states that any security
considerations for communicating with a particular resolver are outside
the bounds of this spec but must be addressed in the specifications for
resolver communication protocols.

4) Ed Lewis pointed out some flaws in my BNF for the substitution expression
   grammar, and raised the issue of host names vs. domain names.

I changed the grammar, and added a statement that the output of the
substitution expression MUST result in a string that obeys the syntax
of DNS host names.

5) Martin Duerst raised the question of how the regular expressions should
   deal with %encoded characters - in their encoded or binary form?

I added a statement that the URN Syntax draft defines a canonical form for
URNs, which %encodes characters outside a limited repertoire. The regular
expressions MUST be constructed to operate on the canonical form of a URN.
Since this means we have to match %encoded characters, the regexps are
going to be especially ugly. Sorry.

I'll send the -04 version of the draft to the list in just a minute.

Regards,

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: Wed, 12 Mar 1997 18:15:29 +0000
To: "Ron Daniel Jr." <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: Re: [URN] URNs grandfathering certain Object or Interface References
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Ron,

I'm off on leave tomorrow, so a quick answer...

At 10:22 12/03/97 -0700, Ron Daniel Jr. wrote:
>Cheap answer #1 is that what you are asking for is a Turing-complete
>way of operating on URIs. Declare a new flag, lets say "J", and use the
>regexp field to carry Java bytecodes instead of regular expressions.
>Clients that don't know the "J" flag ignore the record, those that do
>know it could run the supplied bytecodes to learn how to crack such an
>opaque identifier and what to do with the resulting pieces. For a
>variety of reasons this is a bad idea, but is allowed by the draft.
>(Well, change "J" to a digit and it is allowed as a local experiment. Try
>to use an alphabetic flag and you will have to contend with people like me
>on the list who will oppose doing such a thing).

Fine - or a further flag that indicates "expect the URN/URL of the bytecode"?

>
>Cheap answer #2 is that we don't have to dump it all onto one global
>resolver, we can use the "S" flag and a SRV record to dump it all onto
>a resolver that is replicated to whatever degree one needs.

Not sufficient for CORBA/2 interoperability. The point is that domains can
be isolated apart from a local ORB protocol-IIOP gateway, so need some way
to identify which global replica is accessible protocol-wise.

>
>Cheap answer #3 is that instead of using one central resolver, you use
>some arbitrary subset of the characters in the identifier to distribute
>the resolutions to an arbitrary number of resolver services. For IORs we
>might use the last character, which will distribute the load to 16 possible
>places. Use the last two and we can go 256 different places, ...

I believe a portion of the hex strong represents the resolution service
scope that will give the right answer. CORBA/2 deliberately doesn't use
global scope naming (hence my exhortation to read their case against global
naming in the reply to Leslie). Accessing the resolver in the local context
might give an answer but not the right answer, because names are context
dependent.

>The real answer is more complex:
>  a) What you are asking for is more than the NAPTR system is
>     trying to solve. It is OK for us to start simple. There are
>     a lot of important namespaces, such as ISBN, SICI, .. that can
>     be handled using only syntactic transformations. NAPTR
>     is intended to be the first, not last, resolver discovery
>     service. Later ones can try to solve this problem directly if
>     experience with NAPTR shows that it is a significant problem.
>  b) NAPTR is intended to be a fallback resolution approach, and clients
>     should try other things first. IORs are references to CORBA objects,
>     and clients can invoke the object's methods, but only if they know IIOP
>     or some other way to talk to the Object Request Broker associated with
>     the object. Clients that speak IIOP should do so early on
>     and not mess with NAPTR. Clients that don't speak IIOP might end up
>     trying NAPTR and get back a record like:
>
>      ior.urn.net NAPTR 1 1 "p" "iiop" "" foo.omg.org
>
>     which tells them they need to know the IIOP protocol to do anything more
>     with the identifier.

I think this is the correct answer, which I alluded to in my original posting:

>>Alternatively, given that Object systems have their own location
transparency schemes, might URN not be relevant here (then we'd have to
rename them FURNs (Fairly Universal [as opposed to Uniform] Resource
Names)? I would have thought that if URN could be made relevant, it should
be. 

I await the replies from Microsoft & OMG with antici...pation.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Wed, 12 Mar 1997 17:03:49 +0000
To: "Kindel, Charlie" <[email-masked]>, "Watson, Andrew" <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: [URN] The IETF Uniform Resource Names Working Group invites your comments
Cc: [email-masked], [email-masked] (Leslie Daigle)
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Charlie, Andrew,

Leslie Daigle, the co-chair of the IETF URN working group has asked me to
invite you two to comment on a problem I have just thrown into the IETF URN
working group. Alternatively can you forward this to someone with the time
and equivalent expertise to look into this?

The question is do you think the NAPTR proposal (see below) could be made
to assimilate both "clsid:" and "IOR:" identifier schemes as a global
naming glue?

To catch up on the conversation so far, see the mailing list archive at
ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive/urn-ietf.archive.970
3 - then search for the string "Interface References" in the subject line.
I have attached the 3 postings in this thread so far as the archive is not
ordered by thread.

To catch up on the proposal at issue, see the Internet draft at:
http://www.acl.lanl.gov/URN/naptr.txt (identical to
draft-ietf-urn-naptr-03.txt in your favourite internet-drafts directory).

Bob

---No 1 in thread---
>>>Date: Tue, 11 Mar 1997 14:59:39 +0000
>>>To: [email-masked]
>>>From: Bob Briscoe <[email-masked]>
>>>Subject: URNs grandfathering certain Object or Interface References
>>>
>>>Apologies if this has already covered - I've not being reading the URN
list too carefully recently, but a scan of the archive and the latest NAPTR
draft makes me think I have identified a new problem.
>>>
>>>The NAPTR proposal has a regexp/replacement field based on sed which is
a text based transformation.
>>>
>>>DCE universally unique id's (UUIDs) used by Microsoft's COM (as well as
DCE) and CORBA/2 Interoperable Object References (IORs) are typically
generated to include a references to the service for resolving them but
they can both be stringified to end up being a string of hex characters.
Proposals have been put forward to introduce these as new URL schemes.
>>>
>>>Refer to:
>>>The "clsid:" URL Scheme, Charlie Kindel, Microsoft Corporation, Feb 28
1996 Draft, <URL:http://www.w3.org/pub/WWW/Addressing/clsid-scheme>
>>>
>>>CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.6.5 Stringified Object References]
>>>
>>>You end up with URLs like:
>>>clsid:EFF6744C-7143-11cf-A51B-080036F12502
>>>or
>>>IOR:000000000000001b9444c3a48656c6c6f576f726c642f476f6f644461793a312e3000
00000000010000000000000044000100000000000e3133302e31303a22e3137362e3900d7820
000002800504d43000000010000001448656c6c6f576f726c643a3a476f6f644461790000000
002cc52247e
>>>
>>>I don't know to much about UUIDS but I know that IORs are intended to be
semi-resolvable outside the domain in which their id has true context, at
least to the extent that the services they rely on for resolution, and the
originating domain can be identified.
>>>
>>>The problem is that some COM/CORBA based systems can interpret these
strings of hex digits to extract the machine/port etc. which hosts the
object they need for resolution, but the algorithm isn't a simple textual
transformation.
>>>
>>>How might NAPTR cope with this without just resorting to a replacement
string and lumping the whole problem on one global resolver for the whole
scheme leading to a horrible bottleneck?
>>>
>>>Alternatively, given that Object systems have their own location
transparency schemes, might URN not be relevant here (then we'd have to
rename them FURNs (Fairly Universal Resource Names)? I would have thought
that if URN could be made relevant, it should be.
>>>
>>>Apologies in advance for anyone who wants me to explain these schemes in
any more depth - my knowledge is fairly sketchy.
>>>
>>>Bob

---No 2 in thread---
>>From: [email-masked] (Leslie Daigle)
>>Date: Tue, 11 Mar 1997 14:57:36 -0500
>>To: Bob Briscoe <[email-masked]>, [email-masked]
>>Subject: Re: [URN] URNs grandfathering certain Object or Interface
References
>>
>>Bob,
>>
>>I'm glad you've brought up a couple of emerging electronic namespaces that
>>are clear candidates for URN namespaces.
>>
>>Ron may want to take a more detailed shot at NAPTR and the specific issues
>>you've raised wrt the use of text-replacement only for these namespaces.
>>
>>I'd like to put a little context around the whole issue:
>>
>>	. As Ron is very good about reminding us regularly, NAPTR is 
>>	  meant to be an _experimental_ implementation of the general
>>	  architecture for URN systems.  It is proposed as experimental
>>	  specifically so that we can answer questions with concrete
>>	  experience on:
>>
>>		. what are the real security issues
>>
>>		.(most relevant here) what _is_ a sufficiently powerful 
>>		 and yet generally-implementable method for specifying
>>		 transformations? (regexps are already dangerously
>>		 complex, and yet there are clearly things they cannot do).
>>
>>> The problem is that some COM/CORBA based systems can interpret these
>>> strings of hex digits to extract the machine/port etc. which hosts the
>>> object they need for resolution, but the algorithm isn't a simple textual
>>> transformation.
>>> 
>>> How might NAPTR cope with this without just resorting to a replacement
>>> string and lumping the whole problem on one global resolver for the whole
>>> scheme leading to a horrible bottleneck?
>>
>>The key thing to remember with the proposed URN resolution _framework_
>>is that the first step in resolution is to determine the authority
>>that _can_  assert machine, port, protocol for a particular URN.  I.e.,
>>this is step one in distributing the problem.  Step two is to perform
>>some kind of lookup at/of that authority to get that information.  The
NAPTR 
>>proposal uses the same basic DNS lookup algorithms for both of these
steps, so 
>>they start to look the same.  BUT, the key thing in finding a mapping from 
>>UUIDs and IORs would be to determine how to find the authority for a
particular 
>>one, and then run some kind of local process there  to interpret the
namespace-
>>specific stuff (HEX code, here).
>>
>>So, bringing either of these namespaces into URN-land may not just be a
question
>>of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
>>may be the case that the process of developing these as URN namespaces will
>>include attaching some reference to the authority that will be responsible
>>for performing the analysis of the HEX representation.
>>
>>For example, 
>>
>>> clsid:EFF6744C-7143-11cf-A51B-080036F12502
>>
>>could become 
>>
>>  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502
>>
>>or even
>>
>>  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>
>>
>>The first step in resolving this URN is to identify that it is a clsid
>>namespace URN -- this indicates how to go about finding the naming 
>>authority ID, which can be textually extracted from either of the above.  
>>
>>Now, if that NA-ID can be mapped onto a machine name in some regular way
>>(forget the pros and cons for a moment) then even NAPTR can be used to
>>look up the alias, find the current address, port and protocol to speak
>>to it to _resolve_ the clsid-specific string (the HEX resolution process).
>>
>>If you don't want to include such a NA-ID in the URN representation of the
>>clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
>>service (which could be mirrored). Note that the global service doesn't
have 
>>to do the entire document resolution - it "only" has to apply the "hex 
>>decoding" algorithm to the URN.  If that can't be done quickly, then it
>>would be a bottleneck no matter where it was handled.  
>>
>>So, I don't see anything here that really breaks the paradigm of the URN
>>framework acting as a "glue" that ties togethe multiple namespaces. It
>>is a _good_ case of things to test NAPTR against -- are there people 
>>involved with defining the UUID and IOR namespaces that are interested in
>>taking on the mapping from those spaces into a URN representation?  This
>>could be a great test-case for our grandfather-a-namespace issue, if
>>somebody that represents those namespaces is willing to take it on.
>>
>>Leslie.
>>
>>-- 
>>
>>----------------------------------------------------------------------------
>>
>>  "_Be_                                           Leslie Daigle
>>             where  you                           
>>                          _are_."                 Bunyip Information Systems
>>                                                  (514) 875-8611
>>                      -- ThinkingCat              [email-masked]
>>----------------------------------------------------------------------------
>>

---No 3 in thread---
>Date: Wed, 12 Mar 1997 16:25:07 +0000
>To: [email-masked] (Leslie Daigle)
>From: Bob Briscoe <[email-masked]>
>Subject: Re: [URN] URNs grandfathering certain Object or Interface References
>Cc: [email-masked]
>
>At 14:57 11/03/97 -0500, Leslie Daigle wrote:
>>		.(most relevant here) what _is_ a sufficiently powerful 
>>		 and yet generally-implementable method for specifying
>>		 transformations? (regexps are already dangerously
>>		 complex, and yet there are clearly things they cannot do).
>>
>
>I would suggest the reference in the CORBA spec I cited would be worth
reading for the thinking on context relative naming from the OMG's members.
There is years of academic thought and history behind it. CORBA naming
interoperability between very different ORB domains is targeting the same
problem as URN.
>
>See CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.5 & 10.6]
>
>>The key thing to remember with the proposed URN resolution _framework_
>>is that the first step in resolution is to determine the authority
>>that _can_  assert machine, port, protocol for a particular URN.  I.e.,
>>this is step one in distributing the problem.  Step two is to perform
>>some kind of lookup at/of that authority to get that information.  The
NAPTR 
>>proposal uses the same basic DNS lookup algorithms for both of these
steps, so 
>>they start to look the same.  BUT, the key thing in finding a mapping from 
>>UUIDs and IORs would be to determine how to find the authority for a
particular 
>>one, and then run some kind of local process there  to interpret the
namespace-
>>specific stuff (HEX code, here).
>>
>>So, bringing either of these namespaces into URN-land may not just be a
question
>>of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
>>may be the case that the process of developing these as URN namespaces will
>>include attaching some reference to the authority that will be responsible
>>for performing the analysis of the HEX representation.
>>
>>For example, 
>>
>>> clsid:EFF6744C-7143-11cf-A51B-080036F12502
>>could become 
>>  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502
>>or even
>>  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>
>>
>>The first step in resolving this URN is to identify that it is a clsid
>>namespace URN -- this indicates how to go about finding the naming 
>>authority ID, which can be textually extracted from either of the above.  
>
>Duplicating the <naming authority ID> that is already embedded in the hex
would be ANATHEMA to the reliability and security of the processes for
publishing these names, not to mention performance which is why these
things are stringified to hex rather than ASCII - a big winge the OO
community has about IETF protocols is that they all appear to have been
left permanently in de-bug mode so humans can read the protocol headers (I
personally think this is a GOOD THING, but it does have performance problems).
>
>>
>>Now, if that NA-ID can be mapped onto a machine name in some regular way
>>(forget the pros and cons for a moment) then even NAPTR can be used to
>>look up the alias, find the current address, port and protocol to speak
>>to it to _resolve_ the clsid-specific string (the HEX resolution process).
>>
>>If you don't want to include such a NA-ID in the URN representation of the
>>clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
>>service (which could be mirrored). Note that the global service doesn't
have 
>>to do the entire document resolution - it "only" has to apply the "hex 
>>decoding" algorithm to the URN.  If that can't be done quickly, then it
>>would be a bottleneck no matter where it was handled.  
>
>Again, this is ANATHEMA to the designers of these systems. We have to
consider gazillions of object refs, bearing in mind that there's one for
each *object* not just each class of *object*. For instance the (fixed
size) DCE/COM name-space has been designed to be larger than the estimated
number of atoms in the universe. The CORBA namespace is gazillions of
orders of magnitude bigger than that (the number of permutations of atoms
in the universe is more relevant to the number of possible permutations of
objects, profiles and service environments).
>
>>
>>So, I don't see anything here that really breaks the paradigm of the URN
>>framework acting as a "glue" that ties togethe multiple namespaces.
>
>I think NAPTR is a neat trick for farming out the problem very early on,
however, I think we may find these object-based schemes do break the
*currently proposed* paradigm (although my understanding of how their names
are constructed is sketchy), simply because of the performance requirements
at huge scale. For instance, BT has already found experimental CORBA-based
systems to be too slow to do 0800 (free phone) look-ups within the 500msec
time budget we have between the end of dialling and ringing (before the
caller hangs up thinking there's a problem). Just object location (id
look-ups) for 4 objects out of c.1million currently takes more than this
time budget. I'm not saying an *experimental* system like NAPTR should meet
these requirements, but I am saying if the intention is to assimilate all
naming, it has to be a *requirement* to *be able to* meet the *highest*
common denominator performance target.
>
>>It
>>is a _good_ case of things to test NAPTR against -- are there people 
>>involved with defining the UUID and IOR namespaces that are interested in
>>taking on the mapping from those spaces into a URN representation?  This
>>could be a great test-case for our grandfather-a-namespace issue, if
>>somebody that represents those namespaces is willing to take it on.
>>
>
>I'll refer Charlie Kindel (Microsoft) and Andrew Watson (OMG chief
architect) to the archive entries of this thread. I was going to do this
anyway once I had done an initial sanity check with the URN working group.
>
>Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Wed, 12 Mar 1997 10:22:25 -0700
To: Bob Briscoe <[email-masked]>, [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] URNs grandfathering certain Object or Interface References
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Hi Bob,

Nice to hear from you again. Sorry to be a little late replying, I was
off-net yesterday.

>The problem is that some COM/CORBA based systems can interpret these
>strings of hex digits to extract the machine/port etc. which hosts the
>object they need for resolution, but the algorithm isn't a simple textual
>transformation.
>
>How might NAPTR cope with this without just resorting to a replacement
>string and lumping the whole problem on one global resolver for the whole
>scheme leading to a horrible bottleneck?

Don't know anything about UUIDs, but I  know a little about IORs and CORBA,
so I will answer your questions using those as examples.
 
Let me give four answers - three cheap ones and the real one.

Cheap answer #1 is that what you are asking for is a Turing-complete
way of operating on URIs. Declare a new flag, lets say "J", and use the
regexp field to carry Java bytecodes instead of regular expressions.
Clients that don't know the "J" flag ignore the record, those that do
know it could run the supplied bytecodes to learn how to crack such an
opaque identifier and what to do with the resulting pieces. For a
variety of reasons this is a bad idea, but is allowed by the draft.
(Well, change "J" to a digit and it is allowed as a local experiment. Try
to use an alphabetic flag and you will have to contend with people like me
on the list who will oppose doing such a thing).

Cheap answer #2 is that we don't have to dump it all onto one global
resolver, we can use the "S" flag and a SRV record to dump it all onto
a resolver that is replicated to whatever degree one needs.

Cheap answer #3 is that instead of using one central resolver, you use
some arbitrary subset of the characters in the identifier to distribute
the resolutions to an arbitrary number of resolver services. For IORs we
might use the last character, which will distribute the load to 16 possible
places. Use the last two and we can go 256 different places, ...

There is more than one way to do what you are asking for if it really has
to be done using NAPTR.

The real answer is more complex:
  a) What you are asking for is more than the NAPTR system is
     trying to solve. It is OK for us to start simple. There are
     a lot of important namespaces, such as ISBN, SICI, .. that can
     be handled using only syntactic transformations. NAPTR
     is intended to be the first, not last, resolver discovery
     service. Later ones can try to solve this problem directly if
     experience with NAPTR shows that it is a significant problem.
  b) NAPTR is intended to be a fallback resolution approach, and clients
     should try other things first. IORs are references to CORBA objects,
     and clients can invoke the object's methods, but only if they know IIOP
     or some other way to talk to the Object Request Broker associated with
     the object. Clients that speak IIOP should do so early on
     and not mess with NAPTR. Clients that don't speak IIOP might end up
     trying NAPTR and get back a record like:

      ior.urn.net NAPTR 1 1 "p" "iiop" "" foo.omg.org

     which tells them they need to know the IIOP protocol to do anything more
     with the identifier.

Gotta go now, best regards,

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: Wed, 12 Mar 1997 16:25:07 +0000
To: [email-masked] (Leslie Daigle)
From: Bob Briscoe <[email-masked]>
Subject: Re: [URN] URNs grandfathering certain Object or Interface References
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

At 14:57 11/03/97 -0500, Leslie Daigle wrote:
>		.(most relevant here) what _is_ a sufficiently powerful 
>		 and yet generally-implementable method for specifying
>		 transformations? (regexps are already dangerously
>		 complex, and yet there are clearly things they cannot do).
>

I would suggest the reference in the CORBA spec I cited would be worth
reading for the thinking on context relative naming from the OMG's members.
There is years of academic thought and history behind it. CORBA naming
interoperability between very different ORB domains is targeting the same
problem as URN.

See CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.5 & 10.6]

>The key thing to remember with the proposed URN resolution _framework_
>is that the first step in resolution is to determine the authority
>that _can_  assert machine, port, protocol for a particular URN.  I.e.,
>this is step one in distributing the problem.  Step two is to perform
>some kind of lookup at/of that authority to get that information.  The NAPTR 
>proposal uses the same basic DNS lookup algorithms for both of these
steps, so 
>they start to look the same.  BUT, the key thing in finding a mapping from 
>UUIDs and IORs would be to determine how to find the authority for a
particular 
>one, and then run some kind of local process there  to interpret the
namespace-
>specific stuff (HEX code, here).
>
>So, bringing either of these namespaces into URN-land may not just be a
question
>of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
>may be the case that the process of developing these as URN namespaces will
>include attaching some reference to the authority that will be responsible
>for performing the analysis of the HEX representation.
>
>For example, 
>
>> clsid:EFF6744C-7143-11cf-A51B-080036F12502
>could become 
>  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502
>or even
>  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>
>
>The first step in resolving this URN is to identify that it is a clsid
>namespace URN -- this indicates how to go about finding the naming 
>authority ID, which can be textually extracted from either of the above.  

Duplicating the <naming authority ID> that is already embedded in the hex
would be ANATHEMA to the reliability and security of the processes for
publishing these names, not to mention performance which is why these
things are stringified to hex rather than ASCII - a big winge the OO
community has about IETF protocols is that they all appear to have been
left permanently in de-bug mode so humans can read the protocol headers (I
personally think this is a GOOD THING, but it does have performance problems).

>
>Now, if that NA-ID can be mapped onto a machine name in some regular way
>(forget the pros and cons for a moment) then even NAPTR can be used to
>look up the alias, find the current address, port and protocol to speak
>to it to _resolve_ the clsid-specific string (the HEX resolution process).
>
>If you don't want to include such a NA-ID in the URN representation of the
>clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
>service (which could be mirrored). Note that the global service doesn't have 
>to do the entire document resolution - it "only" has to apply the "hex 
>decoding" algorithm to the URN.  If that can't be done quickly, then it
>would be a bottleneck no matter where it was handled.  

Again, this is ANATHEMA to the designers of these systems. We have to
consider gazillions of object refs, bearing in mind that there's one for
each *object* not just each class of *object*. For instance the (fixed
size) DCE/COM name-space has been designed to be larger than the estimated
number of atoms in the universe. The CORBA namespace is gazillions of
orders of magnitude bigger than that (the number of permutations of atoms
in the universe is more relevant to the number of possible permutations of
objects, profiles and service environments).

>
>So, I don't see anything here that really breaks the paradigm of the URN
>framework acting as a "glue" that ties togethe multiple namespaces.

I think NAPTR is a neat trick for farming out the problem very early on,
however, I think we may find these object-based schemes do break the
*currently proposed* paradigm (although my understanding of how their names
are constructed is sketchy), simply because of the performance requirements
at huge scale. For instance, BT has already found experimental CORBA-based
systems to be too slow to do 0800 (free phone) look-ups within the 500msec
time budget we have between the end of dialling and ringing (before the
caller hangs up thinking there's a problem). Just object location (id
look-ups) for 4 objects out of c.1million currently takes more than this
time budget. I'm not saying an *experimental* system like NAPTR should meet
these requirements, but I am saying if the intention is to assimilate all
naming, it has to be a *requirement* to *be able to* meet the *highest*
common denominator performance target.

>It
>is a _good_ case of things to test NAPTR against -- are there people 
>involved with defining the UUID and IOR namespaces that are interested in
>taking on the mapping from those spaces into a URN representation?  This
>could be a great test-case for our grandfather-a-namespace issue, if
>somebody that represents those namespaces is willing to take it on.
>

I'll refer Charlie Kindel (Microsoft) and Andrew Watson (OMG chief
architect) to the archive entries of this thread. I was going to do this
anyway once I had done an initial sanity check with the URN working group.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 12 Mar 1997 10:39:36 -0600 (CST)
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] semantic representation in URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Karen R. Sollins writes:
 > Location is one form of semantic information; think of it as one dimension
 > in semantic space.

Since the subject of this thread is semantics in URNs, and the broader
question is not just human friendly semantics but any kind of
semantics, we should probably try to stay at a level above the details
of particular semantic dimensions.  Each dimension could lead us off
in another direction.

For example, the issue of location semantics is a big one and is
exactly the same question as URNs vs URLs and whether they are
distinguishable.  Attempting to stay clear of that debate, it would
help if you could simply and precisely define location.  I.e. what are
(is?) the semantics of locations?  (Dan Connelly claims that there is
not a definition of location-independence in any RFC (or draft?))  My
claim is that any adequate definition of location would include URNs
themselves if URNs can be looked up in a globally consistent manner.
I'll respond to your definition in private mail.

So the general question, applied to other kinds of semantics, is: how
do you really know when you are building in some kind of semantics?
There is explicit semantics and implicit semantics.

But there are some other distinctions that should be considered in the
kinds of semantics.  There is semantics regarding the identifier
itself and semantics regarding the resource(s) associated with the
identifier.  For some kinds of semantics, it is difficult to
distinguish whether you have one or the other.  You give examples of
semantics of the resource:

 > Another might be programming language in which
 > something is implemented or natural language in which it is expressed.
 > Consider that another dimension. Another might be some indication of
 > underlying algorithm on which the resource is based.  Again, another
 > dimension.

But here are some semantics of the identifier itself.  The scheme name
(e.g. "urn:"), naming authority (single or hierarchy), structure of
the identifier itself are very low level semantics (i.e. on the
syntax-semantics continuum) about how to interpret the identifier
itself.  One step up from this, there might be a field that indicates
how to interpret the remainder of the identifier.  Others: there might
be a date field that indicates when the identifier itself was created,
not the resource it refers to.  There might be a checksum or signature
field that can be used to verify the identifier itself, not the
resource it refers to.

One place where the boundary between semantics of the identifier and
semantics of the resource gets blurry is in the organization of the
name space.  In a hierarchical name space with a hierarchical name,
the components of the name presummably (but not necessarily) map on to
the organization of the space.  This blurs the distinction because in
the process of resolving the identifier over several resolution steps,
you are getting closer to the resource itself.  As the organization of
the space changes, the concern is that the resolution process could
break.  I discussed strategies and mechanisms for dealing with that
reorganization in previous mail.

The key question regarding semantics is whether the semantics of the
organization of the name space is a reflection of the semantics of the
resources.  Yes and no.  Each node in the hierarchy (if it is a
hierarchy) can be considered to represent a collection, a resource
itself.  It may correspond to a resolution service that can provide
information about that collection resource.  But, importantly, these
collections need have no necessary semantic relevance in that the
resources in a collection need not be at all related to each other
other than being in the same collection.  Whether it is useful to have
no meaningful relationship between collection members is another
question.

What I think should happen is that these collections are meaningful,
but their meaning is not intended to be complete or persistent.  In
other words, the collection of /edu/uiuc/ncsa/liberte is generally my
stuff, but some of my stuff might also appear elsewhere
(e.g. /com/bunyip/ietf/urn/liberte) and I might provide access to
other people's stuff via my space (e.g. ../liberte/hotlist/urns).

Then we get down to semantics that is more clearly about the resource
itself, but notice that we are getting into the metadata question.
(I.e. What is the difference between data and metadata?)  Bunches of
metadata could be included in identifiers (e.g. title, author, date,
subject, etc), and some people consider this to be the true way to
name resources.  For small resources, the resource *itself* could be
in the identifier (e.g. Larry's "data" URI).

My argument is that there will always be semantics in identifiers
unless the identifiers are useless for anything except for being
meaningless identifiers.  The nature of semantics is an association
between things, so, for example, you can get from an identifier to
the associated resource.

[Philosophical tangent: The general principal I am applying is that
there are really continuums everywhere.  Wherever we draw lines, we
distinguish things that are not really distinguishable.  It seems
useful to draw lines anyway, but the Universe conspires to ultimately
erase them, or scribble over them.]

 > Of course the number of possibilities is unlimited.  Yes,
 > n-dimensional space.  If URNs can be assumed to contain semantic
 > information, services will be built on that assumption, taking advantage of
 > the embedded knowledge.

Given the argument (conclusion?) that there will always be semantics
in identifiers, the question is how much and what kind of semantics.
It is a trade off.  Generally, the more semantics a service takes
advantage of, the more it needs to be flexible when those semantics
may change.  Location semantics is a relatively simple case that
requires an indirection or sequence of indirections to eventually find
the resource at some location.

 > If that knowledge can become invalid just as
 > location information can become invalid, we have an n-dimensional problem
 > where in URLs we have a one-dimensional problem.

URLs can have just as many dimensions of semantics as URNs.

 > Seems undesirable to me,
 > but the question is whether we should actively discourage our "customers"
 > from shooting themselves in the foot in this particular way or not.

We should discourage people from building services that don't work in
the face of changing semantics.  Putting it that way let's people
decide for themselves whether and how they can deal with changing
semantics.

 > What I was trying to say is that if the hierarchy reflects delegation then
 > using it to reflect something else as well (say, for example, derivation)
 > is extremely difficult because it is overloading the meaning of
 > hierarchical components.  Doing this in general probably becomes impossible.

I would tend to agree that overloading hierarchical components with
other semantics could cause problems, but there are other places that
additional semantics could be included in an identifier.  For example,
semantics could be included before or after the hierarchial part
(e.g. the //higher-level-space/lower/level/space and
...;name=value;name=value extensions), or each component could have
its own additional semantics that applies only to itself, or maybe to
the remainder of the path.

 > Saltzer, J., Reed, D., and Clark, D.D., "End-to-End Arguments in System
 > Design", ACM Transactions on Computer Systems, Vol. 2, No. 4, November
 > 1984, pp. 277-288.
 > 
 > This paper makes the argument that repeating functionality at different
 > layers of abstraction (particularly as exemplified in security mechanisms)
 > is a bad idea. It probably should be required reading for all systems and
 > protocol designers and implementers.  I strongly recommend it.

Looks very worthwhile.  1984 is BW (before web), so finding it on-line
might be difficult.  I'll have to take a trip to the library; could
be educational. :-)

 > ... And we say that semantics can be included in whatever language
 > the creator of the URN chooses, and if the semantics cannot be understood
 > and useful in other contexts, tough luck.

That's my conclusion too.

dan

Date: Wed, 12 Mar 1997 08:19:31 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Cc: [email-masked]
Subject: [URN] New URN syntax draft (-04)
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

--------------6EAA16BE35C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached is draft-ietf-urn-syntax-04.txt.

This draft has editorial changes made during WG last call.

--------------6EAA16BE35C4
Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="urn.syntax.txt"

Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-04.txt                                        AT&T
Expires in six months                                         March 1997

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-04.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

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers. This document sets
   forward the canonical syntax for URNs.  A discussion of both existing
   legacy and new namespaces and requirements for URN presentation and
   transmission are presented.  Finally, there is a discussion of URN
   equivalence and how to determine it.

1. Introduction

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces (which share the properties of URNs)
   into URN-space. Therefore, the URN syntax provides a means to encode
   character data in a form that can be sent in existing protocols,
   transcribed on most keyboards, etc.

Expires 9/30/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                     March 1997

2. Syntax

   All URNs have the following syntax (phrases enclosed in quotes are
   REQUIRED):

                     <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String (as discussed in [1]).

   RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
   for URN encoding, which have implications as far as limiting syntax.
   On the other hand, the requirement to support existing legacy naming
   systems has the effect of broadening syntax.  Thus, we discuss the
   acceptable syntax for both the Namespace Identifier and the Namespace
   Specific String separately.

2.1 Namespace Identifier Syntax

   The following is the syntax for the Namespace Identifier. To (a) be
   consistent with all potential resolution schemes and (b) not put any
   undue constraints on any potential resolution scheme, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <let-num> [ 1,31<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                     "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                     "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                     "Y" | "Z"

   <lower>       ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                     "y" | "z"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"

   This is slightly more restrictive that what is stated in [4] (which

Expires 9/30/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                     March 1997

   allows the characters "." and "+").  Further, the Namespace
   Identifier is case insensitive, so that "ISBN" and "isbn" refer to
   the same namespace.

   To avoid confusion with the "urn:" identifier, the NID "urn" is
   reserved and MUST NOT be used.

2.2 Namespace Specific String Syntax

   As required by RFC 1737, there is a single canonical representation
   of the NSS portion of an URN.   The format of this single canonical
   form follows:

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "@" | ";" | "$" |
                     "_" | "!" | "*" | "'"

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are not members of the URN
   character set above (<URN chars>).  Such strings MUST be translated
   into canonical NSS format before using them as protocol elements or
   otherwise passing them on to other applications. Translation is done
   by encoding each character outside the URN character set as a
   sequence of one to six octets using UTF-8 encoding [5], and the
   encoding of each of those octets as "%" followed by two characters
   from the <hex> character set above. The two characters give the
   hexadecimal representation of that octet.

2.3 Reserved characters

   The remaining character set left to be discussed above is the
   reserved character set, which contains various characters reserved
   from normal use.  The reserved character set follows, with a
   discussion on the specifics of why each character is reserved.

   The reserved character set is:

   <reserved>    ::= '%" | "/" | "?" | "#"

Expires 9/30/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                     March 1997

2.3.1 The "%" character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet.  Literal use of the "%" character in a
   namespace must be encoded using "%25" in URNs for that namespace.
   The presence of an "%" character in an URN MUST be followed by two
   characters from the <hex> character set.

   Namespaces MAY designate one or more characters from the URN
   character set as having special meaning for that namespace.  If the
   namespace also uses that character in a literal sense as well, the
   character used in a literal sense MUST be encoded with "%" followed
   by the hexadecimal representation of that octet.  Further, a
   character MUST NOT be "%"-encoded if the character is not a reserved
   character.  Therefore, the process of registering a namespace
   identifier shall include publication of a definition of which
   characters have a special meaning to that namespace.

2.3.2 The other reserved characters

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

2.4 Excluded characters

   The following list is included only for the sake of completeness.
   Any octets/characters on this list are explicitly NOT part of the URN
   character set, and if used in an URN, MUST be %encoded:

   <excluded> ::= octets 1-32 (1-20 hex) | "\" | """ | "&" | "<"
                  | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | "~"
                  | octets 127-255 (7F-FF hex)

   In addition, octet 0 (0 hex) should NEVER be used, in either
   unencoded or %-encoded form.

   An URN ends when an octet/character from the excluded character set
   (<excluded>) is encountered.  The character from the excluded
   character set is NOT part of the URN.

3. Support of existing legacy naming systems and new naming systems

   Any namespace (existing or newly-devised) that is proposed as an
   URN-namespace and fulfills the criteria of URN-namespaces MUST be

Expires 9/30/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                     March 1997

   expressed in this syntax.  If names in these namespaces contain
   characters other than those defined for the URN character set, they
   MUST be translated into canonical form as discussed in section 2.2.

4. URN presentation and transport

   The URN syntax defines the canonical format for URNs and all URN
   transport and interchanges MUST take place in this format. Further,
   all URN-aware applications MUST offer the option of displaying URNs
   in this canonical form to allow for direct transcription (for example
   by cut and paste techniques).  Such applications MAY support display
   of URNs in a more human-friendly form and may use a character set
   that includes characters that aren't permitted in URN syntax as
   defined in this RFC (that is, they may replace %-notation by
   characters in some extended character set in display to humans).

5. Lexical Equivalence in URNs

   For various purposes such as caching, it's often desirable to
   determine if two URNs are the same without resolving them. The
   general purpose means of doing so is by testing for "lexical
   equivalence" as defined below.

   Two URNs are lexically equivalent if they are octet-by-octet equal
   after the following preprocessing:

           1. normalize the case of the leading "urn:" token
           2. normalize the case of the NID
           3. normalizing the case of any %-escaping

   Note that %-escaping MUST NOT be removed.

   Some namespaces may define additional lexical equivalences, such as
   case-insensitivity of the NSS (or parts thereof).  Additional lexical
   equivalences MUST be documented as part of namespace registration,
   MUST always have the effect of eliminating some of the false
   negatives obtained by the procedure above, and MUST NEVER say that
   two URNs are not equivalent if the procedure above says they are
   equivalent.

6. Examples of lexical equivalence

   The following URN comparisons highlight the lexical equivalence
   definitions:

           1- URN:foo:a123,456
           2- urn:foo:a123,456
           3- urn:FOO:a123,456

Expires 9/30/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                     March 1997

           4- urn:foo:A123,456
           5- urn:foo:a123%2C456
           6- URN:FOO:a123%2c456
   URNs 1, 2, and 3 are all lexically equivalent.  URN 4 is not
   lexically equivalent any of the other URNs of the above set.  URNs 5
   and 6 are only lexically equivalent to each other.

7. Functional Equivalence in URNs

   Functional equivalence is determined by practice within a given
   namespace and managed by resolvers for that namespeace. Thus, it is
   beyond the scope of this document.  Namespace registration must
   include guidance on how to determine functional equivalence for that
   namespace, i.e. when two URNs are the identical within a namespace.

8. Security considerations

   This document specifies the syntax for URNs.  While some namespaces
   resolvers may assign special meaning to certain of the characters of
   the Namespace Specific String, any security consideration resulting
   from such assignment are outside the scope of this document.  It is
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

9. Acknowledgments

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

10. References

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

         [1]         K. R. Sollins, "Requirements and a Framework for
                     URN Resolution Systems," Internet Draft (work in
                     progress),  November 1996.

         [2]         T. Berners-Lee, "Universal Resource Identifiers in
                     WWW," RFC 1630, June 1994.

         [3]         K. Sollins and L. Masinter,  "Functional Require-
                     ments for Uniform Resource Names," RFC 1737.
                     December 1994.

Expires 9/30/97                                                 [Page 6]

INTERNET DRAFT                 URN Syntax                     March 1997

         [4]         T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
                     Resource Locators (URL)," Internet Draft (work in
                     progress),  December 1996.

         [5]         Appendix A.2 of The Unicode Consortium, "The
                     Unicode Standard, Version 2.0", Addison-Wesley
                     Developers Press, 1996.  ISBN 0-201-48345-9.

11. Editor's address

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

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

Appendix A. Handling of URNs by URL resolvers/browsers.

   The URN syntax has been defined so that URNs can be used in places
   where URLs are expected.  A resolver that conforms to the current URL
   syntax specification [3] will extract a scheme value of "urn:"
   rather than a scheme value of "urn:<nid>".

   An URN MUST be considered an opaque URL by URL resolvers and passed
   (with the "urn:" tag) to an URN resolver for resolution.  The URN
   resolver can either be an external resolver that the URL resolver
   knows of, or it can be functionality built-in to the URL resolver.

   To avoid confusion of users, an URL browser SHOULD display the com-
   plete URN (including the "urn:" tag) to ensure that there is no con-
   fusion between URN namespace identifiers and URL scheme identifiers.

              This Internet Draft expires September 30, 1997.

Expires 9/30/97                                                 [Page 7]

--------------6EAA16BE35C4--

Date: Tue, 11 Mar 1997 23:38:50 -0500
To: Daniel LaLiberte <[email-masked]>, [email-masked]
From: "Karen R. Sollins" <[email-masked]>
Subject: Re: [URN] semantic representation in URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Dan,

I am in agreement with you on a number of points.  I also was trying to be
objective and play devil's advocate, in order to encourage people to jump
in on whatever side they wanted (and you jumped in on both:-).  So, I'll
just extract parts of your message for response.

At 4:01 PM -0600 3/10/97, Daniel LaLiberte wrote:

...
>
> > Remember that one form of semantics is location information,
> > and if we allow others, we will have the problems in multiple
> > dimensions.
>
>Could you be more specific about this?  What are these multiple
>dimensions?  Are you saying that any kind of semantics ties down the
>identifier, as in it locates the identifier in some n-dimensional space?

Location is one form of semantic information; think of it as one dimension
in semantic space.  Another might be programming language in which
something is implemented or natural language in which it is expressed.
Consider that another dimension. Another might be some indication of
underlying algorithm on which the resource is based.  Again, another
dimension.  Of course the number of possibilities is unlimited.  Yes,
n-dimensional space.  If URNs can be assumed to contain semantic
information, services will be built on that assumption, taking advantage of
the embedded knowledge.  If that knowledge can become invalid just as
location information can become invalid, we have an n-dimensional problem
where in URLs we have a one-dimensional problem.  Seems undesirable to me,
but the question is whether we should actively discourage our "customers"
from shooting themselves in the foot in this particular way or not.

> > 3) The hierarchy embodied on URNs reflects namespace delegation.
>
>Delegation is not required, but hierarchy *allows* delegation.
>
> > To cause that to reflect other semantics as well will be very
> > difficult in the general case.
>
>I don't understand what you are thinking here.  Please explain.

What I was trying to say is that if the hierarchy reflects delegation then
using it to reflect something else as well (say, for example, derivation)
is extremely difficult because it is overloading the meaning of
hierarchical components.  Doing this in general probably becomes impossible.

>What is the end-to-end argument?

The reference is to:

Saltzer, J., Reed, D., and Clark, D.D., "End-to-End Arguments in System
Design", ACM Transactions on Computer Systems, Vol. 2, No. 4, November
1984, pp. 277-288.

This paper makes the argument that repeating functionality at different
layers of abstraction (particularly as exemplified in security mechanisms)
is a bad idea. It probably should be required reading for all systems and
protocol designers and implementers.  I strongly recommend it.

> > 5) Given the problems with character sets and internationalization,
> > what is the probability of expressing semantics that would be globally
> > meaningful.
>
>Is there really a problem here?  When would I need to refer to a document
>in chinese with a chinese URN?
>
>I don't follow character set discussions, but one of the PRO arguments
>is that we *need* to use international character sets to make URNs
>useful world-wide.

I don't follow the character set discussions either.  But, the problem I
was highlighting here was that, if there is an expectation that useful (to
whom- or what-ever) semantics is to be included in URNs then the
internationalization problem becomes much more complex than the character
set internationalization problem.  The names are no longer "just bit
strings"but instead include meaningful content.   Thus, given that we do
not have a universal language (and apparently not even a universal
character set), I just don't see how to deal.  But, maybe it simply isn't
an issue.  And we say that semantics can be included in whatever language
the creator of the URN chooses, and if the semantics cannot be understood
and useful in other contexts, tough luck.

>dan

			Karen

From: [email-masked] (Leslie Daigle)
Date: Tue, 11 Mar 1997 14:57:36 -0500
To: Bob Briscoe <[email-masked]>, [email-masked]
Subject: Re: [URN] URNs grandfathering certain Object or Interface References
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Bob,

I'm glad you've brought up a couple of emerging electronic namespaces that
are clear candidates for URN namespaces.

Ron may want to take a more detailed shot at NAPTR and the specific issues
you've raised wrt the use of text-replacement only for these namespaces.

I'd like to put a little context around the whole issue:

	. As Ron is very good about reminding us regularly, NAPTR is 
	  meant to be an _experimental_ implementation of the general
	  architecture for URN systems.  It is proposed as experimental
	  specifically so that we can answer questions with concrete
	  experience on:

		. what are the real security issues

		.(most relevant here) what _is_ a sufficiently powerful 
		 and yet generally-implementable method for specifying
		 transformations? (regexps are already dangerously
		 complex, and yet there are clearly things they cannot do).

> The problem is that some COM/CORBA based systems can interpret these
> strings of hex digits to extract the machine/port etc. which hosts the
> object they need for resolution, but the algorithm isn't a simple textual
> transformation.
> 
> How might NAPTR cope with this without just resorting to a replacement
> string and lumping the whole problem on one global resolver for the whole
> scheme leading to a horrible bottleneck?

The key thing to remember with the proposed URN resolution _framework_
is that the first step in resolution is to determine the authority
that _can_  assert machine, port, protocol for a particular URN.  I.e.,
this is step one in distributing the problem.  Step two is to perform
some kind of lookup at/of that authority to get that information.  The NAPTR 
proposal uses the same basic DNS lookup algorithms for both of these steps, so 
they start to look the same.  BUT, the key thing in finding a mapping from 
UUIDs and IORs would be to determine how to find the authority for a particular 
one, and then run some kind of local process there  to interpret the namespace-
specific stuff (HEX code, here).

So, bringing either of these namespaces into URN-land may not just be a question
of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
may be the case that the process of developing these as URN namespaces will
include attaching some reference to the authority that will be responsible
for performing the analysis of the HEX representation.

For example, 

> clsid:EFF6744C-7143-11cf-A51B-080036F12502

could become 

  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502

or even

  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>

The first step in resolving this URN is to identify that it is a clsid
namespace URN -- this indicates how to go about finding the naming 
authority ID, which can be textually extracted from either of the above.  

Now, if that NA-ID can be mapped onto a machine name in some regular way
(forget the pros and cons for a moment) then even NAPTR can be used to
look up the alias, find the current address, port and protocol to speak
to it to _resolve_ the clsid-specific string (the HEX resolution process).

If you don't want to include such a NA-ID in the URN representation of the
clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
service (which could be mirrored). Note that the global service doesn't have 
to do the entire document resolution - it "only" has to apply the "hex 
decoding" algorithm to the URN.  If that can't be done quickly, then it
would be a bottleneck no matter where it was handled.  

So, I don't see anything here that really breaks the paradigm of the URN
framework acting as a "glue" that ties togethe multiple namespaces. It
is a _good_ case of things to test NAPTR against -- are there people 
involved with defining the UUID and IOR namespaces that are interested in
taking on the mapping from those spaces into a URN representation?  This
could be a great test-case for our grandfather-a-namespace issue, if
somebody that represents those namespaces is willing to take it on.

Leslie.

-- 

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

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

Date: Tue, 11 Mar 1997 14:59:39 +0000
To: [email-masked]
From: Bob Briscoe <[email-masked]>
Subject: [URN] URNs grandfathering certain Object or Interface References
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Apologies if this has already covered - I've not being reading the URN list
too carefully recently, but a scan of the archive and the latest NAPTR
draft makes me think I have identified a new problem.

The NAPTR proposal has a regexp/replacement field based on sed which is a
text based transformation.

DCE universally unique id's (UUIDs) used by Microsoft's COM (as well as
DCE) and CORBA/2 Interoperable Object References (IORs) are typically
generated to include a references to the service for resolving them but
they can both be stringified to end up being a string of hex characters.
Proposals have been put forward to introduce these as new URL schemes.

Refer to:
The "clsid:" URL Scheme, Charlie Kindel, Microsoft Corporation, Feb 28 1996
Draft, <URL:http://www.w3.org/pub/WWW/Addressing/clsid-scheme>

CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.6.5 Stringified Object References]

You end up with URLs like:
clsid:EFF6744C-7143-11cf-A51B-080036F12502
or
IOR:000000000000001b9444c3a48656c6c6f576f726c642f476f6f644461793a312e3000000
00000010000000000000044000100000000000e3133302e31303a22e3137362e3900d7820000
002800504d43000000010000001448656c6c6f576f726c643a3a476f6f644461790000000002
cc52247e

I don't know to much about UUIDS but I know that IORs are intended to be
semi-resolvable outside the domain in which their id has true context, at
least to the extent that the services they rely on for resolution, and the
originating domain can be identified.

The problem is that some COM/CORBA based systems can interpret these
strings of hex digits to extract the machine/port etc. which hosts the
object they need for resolution, but the algorithm isn't a simple textual
transformation.

How might NAPTR cope with this without just resorting to a replacement
string and lumping the whole problem on one global resolver for the whole
scheme leading to a horrible bottleneck?

Alternatively, given that Object systems have their own location
transparency schemes, might URN not be relevant here (then we'd have to
rename them FURNs (Fairly Universal Resource Names)? I would have thought
that if URN could be made relevant, it should be.

Apologies in advance for anyone who wants me to explain these schemes in
any more depth - my knowledge is fairly sketchy.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

From: [email-masked] (Leslie Daigle)
Date: Mon, 10 Mar 1997 23:40:07 -0500
To: "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] semantic representation in URNs
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

> encouraging or discouraging semantic expression in URNs?

I think this is where the split between URNs-in-general and individual
URN namespaces becomes crucial.

Because finding the one true way of representing semantics in URNs (even
including things like hierarchical representation), in a way that
works across all namespaces (those to be brought in, and those to be
created specifically for URNs), this should not be part of the overall
URN spec.

This is not to say that semantic expression should not be possible 
(human-friendliness (whatever that means in the context-near-you),
hierarchy, etc), within individual namespaces.  The definition of a 
namespace should include the specification of any relevant semantic
expressions.

The idea behind the URN framework was to provide the minimum necessary
set of requirements and services (what the IETF/Internet are good at)
to support the diverse namespaces that serve individual communities (what
people who develop naming systems are good at) and give us global,
persistent, unique identifiers.

Leslie.

-- 

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

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

Date: Mon, 10 Mar 1997 18:23:44 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] semantic representation in URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   You should probably remind people in each posting that you want
   replies to you, if that is what you want.  I'd like to see all the
   raw data somehow, however.

All mail on topic to everyone!  It's just that I'd like us not to try
to work on too many threads at once, so I'm going to try to sequence
the topics a bit.

			Karen

Resent-From: Karen Sollins <[email-masked]>
Resent-Message-Id: <[email-masked]>
Resent-Date: 10 Mar 1997 18:21:03 -0500
Resent-To: [email-masked]
From: Daniel LaLiberte <[email-masked]>
Date: Mon, 10 Mar 1997 16:01:11 -0600 (CST)
To: "Karen R. Sollins" <[email-masked]>
Subject: [URN] semantic representation in URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

You should probably remind people in each posting that you want
replies to you, if that is what you want.  I'd like to see all the
raw data somehow, however.

Karen R. Sollins writes:
 > Thus, a statement that said that no ex post facto ordering choices
 > will be supported would be one to discourage inclusion of some
 > forms of semantic expression.

Yes indeed.  In fact, I am of the opposite mind that we should declare
the structure of URNs, not that all URNs need to use that structure,
in order to support scalable (client directed) resolution.

 > CON (discouraging inclusion of semantics):
 > 
 > 1) Semantics change with time.

There is a big prior question about what "semantics" means.

The semantics of how to subdivide a structured identifier do not need
to change.  Some people might call this mere syntax, but the
distinction is really arbitrary.

The *intended* semantics of how to use the components of the
identifier to resolve the identifier do not need to change even though
the human interpretation of the components may change.  URNs are
resolved by programs which do not have to worry about the changing
meaning of symbols - they're just bits.  But the symbols remain useful
to humans for memory, etc.

 >    If users become dependent on the
 > semantics being correct, resources will need to be issued new URNs
 > when the semantics change and we will have a repeat of all the issues
 > of URLs.

Not necessarily.  See the previous paragraph for one counter argument.
But this CON argument has more to do with the reorganization of the
name space than with the human interpretation of the URNs, I would hope.

Yes, new URNs would be issued for new organizations of names, but we
must already deal with multiple names for things, right?  There will
be multiple URNs for each resource - we cannot stop it.  Consider
legacy names for one.  URNs do not provide a solution for the problem
of having multiple identifiers for a single resource.  That is not
what the uniqueness property of URNs refers to - it refers to the fact
that a single URN will always only be associated with a single
resource.

Does this open the door to "all the issues of URLs"?  Yes and no.
Yes, because this is yet another way in which URNs are not
distinguishable from URLs.  No, because the uniqueness attribute,
which is not necessarily true for URLs would be declared to be true
for URNs.  (The yes and no arguments would seem to be a contradiction,
but there's more... if you want it.)

 > Remember that one form of semantics is location information,
 > and if we allow others, we will have the problems in multiple
 > dimensions.

Could you be more specific about this?  What are these multiple
dimensions?  Are you saying that any kind of semantics ties down the
identifier, as in it locates the identifier in some n-dimensional space?

 > 2) Inclusion of semantics such as in structure may imply more complex
 > information management in the UDS as described in the background
 > example above.

The structure can be optional.  Some parts of the name space need not
use any structure while other parts may use it.

A UDS need not use any structure even if the identifiers it (partly)
resolves have declared structure.  However, the structure allows
clients to talk with other UDSes that *do* use the structure.

 > 3) The hierarchy embodied on URNs reflects namespace delegation.

Delegation is not required, but hierarchy *allows* delegation.

 > To cause that to reflect other semantics as well will be very
 > difficult in the general case.

I don't understand what you are thinking here.  Please explain.

 > 4) A URN scheme is extremely unlikely to reflect all the semantics
 > that might be useful to humans.

And programs.

 > Hence human friendly schemes will be
 > needed on top anyway, and therefore by the end-to-end argument should
 > not be supported at this level as well.

What is the end-to-end argument?

My view on human friendly schemes is that, if people will want to use
them anyway, then we need to make them persistent, etc, just as URNs
would be.  

 > 5) Given the problems with character sets and internationalization,
 > what is the probability of expressing semantics that would be globally
 > meaningful.

Is there really a problem here?  When would I need to refer to a document
in chinese with a chinese URN?

I don't follow character set discussions, but one of the PRO arguments
is that we *need* to use international character sets to make URNs
useful world-wide.  

 > To allow for translation of semantics to be
 > internationally meaningful is certainly not part of a UDS.  Without
 > this, URNs will be meaningful to only part of the customer base at
 > best anyway.

URNs that refer to resources will be as useful as the resources
themselves, so the customer base of the resources that are constrained
to be useful only to them could probably live with similar constraints
on the identifiers.

Alternatively, multiple URNs could be used to identify the same
resource, each one meaningful to different communities.

 > PRO (don't discourage inclusion of semantics or perhaps encourage it):

I'm a devils advocate at heart, so I'll argue against some of the PRO
arguments too.

 > 1) We need to do it for some legacy systems anyway, so why not allow
 > it for all namespaces.

There is always some mapping that will be required to represent legacy
systems in our new identifier scheme, so why not require everyone to
map into numbers?  ASCII chars can be represented by their hex codes,
etc.

 > 2) If we are really suggesting using URNs instead of URLs we need
 > something human friendly now and we don't have anything else.

a. URLs can be made persistent (by similar indirection as UDSes will
provide), so we don't need URNs anyway.  URLs have sufficient human
semantics already.

b. Human friendly identifiers could become the substitute, and then
URNs become like IP numbers compared to human friendly domain names.
IP numbers are mapped to physical machines - the "real" locations.  So
are URNs really names or locations?  Or are the concepts of "name" and
"location" relative to the context in which the identifier is being
resolved?

 > 3) This is a URN issue, not a UDS issue and should not be addressed at
 > all in the UDS requirements documant.

The issue has, truefully, no necessary impact on UDSes.  But it will
encourage UDSes to make use of the semantics/structure just to be
competitive.

 > 4) The ability to support semantics does not mean that everyone has to
 > understand them.  URNs that include semantics might simply be easier
 > to remember or guess for some parts of the population, but it need not
 > imply anything about translation of URNs into other things
 > (e.g. URLs).

Right.  What's wrong with that argument?

dan

Date: Mon, 10 Mar 1997 18:20:23 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] misunderstanding
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

I have already gotten one response, which I will resend to the whole
list.  What I want is a discussion of the questions that I pose on the
whole list.  So, send your comments/responses to the whole list.  It's
only if you think of another topic that you want us to discuss that
I'd like it not to disrupt whatever discussion is already ongoing.
So, if you have a new topic on the subject of URN resolution
requirements that let's take that offline initially and send it to me,
just to avoid disruption.  Otherwise, all mail to everyone!

			Karen

Date: Mon, 10 Mar 1997 15:35:59 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] semantic representation in URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>
Question: should the UDS requirements doc say anything about

encouraging or discouraging semantic expression in URNs?

Background: The URI group in the past argued about this topic
extensively.  This is part of the discussion about the "user
friendliness" of URNs.  RFC 1737 intentionally only goes as far as
"human transcribable" down this path.  This is really a question about
URNs, more than UDS requirements, although one can imagine that some
designs for a UDS might make be more or less encouraging or
discouraging.  For example (and this is only an example!), consider
hierarchical names and the ordering of elements.  In a completely
general UDS that wanted to make semantics more expressible, ordering
within a subspace might be completely determined by the owner of that
subspace.  Clearly, in order to be able to support certain legacy
naming schemes, we need to all for schemes not to be just
left-to-right or right-to-left.  The question is whether there are
schemes that need to allow for determination in the future of the
ordering of subcomponents and whether future naming schemes
(non-legacy) need this or should have this option.  Even in this
simple example the problem is that in order to allow it, for any UDS
scheme that partitions the problem of resolution along the
hierarchical lines, the local decisions about ordering will require
expression of that in order to walk the hierarchy.  Thus, a statement
that said that no ex post facto ordering choices will be supported
would be one to discourage inclusion of some forms of semantic
expression.

The lists of pros and cons below are probably not complete, but I
wanted to give some flavor of the arguments on each side.  Please add
your own and let's get all the issues out on the table.

CON (discouraging inclusion of semantics):

1) Semantics change with time.  If users become dependent on the
semantics being correct, resources will need to be issued new URNs
when the semantics change and we will have a repeat of all the issues
of URLs.  Remember that one form of semantics is location information,
and if we allow others, we will have the problems in multiple
dimensions.

2) Inclusion of semantics such as in structure may imply more complex
information management in the UDS as described in the background
example above.

3) The hierarchy embodied on URNs reflects namespace delegation.  To
cause that to reflect other semantics as well will be very difficult
in the general case.

4) A URN scheme is extremely unlikely to reflect all the semantics
that might be useful to humans.  Hence human friendly schemes will be
needed on top anyway, and therefore by the end-to-end argument should
not be supported at this level as well.

5) Given the problems with character sets and internationalization,
what is the probability of expressing semantics that would be globally
meaningful.  To allow for translation of semantics to be
internationally meaningful is certainly not part of a UDS.  Without
this, URNs will be meaningful to only part of the customer base at
best anyway.

PRO (don't discourage inclusion of semantics or perhaps encourage it):

1) We need to do it for some legacy systems anyway, so why not allow
it for all namespaces.

2) If we are really suggesting using URNs instead of URLs we need
something human friendly now and we don't have anything else.

3) This is a URN issue, not a UDS issue and should not be addressed at
all in the UDS requirements documant.

4) The ability to support semantics does not mean that everyone has to
understand them.  URNs that include semantics might simply be easier
to remember or guess for some parts of the population, but it need not
imply anything about translation of URNs into other things
(e.g. URLs).

Date: Mon, 10 Mar 1997 14:30:34 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] discussion of requirements doc
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

At the last IETF, during the discussion of the requirements document
(draft-ietf-urn-req-frame-00.txt), I put up on a slide a list of
issues that need further discussion, but were to be held for the
mailing list.  The time has now come, so I will be posting questions
at regular intervals.  Obviously, we can't discuss them all at once,
so I will stage them.  This is an attempt to discover where the
consensus lies in the group and where there are still issues that need
further discussion.  Each one will have a different subject field in
order to help people manage the threads.  I will try my best to
provide some background to frame each question.

Also, after re-reading the document, if you have topics that you think
we should discuss, it is probably best to send those directly to me
first ([email-masked]), so that they won't distract the ongoing
discussions.  I will try to make sure that all issues raised get
attention of the whole group.  Obviously, if you think I am
misrepresenting your issue(s), please jump in.

			Karen

Date: Mon, 10 Mar 1997 10:15:45 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
Sender: [email-masked]
Reply-To: Edward Lewis <[email-masked]>

At 7:31 PM -0500 3/7/97, Karen R. Sollins wrote:
>Third, I am still unhappy the treatment of security, both for myself and
...
>DNSSEC will address them has been studied.  I do not think that NAPTR needs
>to be extremely ruggedized with respect to security, but I do think that as

I've been involved in DNSSEC, so when I see it mentioned in a thread, I
wake up and read the document for DNS-type things.

First minor things - on line 598 "DNS_CHAR" is defined.  It is never used,
so I don't know for certain what it is supposed to mean (so maybe it should
be deleted).  If it is the legal, non-escaped chars in DNS, then underscore
("_") should not be there, instead a hypen ("-") should be included as well
as upper case characters.

In the paragrapgh following, "...URI shall be a legal domain name" should
be either:

"...URI MUST be a legal domain name"

or better yet:

"...URI MUST be a legal domain name and SHOULD BE a legal host name"

or perhaps:

"...URI MUST be a legal domain name and MUST BE a legal host name"
                                        ^^^^

There is some confusion over legal domain names and host names, and the
reference to 1123 does not make things clearer.  draft-ietf-dnsind-
clarify-0?.txt is the latest best way to define the binary form of domain
names.  All of the drafts I have seen on defining the ascii/zone-file form
of a domain name have expired.  I haven't followed legal host names as
closely, but I think RFC 1123 is probably the best reference for that.

The distinction is this: a domain name can have non-printable bytes in it
which is legal.  In the zone file, the non-printable bytes must conform to
a specific escape syntax ("\<char>" or "\<three-digits>").  A legal domain
name might not be a legal host name.  (There are length limits for domain
names.)

About the security (the reason I clipped the above mail message),
specifically related to DNSSEC:

DNSSEC will (in a nutshell) let you trust that the NAPTR record received is
what the owner submitted, i.e., no one has substituted a fake record.  (Of
course, DNSSEC will not prevent either bad or malicious data from being
entered, it will just make the insertion of
malicious-data-that-successfully-causes-bad-things harder.)  DNSSEC will
also provide a mechanism for retrieving public keys - if you need that sort
of thing.

DNSSEC does not address denial of service attacks against name servers.

I'm not saying "trust me, DNSSEC will take care of all DNS security issues"
but you probably shouldn't dwell on them too much in the NAPTR document.
(As it is now, IMHO document is fine on security.)  I don't see a security
concern in the document, perhaps you do want to consider security within
the resolver.  I admit to have not read other URN documents...but I'd
venture to say you may want to include a digital signature to authenticate
a URN processed response.  (DNSSEC only helps get you to the URN resolver,
we don't help the URN resolver's security.)  But such a topic is outside
the scope of the NAPTR document.

PS -

One question - has IANA approved the number 35 for NAPTR?  It's not on
their web page (ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters)
yet.  (The page is rather old - dated January 14.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                      Trusted Information Systems
Phone: 301-854-5794               Email: [email-masked]

Date: Sat, 8 Mar 1997 20:56:35 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: "Ron Daniel Jr." <[email-masked]>
Cc: "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 7 Mar 1997, Ron Daniel Jr. wrote:

> Hi Karen,
> 
> >Second, I don't have the Posix regular expression description here (or for
> >that matter anywhere in my office).  I suspect that is true of many people.
> 
> It's more widespread than you might think. Most UNIX machines are POSIX
> compliant now, so they have a regex library and man pages that talk about
> EREs.

POSIX is locale-dependant. It is important to specify exactly
what locale is used, otherwise, you get uncontrolled behaviour.

Also, it's important to say exactly how NAPTR in general and regex
application interacts with several aspects of the syntax. For example,
are NAPTR records stored in %HH-escaped form? DNS can contain 8-bit
data, and the %HH escaping, for octets above 0x80, seems unnecessary.
Are regexps applied to %HH, or to binary octets, or to UTF-8 characters?
(The later would be possible with an UTF-8 posix locale. I don't
propose that this solution is taken, but I want to point out that
there are indeed UTF-8 locales.) Saying that regular expressions
with international characters are impossible to build by hand
seems to imply that at least they work on octets, if not on
%HH. That should at least be made explicit.

In addition, maybe it would pay off to change the formatting
to internet-draft/RFC conventions. At some stage, this has
to be done anyway :-(.

Regards,	Martin.

Date: Sat, 08 Mar 1997 09:15:50 -0500
From: [email-masked] (Jan Hardenbergh)
Organization: Netscape Communications
To: "Ron Daniel Jr." <[email-masked]>
Cc: "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
Sender: [email-masked]
Reply-To: [email-masked] (Jan Hardenbergh)

> >Second, I don't have the Posix regular expression description here (or for
> >that matter anywhere in my office).  I suspect that is true of many people.
> 
> It's more widespread than you might think. Most UNIX machines are POSIX
> compliant now, so they have a regex library and man pages that talk about
> EREs.

UNIX? I thought only networking types used that! Is there a URL?
I like the summary idea, but perhaps, if it is going to be useful,
an information RFC, similar to the utf8 one 2044.

-- 
YON [email-masked] /       "If you spend enough time talking to the 
Jan Hardenbergh  / Martians, everything becomes clear" Tamara Munzner
www.arts.gla.ac.uk/IPA/ipa.html

Date: Sat, 8 Mar 1997 17:51:57 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], Francois Yergeau <[email-masked]>
Subject: Re: [URN] URN syntax v 03
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

I have had a look at the official 03 version of the syntax
draft. Very nice work! I would suggest the following
changes/additions:

- Do something about the formatting of reference [2].

- Fill in the <<your name here!!>> in the Acknowledgements
	section (or do something else about it).

- Add a reference for UTF-8. Without this, there might
	be quite some people that have no clue what is
	meant by this acronym. The reference can be
	either RFC 2044 and/or Unicode Version 2.0,
	Appendix A.2. In the case RFC 2044 is cited,
	the following comment should be included, up to
	the time where RFC 2044 will be upgraded (should
	be really soon):

Note: RFC 2044 specifies UTF-8 in terms of Unicode Version 1.1,
corresponding to ISO 10646 without ammendments. It is widespread
consensus that this should indeed be Unicode Version 2.0,
corresponding to ISO 10646 including ammendment 5.

Regards,	Martin.

Date: Fri, 07 Mar 1997 22:27:13 -0700
To: "Karen R. Sollins" <[email-masked]>, [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Hi Karen,

Thanks for the comments on the NAPTR and THTTP drafts.

>The first is the abstract.

Thanks for the suggested rewording of the NAPTR abstract. It looks like
a reasonable change and I'll put it into -04.

>Second, I don't have the Posix regular expression description here (or for
>that matter anywhere in my office).  I suspect that is true of many people.

It's more widespread than you might think. Most UNIX machines are POSIX
compliant now, so they have a regex library and man pages that talk about
EREs.

>For completeness, is there a way that a summary of it can be provided as an
>appendix?  This would certainly enhance the document's completeness.

Ouch. Well, I'll look at what it will take. I can probably do an appendix,
but no promises just yet. (My POSIX is at the office).

[...]
>the problems of using regular expressions
[...]

If this comes up I think we reiterate the points:
1) The rewrite always applies to the URN, not to the output of a previous
   rewrite, so its not as bad as it might be.
2) Only sites that have to do conditional processing need use regexps. We
   expect most work will be done with simple replacement domain names.
3) This concern is explicitly mentioned in the caveats section as one of
   the reasons we are going for experimental rather than standards-track.
   We can gain experience to see how bad regexps really are.

>Third, I am still unhappy the treatment of security,
[...]
>What we need to do is be quite specific about
>what it will and won't do, and that brief section at the end, just doesn't
>quite do it for me.

Any suggestions for some specific cases you would like to see?

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: Fri, 7 Mar 1997 19:31:09 -0500
To: [email-masked]
From: "Karen R. Sollins" <[email-masked]>
Subject: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Ron, Leslie, et al.,

I think this document is coming along well, but I do still have a few
concerns about it.  My apologies for not getting back to you sooner on
this, but I am only now really getting to the other side of my surgery.
I'll just take them in order.

The first is the abstract.  It reads very nicely, but doesn't quite get
across that the purpose of this document is to present an experimental UDS
(URN-resolution Discovery Service).  I suggest the following minor
modification to the beginning of the second paragraph;

"A UDS (URN-resolution Discovery Service) as laid out in [15] maps URNs to
location information.  This document describes a new, experimental UDS
scheme that provides additional mapping opportunities among URIs.  The
scheme is based on a new DNS Resource Record, NAPTR (Naming Authority
PoinTeR), that provides..."

Second, I don't have the Posix regular expression description here (or for
that matter anywhere in my office).  I suspect that is true of many people.
For completeness, is there a way that a summary of it can be provided as an
appendix?  This would certainly enhance the document's completeness.

(This is an area where I expect the IESG may have some problems, but I'm
not sure how to address them.  I've said this before, but I don't know
whether I've done it in email.  The problem is that the IESG is well aware
of the problems of using regular expressions in a widely distributed
system.  The very negative experience comes from sendmail, in which the
regular expressions were/are much more local.  And, even in that case, it
is extremely difficult to get correct, leaving "the system" extremely
fragile.  In this case, not only must the regular expression be correct,
but in many cases will be dependent on others getting their regular
expressions correct.  I expect there to be significant difficulty both in
getting this sort of thing to be reasonably stably correct and convincing
the IESG of that.  The problem I have here is that I don't know what to
suggest, so mostly I'm expressing a concern.)

Third, I am still unhappy the treatment of security, both for myself and
because it is my understanding that the IESG is becoming more and more
picky about security requirements for documents.  The very brief discussion
at the end does not convince me that that a reasonably complete set of
security threats has been considered here, nor that the question of whether
DNSSEC will address them has been studied.  I do not think that NAPTR needs
to be extremely ruggedized with respect to security, but I do think that as
more and more security problems are made public in the Wall Street Journal,
New York Times and our more local newspapers, it becomes more and more
important for us as the engineers of these more public mechanisms to
understand and make public the dimensions in which and degrees to which our
mechanisms can be trusted.  What we need to do is be quite specific about
what it will and won't do, and that brief section at the end, just doesn't
quite do it for me.

Of course, this is just one person's opinion.  If the consensus of the
group is to move ahead with putting the document as is up to the IESG, then
go ahead and try.

			Karen

Date: Fri, 7 Mar 1997 19:52:31 -0500
To: [email-masked]
From: "Karen R. Sollins" <[email-masked]>
Subject: [URN] the othre internet drafts
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Ryan, Ron, Leslie, et al.,

The other two internet drafts (draft-ietf-urn-syntax-03.txt and
draft-ietf-urn-http-conv-01.txt) both seem fine to me, with one minor
comment on the latter.  In fact, I have no further comments on the syntax.

Perhaps I missed it in the THTTP doc, but otherwise suggest that there
should be a statement somewhere up front that indicates that responses to
such request can in no way be guaranteed to be complete or correct
(although it is in everyone's best interest to do this as much as
possible).  The point is that this protocol makes no statement about the
validity of the responses being sent other than any provisions for
protection of transmitted data.  This is a minor point, but is probably
worth adding to avoid any misunderstandings about correctness or
completeness of the responses.

			Karen

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "'Cecilia Preston'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [URN] IANA gets sued
Date: Wed, 5 Mar 1997 14:52:36 -0500
Sender: [email-masked]
Reply-To: "Phillip M. Hallam-Baker" <[email-masked]>

>"Internet Address Authority Facing Lawsuit" New York Times [National
>edition] March 4, 1997 p.C12

>"A World Wide Web page design company is challenging the Internet's
>tradition of consensus, suing the group that rules on electronic addresses.

Don't get too worried by this. I've read the complaint it alleges that a
verbal undertaking was given, the person alledged to have given the
undertaking denies having done so and the document relied on as IANA
policy in the matter states that it is a proposal to set up a committee to
deliver a proposal. 

Only a fool could have imagined that IANA had granted authority. Some
people prefer to bluster and threaten legal action rather than admit error.
I don't think it will work against IANA and the IAHC people none of whom
are likely to give in to threats.

I suggested to the powers that be that the IODesign suit was to be 
welcomed. Better to face a lawsuit from a minow than from someone 
with deep pockets to buy lawyers. I've not seen the countersuit yet
but I expect it to be a beauty.

	Phill

Date: Wed, 5 Mar 1997 10:39:19 -0800
To: [email-masked]
From: Cecilia Preston <[email-masked]>
Subject: [URN] IANA gets sued
Sender: [email-masked]
Reply-To: Cecilia Preston <[email-masked]>

We knew this was going to happen....

"Internet Address Authority Facing Lawsuit" New York Times [National
edition] March 4, 1997 p.C12

"A World Wide Web page design company is challenging the Internet's
tradition of consensus, suing the group that rules on electronic addresses.
...

In the suit filed last Thursday, Image Online Design said it had been
authorized in July by an authority spokesman, Bill Manning, to register
addresses ending in .web for $25 each.  But Mr. Ambler [of Image Online
Design] said the authority backed out when a plan was announced to change
the current system for assigning Internet addresses by adding seven new
endings, including .web or .store."

--Cecilia

From: [email-masked] (Leslie Daigle)
Date: Tue, 4 Mar 1997 18:38:30 -0500
To: [email-masked]
Subject: [URN] Working Group Last Call -- THTTP
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Further consultation with Ron suggests that the last version of the
"Trivial HTTP Resolution" proposal is also ready for final inspection before
being moved along to "experimental".

As with NAPTR and Syntax -- in 7 days, unless there are major issues
identified, I will ask the A-D to move this along the RFC path.

Cheers!
Leslie.

-- 

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

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

From: [email-masked] (Leslie Daigle)
Date: Tue, 4 Mar 1997 17:57:15 -0500
To: [email-masked]
Subject: [URN] Working Group Last Call: Syntax and NAPTR
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Ron and Ryan tell me that they have finished incorporating such
changes as have been suggested as necessary for the NAPTR and Syntax
drafts.

At this point, I would like to give everyone a chance to make final passes
through the documents before I ask the A-D to move them on their way
to becoming RFCs (experimental for NAPTR, standards-track for Syntax).

If you haven't seen the notices, you can get the latest drafts at:

   NAPTR:

	ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-03.txt

   Syntax:

	ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-03.txt

1 week from now (March 11), if no major flaws have been cited, I will
ask the A-D to advance them.

Thanks!
Leslie.

-- 

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

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-03.txt
Date: Tue, 04 Mar 1997 10:08:53 -0500
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     : URN Syntax                                              
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-syntax-03.txt
       Pages     : 7
       Date      : 03/03/1997

Uniform Resource Names (URNs) are intended to serve as persistent, 
location-independent, resource identifiers. This document sets forward the 
canonical syntax for URNs.  A discussion of both existing legacy and new 
namespaces and requirements for URN presentation and transmission are 
presented.  Finally, there is a discussion of URN equivalence and how to 
determine it.                                                              

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-syntax-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-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-syntax-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-syntax-03.txt

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

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

--OtherAccess--

--NextPart--

From: [email-masked]
Date: Mon, 3 Mar 97 09:51 CST
To: [email-masked]
Cc: [email-masked]
Subject: [URN] URN syntax v 03
Sender: [email-masked]
Reply-To: [email-masked]

Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-03.txt                                        AT&T
Expires in six months                                         March 1997

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-03.tx

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

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers. This document sets
   forward the canonical syntax for URNs.  A discussion of both existing
   legacy and new namespaces and requirements for URN presentation and
   transmission are presented.  Finally, there is a discussion of URN
   equivalence and how to determine it.

1. Introduction

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces (which share the properties of URNs)
   into URN-space. Therefore, the URN syntax provides a means to encode
   character data in a form that can be sent in existing protocols,
   transcribed on most keyboards, etc.

Expires 9/30/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                     March 1997

2. Syntax

   All URNs have the following syntax (phrases enclosed in quotes are
   REQUIRED):

                     <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String (as discussed in [1]).

   RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
   for URN encoding, which have implications as far as limiting syntax.
   On the other hand, the requirement to support existing legacy naming
   systems has the effect of broadening syntax.  Thus, we discuss the
   acceptable syntax for both the Namespace Identifier and the Namespace
   Specific String separately.

2.1 Namespace Identifier Syntax

   The following is the syntax for the Namespace Identifier. To (a) be
   consistent with all potential resolution schemes and (b) not put any
   undue constraints on any potential resolution scheme, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <let-num> [ 1,31<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                     "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                     "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                     "Y" | "Z"

   <lower>       ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                     "y" | "z"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"

   This is slightly more restrictive that what is stated in [4] (which

Expires 9/30/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                     March 1997

   allows the characters "." and "+").  Further, the Namespace
   Identifier is case insensitive, so that "ISBN" and "isbn" refer to
   the same namespace.

   To avoid confusion with the "urn:" identifier, the NID "urn" is
   reserved and MUST NOT be used.

2.2 Namespace Specific String Syntax

   As required by RFC 1737, there is a single canonical representation
   of the NSS portion of an URN.   The format of this single canonical
   form follows:

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "@" | ";" | "$" |
                     "_" | "!" | "*" | "'"

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are not members of the URN
   character set above (<URN chars>).  Such strings MUST be translated
   into canonical NSS format before using them as protocol elements or
   otherwise passing them on to other applications. Translation is done
   by encoding each character outside the URN character set as a
   sequence of one to six octets using UTF-8 encoding, and the encoding
   of each of those octets as "%" followed by two characters from the
   <hex> character set above. The two characters give the hexadecimal
   representation of that octet.

2.3 Reserved characters

   The remaining character set left to be discussed above is the
   reserved character set, which contains various characters reserved
   from normal use.  The reserved character set follows, with a
   discussion on the specifics of why each character is reserved.

   The reserved character set is:

   <reserved>    ::= '%" | "/" | "?" | "#"

Expires 9/30/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                     March 1997

2.3.1 The "%" character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet.  Literal use of the "%" character in a
   namespace must be encoded using "%25" in URNs for that namespace.
   The presence of an "%" character in an URN MUST be followed by two
   characters from the <hex> character set.

   Namespaces MAY designate one or more characters from the URN
   character set as having special meaning for that namespace.  If the
   namespace also uses that character in a literal sense as well, the
   character used in a literal sense MUST be encoded with "%" followed
   by the hexadecimal representation of that octet.  Further, a
   character MUST NOT be "%"-encoded if the character is not a reserved
   character.  Therefore, the process of registering a namespace
   identifier shall include publication of a definition of which
   characters have a special meaning to that namespace.

2.3.2 The other reserved characters

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

2.4 Excluded characters

   The following list is included only for the sake of completeness.
   Any octets/characters on this list are explicitly NOT part of the URN
   character set, and if used in an URN, MUST be %encoded:

   <excluded> ::= octets 1-32 (1-20 hex) | "\" | """ | "&" | "<"
                  | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | "~"
                  | octets 127-255 (7F-FF hex)

   In addition, octet 0 (0 hex) should NEVER be used, in either
   unencoded or %-encoded form.

   An URN ends when an octet/character from the excluded character set
   (<excluded>) is encountered.  The character from the excluded
   character set is NOT part of the URN.

3. Support of existing legacy naming systems and new naming systems

   Any namespace (existing or newly-devised) that is proposed as an
   URN-namespace and fulfills the criteria of URN-namespaces MUST be

Expires 9/30/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                     March 1997

   expressed in this syntax.  If names in these namespaces contain
   characters other than those defined for the URN character set, they
   MUST be translated into canonical form as discussed in section 2.2.

4. URN presentation and transport

   The URN syntax defines the canonical format for URNs and all URN
   transport and interchanges MUST take place in this format. Further,
   all URN-aware applications MUST offer the option of displaying URNs
   in this canonical form to allow for direct transcription (for example
   by cut and paste techniques).  Such applications MAY support display
   of URNs in a more human-friendly form and may use a character set
   that includes characters that aren't permitted in URN syntax as
   defined in this RFC (that is, they may replace %-notation by
   characters in some extended character set in display to humans).

5. Lexical Equivalence in URNs

   For various purposes such as caching, it's often desirable to
   determine if two URNs are the same without resolving them. The
   general purpose means of doing so is by testing for "lexical
   equivalence" as defined below.

   Two URNs are lexically equivalent if they are octet-by-octet equal
   after the following preprocessing:

           1. normalize the case of the leading "urn:" token
           2. normalize the case of the NID
           3. normalizing the case of any %-escaping

   Note that %-escaping MUST NOT be removed.

   Some namespaces may define additional lexical equivalences, such as
   case-insensitivity of the NSS (or parts thereof).  Additional lexical
   equivalences MUST be documented as part of namespace registration,
   MUST always have the effect of eliminating some of the false
   negatives obtained by the procedure above, and MUST NEVER say that
   two URNs are not equivalent if the procedure above says they are
   equivalent.

6. Examples of lexical equivalence

   The following URN comparisons highlight the lexical equivalence
   definitions:

           1- URN:foo:a123,456
           2- urn:foo:a123,456
           3- urn:FOO:a123,456

Expires 9/30/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                     March 1997

           4- urn:foo:A123,456
           5- urn:foo:a123%2C456
           6- URN:FOO:a123%2c456
   URNs 1, 2, and 3 are all lexically equivalent.  URN 4 is not
   lexically equivalent any of the other URNs of the above set.  URNs 5
   and 6 are only lexically equivalent to each other.

7. Functional Equivalence in URNs

   Functional equivalence is determined by practice within a given
   namespace and managed by resolvers for that namespeace. Thus, it is
   beyond the scope of this document.  Namespace registration must
   include guidance on how to determine functional equivalence for that
   namespace, i.e. when two URNs are the identical within a namespace.

8. Security considerations

   This document specifies the syntax for URNs.  While some namespaces
   resolvers may assign special meaning to certain of the characters of
   the Namespace Specific String, any security consideration resulting
   from such assignment are outside the scope of this document.  It is
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

9. Acknowledgments

   Thanks to various members of the URN working group and <<your name
   here!!>> for comments on earlier drafts of this document.  This
   document is partially supported by the National Science Foundation,
   Cooperative Agreement NCR-9218179.

10. References

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

         [1]         K. R. Sollins, "Requirements and a Framework for
                     URN Resolution Systems," Internet Draft (work in
                     progress),  November 1996.

         [2]
          T. Berners-Lee, "Universal Resource Identifiers in WWW," RFC
          1630, June 1994.

         [3]         K. Sollins and L. Masinter,  "Functional Require-
                     ments for Uniform Resource Names," RFC 1737.

Expires 9/30/97                                                 [Page 6]

INTERNET DRAFT                 URN Syntax                     March 1997

                     December 1994.

         [4]         T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
                     Resource Locators (URL)," Internet Draft (work in
                     progress),  December 1996.

11. Editor's address

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

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

Appendix A. Handling of URNs by URL resolvers/browsers.

   The URN syntax has been defined so that URNs can be used in places
   where URLs are expected.  A resolver that conforms to the current URL
   syntax specification [3] will extract a scheme value of "urn:"
   rather than a scheme value of "urn:<nid>".

   An URN MUST be considered an opaque URL by URL resolvers and passed
   (with the "urn:" tag) to an URN resolver for resolution.  The URN
   resolver can either be an external resolver that the URL resolver
   knows of, or it can be functionality built-in to the URL resolver.

   To avoid confusion of users, an URL browser SHOULD display the com-
   plete URN (including the "urn:" tag) to ensure that there is no con-
   fusion between URN namespace identifiers and URL scheme identifiers.

              This Internet Draft expires September 30, 1997.

Expires 9/30/97                                                 [Page 7]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-03.txt
Date: Mon, 03 Mar 1997 09:24:11 -0500
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     : Resolution of Uniform Resource Identifiers using the 
                   Domain Name System                                      
       Author(s) : R. Daniel, M. Mealling
       Filename  : draft-ietf-urn-naptr-03.txt
       Pages     : 14
       Date      : 02/27/1997

Uniform Resource Locators (URLs) are the foundation of the World Wide Web, 
and are a vital Internet technology. However, they have proven to be 
brittle in practice. The basic problem is that URLs typically identify a 
particular path to a file on a particular host. There is no graceful way of
changing the path or host once the URL has been assigned. Neither is there 
a graceful way of replicating the resource located by the URL to achieve 
better network utilization and/or fault tolerance. Uniform Resource Names 
(URNs) have been hypothesized as a adjunct to URLs that would overcome such
problems. URNs and URLs are both instances of a broader class of 
identifiers known as Uniform Resource Identifiers (URIs). 

This document describes a new DNS Resource Record, NAPTR (Naming Authority 
PoinTeR), that provides rules for mapping parts of URIs to domain names. 
By changing the mapping rules, we can change the host that is contacted to 
resolve a URI.  This will allow a more graceful handling of URLs over 
long time periods, and forms the foundation for a new proposal for 
Uniform Resource Names.    

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-naptr-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-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-naptr-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-naptr-03.txt

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

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

--OtherAccess--

--NextPart--