Subject: [URN] You can pick your friends, but you inherit your relatives...
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Date: Fri, 31 Jan 1997 18:11:38 -0500

Okay, a lot of interesting material has been brought up on the subject
of relative URNs, in particular as a case of relative URIs.  Much good
material has been flushed out this week, but it has also been made clear
that there is much left to be understood.  Of the questions that have been
raised (and, indeed, many of the answers that have been given), I believe
that we can't make any more progress on this at this point -- not until
we have more of the base documents on the table and hammered out.  One
of the key things that was missing in many of the informal scenarios
that were discussed is the issue of _assignment_ of URNs -- it hasn't
yet been made clear that assignment will always be easy or immediate, so
the notion of URNs in "working trees and published trees" _may_ not even
be an issue.  Also, some of the examples were based on assumptions that
URNs are encountered _within documents_ and thus relativity was an issue
of referring to the base document that was retrieved (without addressing
the concept of URNs that then get pulled out of documents and kept for
later use -- as Karen put it, escaping its environment in which the relation
was defined.  Or, is the environment of relationship in fact the object to
which the URN is assigned, or some other construct in the namespace?).  These 
are merely things that are not entirely clear until we've finished the basic 
work we set out to do.

As Ron Daniel put it so succinctly earlier in the week:

> My current position is that:
>  1  URNs are one of the two forms of URI.
>  2  URLs are the other form of URI.
>  3  URNs are not URLs although they have a similar syntax. In fact,
>     we purposefully try to align our syntax with that of URLs in order
>     to avoid gratuitous differences. However, we don't adopt all of the
>     URL syntax features until we see how they impact the core purpose of
>     URNs - persistent, location-independent, resource identifiers.
>         (The difference, to me, is that URNs MUST NOT specify any
>          resolution-system specific hints, like protocol, port, host, etc.
>          while URLs typically do specify such things.)
>         (As a side note, the question of whether there really is a
>          difference between URNs and URLs has been beaten to death and has
>          been declared out of bounds for this list. The URN-WG charter
>          assumes there is such a difference, and if there is not then the
>          worst that happens to the world is that our work is moot.)
>  4  In the absence of good arguments to the contrary, unencoded '/' in URNs
>     will end up denoting hierarchy as stated in RFC 1630.
>  5  Since we have only just started seriously discussing relative URNs,
>     we have not reached consensus on the existance or absence of such a
>     good argument.
>  6  Since the URN-WG is chartered to produce a URN Syntax draft, and
>     neither the charter or URN requirements RFC mentions relative URNs, we
>     should not stop the syntax draft while we discuss them.
>  7  Therefore, the syntax draft should leave an escape hatch for relative
>     URNs.
>  8  This is easy to do, we just state that '/' SHOULD (not MUST) be
>     %encoded, leaving the door open for people not to encode it if they
>     think
>       a) they are following the letter and spirit of 1630
>       b) whatever we do decide will be in line with 1630

With regards to the discussion surrounding whether or not '/' should
be encoded today, (specifically Roy Fielding's concerns and Dan Laliberte's
elaboration on the FPI example), I think it's pretty clear that the point
is:

	'/' should be % encoded iff:

		. in the particular namespace, '/' does not necessarily
		  denote hierarchy (or other relative terms)
		. the designers of the namespace have determined that it is
		  not desirable to expose that hierarchy _for_the_purposes_
		  _of_describing_relationships_between_URNs (e.g., if some
		  other hierarchy is desired)

Note that the '/' is intended to denote relativity in the _URN_namespace_, i.e.,
as part of the process of handling URNs.  This _may_ in fact be distinct
from any hierarchy as it is assigned in the underlying namespace.

So, I think we have discussed this to the point where Ryan can move forward
with the syntax document, and urge people to remember their good arguments
and points of view so that we can come back to this thread _after_ we have
moved forward with the namespace definition document, and various 
namespaces.

Cheers!
Leslie.

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

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

From: Leslie Daigle <[email-masked]>
Date: Fri, 31 Jan 1997 17:53:40 -0500
To: [email-masked]
Subject: [URN] Results from questions...
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Thanks to everyone who replied to my request for comments on aligning URN
and URL syntaxes (original message attached below).  As promised, the
replies themselves can (eventually -- a small matter of making material
"go live" in our tree) be found at:

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

Overall, people seemed to feel that URN syntax should be aligned with URI
syntax -- see RFC 1630.   This was part of the overall sentiment that
URNs are URI schemes, and definitely _not_ URL schemes.

There was almost unanimity on the point that URNs should _not_ go through
the URL vetting process, except for one reply which I think had more to do
with the fact that URNs should be _reviewed_ than that they should specifically
be reviewed by the specific procedure developed for vetting URLs.

As for whether or not aligning the syntax would facilitate acceptance of
URNs in application software, responses varied from suggesting that it
_would_ make it easier to the fact that the differences required for
handling URNs would still be sufficiently great that it wouldn't be any
easier for application software to handle URNs just because they had the
same kind of syntax.  

However, no specific ills of aligning syntax have yet been identified.

So, the effort was succesful insofar as it suggests that the group does
not seem to anticipate major problems with the general course we are taking with
the syntax (although there are some specific details to keep track of).

Thanks again to all who answered.

Leslie.

==================

[Original request for comments]

It seems to me that we are at a crossroads with the URN syntax, and we need to 
get some concrete sense of direction quickly.

I'd like to outline the situation below and then ask for everyone to send
feedback to me directly -- and please, do send feedback, if only to let me
know people are still thinking about this :-)

Ryan, our URN syntax document editor, has spent a good deal of time trying
to get URN syntax to line up reasonably well with the existing URL syntax
document (i.e., the de facto "URI" syntax document).

This document is currently under review, and there are efforts afoot to 
determine a review process for vetting new URL schemes. 

As part of the discussion of this (on the [email-masked] mailing list),
the issue of URN conformance with URL syntax has come up.  There are some
specific changes that would (still) have to be made to accomplish this.
While these are not necessarily stressing in terms of syntax, there
are some particular ramifications that need to be considered:

	. If we align the syntaxes wrt reserved characters, etc, will
	  
		URN:<see syntax draft of the day>

	  necessarily imply that URNs are a "scheme" of URLs?

	  If so, then URNs will have to go through the URL vetting process,
	  and potentially the string "URN" will be objected to.

	  Also, will this imply that URNs are equivalent to URLs in terms
	  of semantics?  (There are those that think the are, and those that
	  think they aren't). 

	. Alternatively, can we align the syntaxes and succeed in having

		URN:<see syntax draft of the day>

	  treated as a special case by URL resolvers, (treated as an 
	  opaque URL, as Ryan described it).

These questions have little to do with implementation details -- i.e., 
any of the above can certainly be implemented.  The real questions, to my
way of thinking, lie in:

	. Does lining up the syntaxes increase the likelihood of getting
	  URNs handled sooner rather than later by existing software (i.e.,
	  are the necessary differences in handling going to mean that
	  existing software can't handle them anyway?)

	. What issues will we have to address in terms of 
	  supporting/distinguishing URN/URL semantics?  (E.g., if URNs
	  are supported as URL "schemes",  can we make the distinction
	  between names and addresses).

I have not been successful in trying to make this an even-handed message -- it
is pretty clear that I am concerned that we are heading back into rough
waters regarding "why do we need URNs when we have URLs".  _However_, I 
know there are other people who have seen all of this and think that there
is no real issue at all.

So, please send feedback -- if you think there is an issue here, and why, or
if you think there is no issue here, and why not.  Please send directly
to me -- I will summarize for the list, and make the collected messages
available.  

Thanks,
Leslie.

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

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

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 31 Jan 1997 16:34:21 -0600 (CST)
To: "Martin J. Duerst" <[email-masked]>
Cc: urn-ietf <[email-masked]>, URL mailing list <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Martin J. Duerst writes:
 > For URLs, it's very clear how relative URLs behave. But for URNs,
 > there is an additional step: Resolution from name to location.

There isn't necessarily any additional step.  Names *can* be resolved
"directly" to resources.  Or perhaps you will get a URC or set of URLs
back.  "Directly" is in quotes because there is necessarily some
indirection in the resolution process, but that may not involve
getting a URL.

 > The question now is: is a relative URI supposed to be applied
 > to the name (i.e. before resolution, URN) or the location
 > (i.e. after resolution, URL) of the document.

Given the above, this question doesn't necessarily make sense.  But
more below.

But there is an easy answer to the question of how a relative URI is
resolved relative to a base URN.  The rules for relative URLs
described in RFC 1808 (http://ds.internic.net/rfc/rfc1808.txt) should
work exactly the same for URNs, with possibly one clarification
described below.

 > We definitely cannot and should not assume that names and locations
 > are equally structured.

Correct, we cannot.  But you don't need to worry about that, if you
follow the rules.

RFC 1808 describes a seven step process for constructing the absolute
URL from the relative URL and the context.  We can just substitute URI
(and therefore include URN) wherever it says URL.  The first step of
the seven concerns finding the base URI, which I give here in brief
since that is where the clarification is needed.

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.

So this clarification is an answer to your question above; whether
the relative URI is applied to the name or the location depends on
what the document and server say should be done.

 > > Is it true that the fpi URNs are non-hierarchical, or if they have
 > > hierarchical structure, you don't want to expose it?  (I'd recommend
 > > that the syntax of fpi URNs expose the structure and avoid reserved
 > > chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN)
 > 
 > What does exposing the structure help exactly? A resolver migh
 > very well use the last few digits of the long number for
 > distributed processing because it gives better distribution.

Exposing the hierarchical structure *allows* use of relative URNs, but
even with that structure, you wouldn't have to use relative URNs if
you did not want to.

Moreover, exposing the structure permits more scalable resolution.
Information obtained at intermediate levels can be cached so the
client can use that information in subsequent similar requests rather
than requesting it again.  

As you say, instead of an explicit structuring of the name space
(e.g. using '/' delimiter), an alternative is to use the characters in
the identifier itself.  The handle scheme would have clients hash the
whole id and from that lookup one of several global handle servers.
Either way, we have an essentially random distribution of servers -
but this randomness defeats locality of reference.  Locality of
reference means, in this application, that you (or members of your
local group) are likely to reference related material, so if the
related material is colocated, you can remember the location (or other
metadata) one time and use it again next time.  But if you distribute
randomly, the relationship between the material does not help.
I've written (long ago - rough draft) some more on this scaling issue at:

  http://union.ncsa.uiuc.edu/~liberte/scalability.html

In order of preference we have:
1. No distribution - one server
2. Random distribution
3. Organized distribution

 > > If a relative URI can be used with either an http URL
 > > base or a path URN base, you don't have to change anything but the base.
 > 
 > I don't think that such parallel structures are really useful or
 > important. You expose an awful lot of structure that, for the sake of
 > persistency, you might want to hide.

The flexibility to change name spaces and keep the same substructure
is useful.  If, as a result, you get *more* persistence, not less,
that is important.

 > > Relative URNs *are* likely to save one a significant amount of work *if*
 > > you use a name space that is hierarchical and that supports relative
 > > URNs.
 > 
 > Can you give more details on actual examples where this work is
 > saved?

If you mean examples where I have actually saved work, no I have not
done this yet.  But Ron has described his experience which argues
*against* the value of relative URIs in the case of moving the
document to a *non*-hierarchical name space.

A path URN is hierarchical, and looks just like an http URL except
for the scheme and host part.  The relative URIs in a document can
remain exactly the same when moving to a path URN for the base.
Not changing things saves time, obviously.

dan

Date: Fri, 31 Jan 1997 22:57:54 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: "Ron Daniel Jr." <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, URL mailing list <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 31 Jan 1997, Ron Daniel Jr. wrote:

> Thus spoke Daniel LaLiberte:
> >Ron Daniel, Jr. writes:
> > > The point I was trying to make is that the presence of the relative
> > > URLs is not helping us as we make the transition to URNs.
> >
> >Relative URLs (which are relative URIs intended to be interpreted
> >relative to an absolute URL) would not interfere with a transition
> >to URNs if you keep the same absolute URL base.
> 
> Not always true. If our resolver offers the N2R service, its nice to
> use it because bookmarks will be to the URN, not to a URL. Similarly,
> the Location: text field in netscape will display the URN. However,
> that means that relative URIs will be relative to the URN, not the
> URL of the instance we fetch. Since the hierarchies are not the same,
> it breaks.

The problem that the thing you want to have in the bookmark and the
thing you want to use for relative URL resolving are not the same
was discussed earlier in quite some detail. It might be time to
split these into two. But then again, I'm not at all sure whether
this will lead to a consistent model for relative URNs, or whether
this will contribute to the need for relative URNs.

Regards,	Martin.

Date: Fri, 31 Jan 1997 14:43:27 -0700
To: Daniel LaLiberte <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Cc: URL mailing list <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

At 11:39 AM 1/31/97 -0600, Daniel LaLiberte wrote:
>Ryan Moats writes:
> > Just to make everyting clear, if the client does not understand the
> > namespace, should treat the NSS as an opaque string, yes? (At least,
> > I certainly hope so...)
>
>Nothing else makes sense.
>But maybe such a client should commit suicide. :-)

Whaa???

It seems to me that 1630 and other documents argue just the opposite -
that the semantics of '/', '#', ... are set so that clients can
slice and dice the URIs even if they don't know the scheme or
namespace. More importantly, the same slicing and dicing code can be
used across several known schemes.

>As a general rule, for scalability in a world where clients far
>out-number the servers, the clients or servers near the clients should
>be doing most of the work.

I'll certainly agree with that.

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, 31 Jan 1997 14:19:50 -0700
To: Daniel LaLiberte <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Cc: "URL mailing list" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Daniel LaLiberte:
>Ron Daniel, Jr. writes:
> > The point I was trying to make is that the presence of the relative
> > URLs is not helping us as we make the transition to URNs.
>
>Relative URLs (which are relative URIs intended to be interpreted
>relative to an absolute URL) would not interfere with a transition
>to URNs if you keep the same absolute URL base.

Not always true. If our resolver offers the N2R service, its nice to
use it because bookmarks will be to the URN, not to a URL. Similarly,
the Location: text field in netscape will display the URN. However,
that means that relative URIs will be relative to the URN, not the
URL of the instance we fetch. Since the hierarchies are not the same,
it breaks.

> > For example, the document at
> >   http://www.acl.lanl.gov/URN/index.html
> > might get a FPI of
> >   -//LANL ACL//199703014039//EN
> > which results in the URN
> >   urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN
>
>Is it true that the fpi URNs are non-hierarchical, or if they have
>hierarchical structure, you don't want to expose it?  (I'd recommend
>that the syntax of fpi URNs expose the structure and avoid reserved
>chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN)

FPIs do have a hierarchical structure, and I have no strong feelings
either way about exposing it. What I do care about is a reasonable
approach to granfathering old namespaces. About the only objective
criteria I know of for determining if a mapping from a legacy name
to a URN is reasonable is to see if it is invertible. I can't recover
the original FPI from your sample encoding of it because your '/'
character could map to space, //, or nothing at all (where you put
them into 1997/03/01/4039). (They could also map to :: in some FPIs).
Being able to map to the original identifier is important since it allows
us to add a URN resolution gateway on top of existing databases.

Putting that problem aside, lets assume that I can use
  urn:fpi:/LANL/ACL/1997/03/01/4039/EN
to refer to the document currently known as
  http://www.acl.lanl.gov/URN/index.html
which has a relative reference to
  HREF="software.html"
Since we are using N2R in order to get bookmarks to use the persistent name
for a resource, Netscape would try to fetch new URNs that look like
   urn:fpi:/LANL/ACL/1997/03/01/4039/software.html

This is the crucial problem with relative URNs. There are LOTs of
different hierarchies into which a document can reasonably be placed.
Relative URNs will persist across namespace transitions if we keep
the same hierarchy. If we want to change the hierarchy, the relative
references will no longer work. The scary thing about relative URNs
is that if you access the document using someone else's name for it,
your relative links will break (unless you have used something like
the BASE tag, but then we are back to editing the documents to move
to a new namespace).

>Relative URNs *are* likely to save one a significant amount of work *if*
>you use a name space that is hierarchical and that supports relative
>URNs.

... *and* if your next namespace uses the same hierarchy as the earlier
namespace. (In which case, why are you switching?)

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, 31 Jan 1997 12:25:14 -0700
To: "Gregory J. Woodhouse" <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Cc: Daniel LaLiberte <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Gregory J. Woodhouse:
>If there are
>no relative URNs, many (most?) people will not use URNs because they will
>be unable to develop web sites off-line (meaning off the production server,
>not disconnected).

I don't think that is quite true. Since the URN doesn't contain
resolution system info, they get resolved through the use of a
database that can map the URN to a URL, set of URLs, metadata,
or the resource itself. People using URNs to refer to a connected
set of resources will do their testing by having a set of URLs in
the resolver database that point to the test environment. Once
they are ready to go, they change those URLs to the production
machine.

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  

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 31 Jan 1997 13:12:39 -0600 (CST)
To: "Martin J. Duerst" <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, [email-masked], "Ron Daniel Jr." <[email-masked]>, omar syed <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: [URN] Proxies and extensible clients
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Martin J. Duerst writes:
 > Not necessarily. With the number of URL schemes and URN namespaces
 > increasing, as well as the complexity of other things the client has
 > to do, it might be a very good implementation strategy to delegate
 > all the URL/URN resolution stuff to a *local* server (proxy).

Yes, yes!  I was going too far.  

By "client", I sometimes metaphorically mean things in the
neighborhood of the client which act as sort of extensions of the
client.  A local proxy or Java applet that understands a scheme works
just as well as, if not better than, explicitly cramming the hardcoded
understanding of all schemes into one client.

In fact, I am very interested in how a Java applet API can be done to
avoid the security concerns (accessing arbitrary new servers).  The
main problem with new URI schemes is deploying them to millions of
clients.  Even proxies would have to be educated, so auto-downloadable
code that understands new URI schemes and associated protocols would
grease the rails on the bridge to the future.

dan

Date: Fri, 31 Jan 1997 20:02:09 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, URL mailing list <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

> Relative URLs (which are relative URIs intended to be interpreted
> relative to an absolute URL)

This reminds me of an implicit problem here with URNs that I haven't
seen answered:

For URLs, it's very clear how relative URLs behave. But for URNs,
there is an additional step: Resolution from name to location.
The question now is: is a relative URI supposed to be applied
to the name (i.e. before resolution, URN) or the location
(i.e. after resolution, URL) of the document. We definitely
cannot and should not assume that names and locations are
equally structured.
The later alternative would help for things such as coordinating
between development and production version (there would be URNs
for the "entry points" of the production version, but the rest
would all be relative URLs).
The former alternative seems to be implied by all those that
see the need for hierarchical URN namespaces.
I don't see how we could have both unless we introduce additional
syntax (e.g. \ for URN hierarchy and / for URL hierarchy, or
maybe something with /// and //).
Daniel, maybe you can tell me which one you have in mind?

>  > The URNs
>  > we are assigning are very different from the URLs we currently use.
>  > For example, the document at
>  >   http://www.acl.lanl.gov/URN/index.html
>  > might get a FPI of
>  >   -//LANL ACL//199703014039//EN
>  > which results in the URN
>  >   urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN
> 
> Is it true that the fpi URNs are non-hierarchical, or if they have
> hierarchical structure, you don't want to expose it?  (I'd recommend
> that the syntax of fpi URNs expose the structure and avoid reserved
> chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN)

What does exposing the structure help exactly? A resolver migh
very well use the last few digits of the long number for
distributed processing because it gives better distribution.

>  > Relative URNs only save you work if the next
>  > namespace you use is very similar to the one you currently use.
>  > If they are not similar, then you have to edit the documents, just
>  > as you would have to do if you had used absolute identifiers.
> 
> Or, another way of looking at it is that (absolute) URNs only save you
> work if the structure of the name space is similar to the one you
> currently use.  If a relative URI can be used with either an http URL
> base or a path URN base, you don't have to change anything but the base.

I don't think that such parallel structures are really useful or
important. You expose an awful lot of structure that, for the sake of
persistency, you might want to hide.

>  > This is not a damning indictment of relative URNs, it just points out
>  > that they are unlikely to save one a significant amount of work.
> 
> Relative URNs *are* likely to save one a significant amount of work *if*
> you use a name space that is hierarchical and that supports relative
> URNs.

Can you give more details on actual examples where this work is
saved?

Not that I am absolutely against relative URNs, as some of my
mail may have suggested. But I just try to figure things out,
and for some of the things, I don't have an answer yet.

Regards,	Martin.

Date: Fri, 31 Jan 1997 14:01:42 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Reltive URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Yes, URNs are intended not only to be persistent, but also to be
global.  Furthermore, the closest we got in the URN requirements to
humans was to say that they be "human transcribable".  We
intentionally did not go further into the realm of human friendliness.
Relative and global are contradictory in my model of this world,
unless someone can _guarantee_ that a relative URN would NEVER escape
the environment within which it is relative without being converted to
its global representation.  But, if that's the case, it doesn't belong
in a standard anyway; it's a private convention, and people can do
anything they want in private, as long as it doesn't affect the
outside world.

So, this whole discussion about "relative" URNs leaves me very puzzled.

			Karen

Date: Fri, 31 Jan 1997 12:39:32 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Gregory J. Woodhouse" <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, Daniel LaLiberte <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Gregory J. Woodhouse wrote:
> 
> I always use relative URLs for my internal links. One reason I do this is
> so that I can maintain a copy of my site (or part thereof) on my
> workstation for development purposes and then upload it to the server. If
> URNs can only be absolute, then this methodology doesn't work. If there are
> no relative URNs, many (most?) people will not use URNs because they will
> be unable to develop web sites off-line (meaning off the production server,
> not disconnected).
> 

While I agree that developing web-sites on development machines becomes
easier with relative URIs, I don't buy that not having them makes it
impossible, just more difficult.

Ryan

Date: Fri, 31 Jan 1997 19:32:11 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: [email-masked], "Ron Daniel Jr." <[email-masked]>, omar syed <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

> Ryan Moats writes:
>  > Just to make everyting clear, if the client does not understand the
>  > namespace, should treat the NSS as an opaque string, yes? (At least,
>  > I certainly hope so...)
> 
> Nothing else makes sense.
> But maybe such a client should commit suicide. :-)

Not necessarily. With the number of URL schemes and URN namespaces
increasing, as well as the complexity of other things the client has
to do, it might be a very good implementation strategy to delegate
all the URL/URN resolution stuff to a *local* server (proxy).

Regards,	Martin.

Date: Fri, 31 Jan 1997 19:17:46 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, omar syed <[email-masked]>, URL mailing list <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

>  > Thus spoke Omar Syed:
>  > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
>  > 
> Ron Daniel, Jr. writes:
>  > I think assumption 2 is in error. Clients that know the structure of
>  > a name in a particular namespace are likely to manipulate it.
> 
> I agree.  Clients, of course, can do whatever they want (whatever they
> can get away with) anyway, but they have to be able to interpret the
> structure of an identifier in order to do as much processing of it on
> their own as they can.  Forcing clients (if that were possible) to
> always consult a remote server to process the whole identifier is a
> sure way to make the system unscalable.

Forcing to consult a *remote* server is a bad thing. On the other
hand, if we would require that a client *has to* understand anything
about the structure of certain URNs, that might also be too much
of a limitation.

> Ron Daniel, Jr. writes:
>  > This is the sort of problem I am running into now in our tests, where
>  > we have a bunch of HTML pages we are retroactively assigning URNs to.
>  > Since those pages have lots of relative links in them, we can either:
>  >   1) Make sure our new URNs reflect the same filesystem arrangement
>  >      as the pages do.
>  >   2) Modify the pages to make all the references absolute.
>  > Alternative 1 certainly is unattractive, since a major point of URNs is
>  > to provide independence from the filesystem organization du jour.
> 
> First, identifiers (relative or not) may *reflect* a filesystem
> structure, but it is up to the server whether to look up an identifier
> in a filesystem, database, or pass it to a CGI program, for
> example.  So it is incorrect to assume filesystems specifically.

For what Ron is saying, the fact that it is the *filesystem* structure
is irrelevant. It could be any hierarchy. The main point is that
if you want to keep relative addressing and change the base, then
you have to keep the structure. This is a good thing with relative
URLs, because currently they mainly point to filesystems and
coordinated relocation of directory subtrees is an operation well
supported for filesystems. It's an operation that is much less
supported/common, and much less important, for other kinds of
things, for example for rote numberings and for conceptual hierarchies
(two of the things various people think URNs might be used for).

> But going beyond that, the identier may reflect a hierarchical
> structure (filesystem or not) and if you want that structure to be
> persistent, you have to arrange that old identifiers are redirected
> to the new identifiers, and the old identifiers are not reused for
> other purposes.

As far as I know, we mainly want the identifiers to be persistent.
Then if a bunch of identifiers stay persistent, their structure
will stay persistent (with the same sense of persistency as the
identifiers themselves).
For URNs (in contrast to URLs), keeping the structure when
moving from one namespace to another (or one part of a
hierarchy to another if there is a hierarchy) seems not to
be that important. In particular, for namespaces, the reason
to make a new namespace might very clearly be that you want
to have another structure. If you need the same structure,
you can always use the old names. For example, if you
take ISBN. It has structure: country/publisher/book/error code.
Now take Library of Congress numbers. If they had been happy
with the structure of ISBNs, they would have used ISBNs
(well, maybe historically, they were first).

Some more general thoughts:

One important question is whether one sees the world as primarily
hierarchical or not. File systems and the military are primarily
hierarchical, other systems are less so. Tim said in an earlier
message that throwing away the special meaning of "/" would mean
loosing generality. But this is only so if one sees the hierarchy
as the general case, and the non-hierarchical case as a one-level
hierarchy. From another viewpoint, everything is opaque, and the
hierarchical structure is just an internal affair.

Daniel, in other mails you have made references to efficiency
problems that can be alleviated by hierarchy. However, even
if an URN is completely opaque, there is no reason to have
efficiency problems. For example, the client could ask a
resolver close to it to help out, and this could go ask
another resolver if it can't deal with it. If you have
to split the load for a huge namespace, you can as well
split it on semantically meaningful boundaries as you
can split it on arbitrary boundaries (e.g. take the
two first letters of the string to decide which next
resolver to contact. For an example, in DNS currently
zones are related to ".". This creates big problems
because the .com-domain is too big. If we had a mechanism
to split such domains (I guess work is going on on such
things), then one of the obvious things would be to
split them on the last or the last two letters of the
label before .com.

Another idea is that something such as Java Applets are
part of a resolution scheme. For example, on a request for
an URN resolution, a browser recieves a (reference to) a
piece of code that it uses according to certain conventions.
Such an applet could for example do such things as say
"Hey, I know this namespace, and I know it has certain
conventions for hierarchies, and these hierarchies in
that case actually are connected to the way these things
are resolved, and I just helped resolve an URN
	aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^xyz
which is very similar to what I have to help resolve now, namely
	aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^pqr
so let's use (most of) the result of what I got for the
previous resolution.

Just some ideas.

Regards,	Martin.

Date: Fri, 31 Jan 1997 10:00:49 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: "Ron Daniel Jr." <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

I always use relative URLs for my internal links. One reason I do this is
so that I can maintain a copy of my site (or part thereof) on my
workstation for development purposes and then upload it to the server. If
URNs can only be absolute, then this methodology doesn't work. If there are
no relative URNs, many (most?) people will not use URNs because they will
be unable to develop web sites off-line (meaning off the production server,
not disconnected).

---
[email-masked]    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
to come up with a better one.

Date: Fri, 31 Jan 1997 10:05:10 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: [email-masked], "Ron Daniel Jr." <[email-masked]>, omar syed <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

> 
> As a general rule, for scalability in a world where clients far
> out-number the servers, the clients or servers near the clients should
> be doing most of the work.
> 
> dan
> 

Excellent point.

---
[email-masked]    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
to come up with a better one.

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 31 Jan 1997 11:59:36 -0600 (CST)
To: "Ron Daniel Jr." <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, "URL mailing list" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > The point I was trying to make is that the presence of the relative
 > URLs is not helping us as we make the transition to URNs.

Relative URLs (which are relative URIs intended to be interpreted
relative to an absolute URL) would not interfere with a transition
to URNs if you keep the same absolute URL base.  But if you want
each and every one of your documents to have a URN, and you can't use
relative URNs then you have to use absolute URNs.  That much is clear.

 > The URNs
 > we are assigning are very different from the URLs we currently use.
 > For example, the document at
 >   http://www.acl.lanl.gov/URN/index.html
 > might get a FPI of
 >   -//LANL ACL//199703014039//EN
 > which results in the URN
 >   urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN

Is it true that the fpi URNs are non-hierarchical, or if they have
hierarchical structure, you don't want to expose it?  (I'd recommend
that the syntax of fpi URNs expose the structure and avoid reserved
chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN)

 > Relative URNs only save you work if the next
 > namespace you use is very similar to the one you currently use.
 > If they are not similar, then you have to edit the documents, just
 > as you would have to do if you had used absolute identifiers.

Or, another way of looking at it is that (absolute) URNs only save you
work if the structure of the name space is similar to the one you
currently use.  If a relative URI can be used with either an http URL
base or a path URN base, you don't have to change anything but the base.

 > This is not a damning indictment of relative URNs, it just points out
 > that they are unlikely to save one a significant amount of work.

Relative URNs *are* likely to save one a significant amount of work *if*
you use a name space that is hierarchical and that supports relative
URNs.

dan

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 31 Jan 1997 11:39:55 -0600 (CST)
To: [email-masked]
Cc: Daniel LaLiberte <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, omar syed <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ryan Moats writes:
 > Just to make everyting clear, if the client does not understand the
 > namespace, should treat the NSS as an opaque string, yes? (At least,
 > I certainly hope so...)

Nothing else makes sense.
But maybe such a client should commit suicide. :-)

As a general rule, for scalability in a world where clients far
out-number the servers, the clients or servers near the clients should
be doing most of the work.

dan

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 31 Jan 1997 11:28:42 -0600 (CST)
To: "Ron Daniel Jr." <[email-masked]>
Cc: "Ryan Moats" <[email-masked]>, <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] URI and URN syntax
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > My current position on this is that we should follow 1630 where it claims
 > to speak for all URI schemes. This means we should put  % / # and ? into
 > the set of reserved characters for all URN namespaces. I think the
 > direction on = ; * and ! is less clear so I can go either way on those
 > characters.

I agree that we should follow rfc 1630, and push for clarifications
there if needed.  In fact, why not simply inherit that spec rather
than copy it into the URN syntax spec?  If a URN is-a URI (it better
be!), then URNs must inherit the URI constraints, although URNs can be
more constrained.

Tim B-L recently mentioned on the URI list that relative URIs may
contain ";name=value;name=value" pairs in his original plans, but I
don't know that this is actually followed in any practice, but the
characters are still reserved unless explicitly unreserved.  Instead,
we see "?name=value&name=value" used for a similar purpose, but the
structure after the '?' is merely a convention.

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

Date: Fri, 31 Jan 1997 10:32:19 -0700
To: Daniel LaLiberte <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Cc: "URL mailing list" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Daniel LaLiberte:
>Ron Daniel, Jr. writes:
> > This is the sort of problem I am running into now in our tests, where
> > we have a bunch of HTML pages we are retroactively assigning URNs to.

>First, identifiers (relative or not) may *reflect* a filesystem
>structure, but it is up to the server whether to look up an identifier
>in a filesystem, database, or pass it to a CGI program, for
>example.  So it is incorrect to assume filesystems specifically.

The point I was trying to make is that the presence of the relative
URLs is not helping us as we make the transition to URNs. The URNs
we are assigning are very different from the URLs we currently use.
For example, the document at
  http://www.acl.lanl.gov/URN/index.html
might get a FPI of
  -//LANL ACL//199703014039//EN
which results in the URN
  urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN

Relative URNs only save you work if the next
namespace you use is very similar to the one you currently use.
If they are not similar, then you have to edit the documents, just
as you would have to do if you had used absolute identifiers.

This is not a damning indictment of relative URNs, it just points out
that they are unlikely to save one a significant amount of work.

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, 31 Jan 1997 11:30:22 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Daniel LaLiberte <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, omar syed <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Daniel LaLiberte wrote:
> 
>  > Thus spoke Omar Syed:
>  > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
>  >
> Ron Daniel, Jr. writes:
>  > I think assumption 2 is in error. Clients that know the structure of
>  > a name in a particular namespace are likely to manipulate it.
> 
> I agree.  Clients, of course, can do whatever they want (whatever they
> can get away with) anyway, but they have to be able to interpret the
> structure of an identifier in order to do as much processing of it on
> their own as they can.  Forcing clients (if that were possible) to
> always consult a remote server to process the whole identifier is a
> sure way to make the system unscalable.

Just to make everyting clear, if the client does not understand the
namespace, should treat the NSS as an opaque string, yes? (At least,
I certainly hope so...)

Ryan

Date: Fri, 31 Jan 1997 08:59:55 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

>2.  While I don't mind adding "#" to the reserved list (unless somebody
screams), it does bring to mind creeping "featuritis".  Do we want to
reserve "?" as well?  How much of the "special" meaning URL characters
do we want to use for the same meaning? (I don't have a position yet,
I'm just trying to take the pulse of the mailing list...)  

I believe the XML folks are finding the URL # and ? features
rather restrictive.  They want to use TEI's extended pointer
syntax for XML linking, and are creeping up on the point where
they'll have to say how it can be represented in URLs.  It's
not clear yet that it can be, completely.  

So it may be that for complex queries (and requests that are
meant to retrieve only part of an object) a more flexible
approach will be to send a UR* plus some additional information.
(I have no suggestion yet about how to do this.)  We should
not assume that # and ? are sufficient to fulfill all needs.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 31 Jan 1997 10:56:39 -0600 (CST)
To: "Ron Daniel Jr." <[email-masked]>
Cc: "omar syed" <[email-masked]>, "URL mailing list" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > I think assumption 2 is in error. Clients that know the structure of
 > a name in a particular namespace are likely to manipulate it.

I agree.  Clients, of course, can do whatever they want (whatever they
can get away with) anyway, but they have to be able to interpret the
structure of an identifier in order to do as much processing of it on
their own as they can.  Forcing clients (if that were possible) to
always consult a remote server to process the whole identifier is a
sure way to make the system unscalable.

Ron Daniel, Jr. writes:
 > This is the sort of problem I am running into now in our tests, where
 > we have a bunch of HTML pages we are retroactively assigning URNs to.
 > Since those pages have lots of relative links in them, we can either:
 >   1) Make sure our new URNs reflect the same filesystem arrangement
 >      as the pages do.
 >   2) Modify the pages to make all the references absolute.
 > Alternative 1 certainly is unattractive, since a major point of URNs is
 > to provide independence from the filesystem organization du jour.

First, identifiers (relative or not) may *reflect* a filesystem
structure, but it is up to the server whether to look up an identifier
in a filesystem, database, or pass it to a CGI program, for
example.  So it is incorrect to assume filesystems specifically.

But going beyond that, the identier may reflect a hierarchical
structure (filesystem or not) and if you want that structure to be
persistent, you have to arrange that old identifiers are redirected
to the new identifiers, and the old identifiers are not reused for
other purposes.

Redirecting is supported by NCSA httpd, and I assume many other servers.
Instead of sending a redirection back to the client, the server could
handle it itself, especially if the new place is within the same server.

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

From: "Ron Daniel Jr." <[email-masked]>
To: "Ryan Moats" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Date: Fri, 31 Jan 1997 08:46:04 -0700
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Ryan Moats:

> 2.  While I don't mind adding "#" to the reserved list (unless somebody
> screams), it does bring to mind creeping "featuritis".  Do we want to
> reserve "?" as well?  How much of the "special" meaning URL characters
> do we want to use for the same meaning? (I don't have a position yet,
> I'm just trying to take the pulse of the mailing list...)

RFC 1630 is not totally consistent on this. The prose reserves the
four characters %, /, #, and ? for purposes it describes and that we
are all familiar with. The prose also says that * and ! "are reserved for
use as having special signifiance [sic] within specific schemes". I'm not
sure what that means.

The BNF says that the reserved characters are = ; # ? : and space.
However, literal occurances of space are not reserved, they are
forbidden. Similarly, only the first occurance of : has a reserved
meaning. The RFC defines the use of ; and = in some specific URL
schemes but makes no overall statement on their use.

My current position on this is that we should follow 1630 where it claims
to speak for all URI schemes. This means we should put  % / # and ? into
the set of reserved characters for all URN namespaces. I think the
direction on = ; * and ! is less clear so I can go either way on those
characters.

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, 31 Jan 1997 08:27:10 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Martin J. Duerst" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Martin J. Duerst wrote:
> 
> On Thu, 30 Jan 1997, Ryan Moats wrote:
> 
> > Mainly, I am thinking of creating a "reserved" set, that
> > contains "%" and "/".  The reason's for "%" being reserved are well
> > known, and that text would be moved to that section.
> >
> > For "/", Ron and I worked out the following proposed text:
> >
> > ...
> > "/" is RESERVED for future developments.  It might be used for
> > denoting hierarchy to allow for relative URN processing, but the WG
> > has not yet reached consensus on this, so such developments will be
> > documented separately.  In the interim, namespace developers SHOULD NOT
> > use an unecoded "/", but rather use %-encoding for "/" ("%2F").
> > ...
> 
> That should be a MUST, of course. And if we are at it, why not
> also put "#" into the reserved set?

Two things:

1.  Martin, I've read your mail to the list.  I assume that you no
longer are worried about the "SHOULD" above.  It was chosen on purpose
after some thought.

2.  While I don't mind adding "#" to the reserved list (unless somebody
screams), it does bring to mind creeping "featuritis".  Do we want to
reserve "?" as well?  How much of the "special" meaning URL characters
do we want to use for the same meaning? (I don't have a position yet,
I'm just trying to take the pulse of the mailing list...)

3.  At this point, I'll hold off the next pre-release of the draft
until point 2 gets a bit more clear (however I am putting place holders
in
this morning...)

Ryan

Date: Thu, 30 Jan 1997 20:19:51 -0500
From: omar syed <[email-masked]>
Organization: NASA Lewis Research Center
To: "Ron Daniel Jr." <[email-masked]>
Cc: Keith Moore <[email-masked]>, Tim Berners-Lee <[email-masked]>, Daniel LaLiberte <[email-masked]>, "Martin J. Duerst" <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: omar syed <[email-masked]>

Ron Daniel Jr. wrote:
> 
> Thus spoke Keith Moore:
> 
> > If we disallow unencoded '/' within URNs for now, we can always add
> > relative URNs later when we understand them better.
> 
> I couldn't agree more.
> 
> Encoding '/' is a bit cumbersome, but it is worth it for the potential
> gain in the future.

Hello members of IETF URN WG,

I have recently joined this mailing list.  But, I have had
an interest in URNs ever since I learned about the
Web and found that URLs are not persistent (around 1993).
I have read the related RFC's and scanned through the
old mailing list archives.

I just wanted to ask some questions and bring up some concerns 
about relative URNs (since that is a hot topic right now).
Maybe the WG has already addressed them.  If so, please
enlighten me.

The rest of what I say is predicated on the following:

1. urn:<NID>:<NSS>
2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
3. the details of interpereting a <NSS> are know only to
   coresponding <NID> resolvers
4. clients must use appropriate resolvers to map the <NSS> to 
   a location or resource

Now then, assume we have a resource r1 and a resource r2.

Lets say that a reference to resource r1 is:
  urn:nid1:A:B:Res1

Lets say that a reference to resource r2 is:
  urn:nid1:A:B:Res2

Lets also assume that resource r1 contains a relative reference to r2.
Maybe something like <a href="Res2">.

Now for the questions:

If the client, after retreiving resource r1, wishes to get 
the resource identified by "Res2", how does it proceed?

It can identify that this reference does not specify a 
scheme, so it should use the same scheme it used to get
the current resource.  But the client is not allowed to
interperet the <NSS> so it cannot replace the "Res1"
from the previous absolute URN with "Res2" to create a new
URN.  The best it can do (I think) is pass both the previous 
absolute URN and the current relative URN to the top level 
resolver of the nid1 name space.  Is this how a client is
supposed to proceed?  If so, then a delimiter is needed
to seperate the absolute URN from the releative URN when
the client passes this info to the resolver.  Is '/'
being reserved for this purpose?  Maybe something like:
  urn:<NID>:<NSS>/<relative URN>

Now for the serious concerns:

Lets say that another valid reference for resouce r1 is:
  urn:nid2:X:Y:resource1

Suppose a client uses this absolute URN to get r1 and then
comes across the relative URN: "Res2".

The first concern is that the client won't even know that
the author of resource r1 had intended the relative URN
to be retrieved using the "urn:nid1" scheme.  Is there a
way for an author to specify the intended scheme along
with the relative URN?  Using "urn:nid1:Res2" should with
the current interpertation cause the client to treat it
as an absolute URN.  Will the '/' (or other reserved character)
be used to indicate a relative URN.  Maybe something like:
  urn:nid1:/Res2.

Also will authors have to maintain multiple relative URN
references (for each <NID> that can be used to reference it)?  
For example:
  <a href="urn:nid1:/Res2" href="urn:nid2:/resource2">
Will HTML specs be modified to allow this?

Assuming the relative URN in resource r1 reads 
<a href="urn:nid1:/Res2">, but the absolute URN:
  urn:nid2:X:Y:resource1
was used to retreive r1.  Can the client now use something
like:
  urn:nid2:X:Y:resource1/urn:nid1:/Res2
to attempt to get r2. The nid2 resolvers would have to determine 
the nid1 equivalent of urn:nid2:X:Y:resource1 and could then
tell the client to try:
  urn:nid1:A:B:Res1/urn:nid1:/Res2
If such a cross name space mapping could be done, it may
eliminate the need for authors to maintain multiple
relative URNs.  But is it possible?

Finally, the most serious concern:

It is quite possible for there to be multiple ways
to reach a reference even within the same name space.
For example:
  urn:nid1:A:B:Res1
and
  urn:nid1:A:res1
may both be valid.  However, the URN:
  urn:nid1:A:Res2
may not be defined.  So a client could request the URN:
  urn:nid1:A:res1/urn:nid1:/Res2
How would the resolver know to remap 'A:res1' to 'A:B:Res1'
since the first is already a valid reference in its name space.

My personal take on this is: I would like to have the URN specs
allow for relative URNs, but the details of how they will
actually be implamented in practice boggles my mind.

That's it.  Sorry it got to be so long.  Please excuse my
grammer and spelling; I was in a hurry to write down my thoughts.
Im sorry if this stuff is "text book" matarial for the
URN WG, but I asked anyhow so that I may be better able to
participate in the future.  Thanks for reading and any
answers you can provide.

Omar Syed

Date: Fri, 31 Jan 1997 14:25:39 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 30 Jan 1997, Roy T. Fielding wrote:

> > Thus spoke Keith Moore:
> > 
> >> If we disallow unencoded '/' within URNs for now, we can always add 
> >> relative URNs later when we understand them better.
> 
> I couldn't disagree more.
> 
> If '/' is disallowed in URNs, then a conforming parser will reject
> a URN containing '/'.  That means you will never be able to introduce
> relative URNs.  Creating barriers to technology just because it isn't
> understood is a mistake, particularly when the only time '/' is
> meaningful for *any* URI is when it is used as a base for parsing
> relative URIs.
> 
> If you aren't using relative forms, then there is no reason to encode '/'.
> If you are, then you don't want '/' encoded.  There does not exist a
> situation in which it is beneficial to disallow '/' in URNs.

There might not be any disagreement. Keith wants '/' disallowed
within actually existing URNs. The parser can (and should, in this
case) be more open. "SHOULD" is the best way to say it (contrary
to my message a few minutes ago, where I didn't see that "SHOULD"
was on puprose).

Regards,	Martin.

Date: Fri, 31 Jan 1997 14:10:44 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 30 Jan 1997, Ryan Moats wrote:

> Mainly, I am thinking of creating a "reserved" set, that
> contains "%" and "/".  The reason's for "%" being reserved are well
> known, and that text would be moved to that section.
> 
> For "/", Ron and I worked out the following proposed text:
> 
> ...
> "/" is RESERVED for future developments.  It might be used for
> denoting hierarchy to allow for relative URN processing, but the WG
> has not yet reached consensus on this, so such developments will be
> documented separately.  In the interim, namespace developers SHOULD NOT
> use an unecoded "/", but rather use %-encoding for "/" ("%2F").
> ...

That should be a MUST, of course. And if we are at it, why not
also put "#" into the reserved set?

Regards,	Martin.

From: "Ron Daniel Jr." <[email-masked]>
To: "omar syed" <[email-masked]>
Cc: "URL mailing list" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Date: Thu, 30 Jan 1997 23:43:33 -0700
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Omar Syed:

> The rest of what I say is predicated on the following:
> 
> 1. urn:<NID>:<NSS>
> 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
> 3. the details of interpereting a <NSS> are know only to
>    coresponding <NID> resolvers
> 4. clients must use appropriate resolvers to map the <NSS> to 
>    a location or resource

I think assumption 2 is in error. Clients that know the structure of
a name in a particular namespace are likely to manipulate it. Further,
the rules in RFC1630 about only using '/' to denote hierarchy and
mandating a particular order for the elements in the hierarchy are
intended (I assume) to provide enough commonality across namespaces
that clients will be able to process identifiers from novel namespaces.

> But the client is not allowed to
> interperet the <NSS> so it cannot replace the "Res1"
> from the previous absolute URN with "Res2" to create a new
> URN.

Yes, it could do that.

> Now for the serious concerns:
> 
> Lets say that another valid reference for resouce r1 is:
>   urn:nid2:X:Y:resource1
> 
> Suppose a client uses this absolute URN to get r1 and then
> comes across the relative URN: "Res2".
> 
> The first concern is that the client won't even know that
> the author of resource r1 had intended the relative URN
> to be retrieved using the "urn:nid1" scheme.  Is there a
> way for an author to specify the intended scheme along
> with the relative URN?

This is the sort of problem I am running into now in our tests, where
we have a bunch of HTML pages we are retroactively assigning URNs to.
Since those pages have lots of relative links in them, we can either:
  1) Make sure our new URNs reflect the same filesystem arrangement
     as the pages do.
  2) Modify the pages to make all the references absolute.
Alternative 1 certainly is unattractive, since a major point of URNs is
to provide independence from the filesystem organization du jour.

But, to answer your question, there are two appraoches the author of
an HTML page can use to say that the references are relative to BASE-URN-1
instead of BASE-URN-2. One is just to use absolute references. The second
is to use the BASE tag of HTML.

> Also will authors have to maintain multiple relative URN
> references (for each <NID> that can be used to reference it)?  
> For example:
>   <a href="urn:nid1:/Res2" href="urn:nid2:/resource2">
> Will HTML specs be modified to allow this?

> Finally, the most serious concern:
> 
> It is quite possible for there to be multiple ways
> to reach a reference even within the same name space.
> For example:
>   urn:nid1:A:B:Res1
> and
>   urn:nid1:A:res1
> may both be valid.  However, the URN:
>   urn:nid1:A:Res2
> may not be defined.  So a client could request the URN:
>   urn:nid1:A:res1/urn:nid1:/Res2
> How would the resolver know to remap 'A:res1' to 'A:B:Res1'
> since the first is already a valid reference in its name space.

It wouldn't.

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  

From: "Ron Daniel Jr." <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: "URL mailing list" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs 
Date: Thu, 30 Jan 1997 23:14:46 -0700
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Roy Fielding:

> If '/' is disallowed in URNs, then a conforming parser will reject
> a URN containing '/'.  That means you will never be able to introduce
> relative URNs.

Perhaps I was reading something into Keith's statement that wasn't
really there, but I took his statement to mean that the syntax draft
(or another document) would tell namespace developers not to use
unencoded '/' while we figure out if it will or won't follow 1630.

Since he said that we could always add relative URNs later, it would
not seem to be a blanket prohibition on unencoded '/'. "should not"
vs. "must not", as we have said in some more recent messages.

Date: Thu, 30 Jan 1997 20:03:37 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] Fragment references.
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

What Ron said, although point 4 may be determined by usage rather 
than specification, in the long run.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

>From [email-masked] Thu Jan 30 16:09 PST 1997
From: "Ron Daniel Jr." <[email-masked]>
To: "Ian Higgs +44 171 542 8595" <[email-masked]>
Cc: "URN Mailing list" <[email-masked]>
Subject: Re: [URN] Fragment references.
Date: Thu, 30 Jan 1997 16:22:59 -0700
X-Msmail-Priority: Normal
X-Priority: 3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Thus spoke Ian Higgs

> Has everybody already agreed that a URN is NOT a form of URI
> and the "/" character does NOT imply a hierarchy as stated in RFC1630?

No. That is pretty much the discussion we are having now.

My current position is that:
 1  URNs are one of the two forms of URI.
 2  URLs are the other form of URI.
 3  URNs are not URLs although they have a similar syntax. In fact,
    we purposefully try to align our syntax with that of URLs in order
    to avoid gratuitous differences. However, we don't adopt all of the
    URL syntax features until we see how they impact the core purpose of
    URNs - persistent, location-independent, resource identifiers.
        (The difference, to me, is that URNs MUST NOT specify any
         resolution-system specific hints, like protocol, port, host, etc.
         while URLs typically do specify such things.)
        (As a side note, the question of whether there really is a
         difference between URNs and URLs has been beaten to death and has
         been declared out of bounds for this list. The URN-WG charter
         assumes there is such a difference, and if there is not then the
         worst that happens to the world is that our work is moot.)
 4  In the absence of good arguments to the contrary, unencoded '/' in URNs
    will end up denoting hierarchy as stated in RFC 1630.
 5  Since we have only just started seriously discussing relative URNs,
    we have not reached consensus on the existance or absence of such a
    good argument.
 6  Since the URN-WG is chartered to produce a URN Syntax draft, and
    neither the charter or URN requirements RFC mentions relative URNs, we
    should not stop the syntax draft while we discuss them.
 7  Therefore, the syntax draft should leave an escape hatch for relative
    URNs.
 8  This is easy to do, we just state that '/' SHOULD (not MUST) be
    %encoded, leaving the door open for people not to encode it if they
    think
      a) they are following the letter and spirit of 1630
      b) whatever we do decide will be in line with 1630

> I think that I missed that.
> If so then there can be no such thing as relative URNs and all URNs
> might as well be 32 digit random numbers (for which there IS a case).

One of the URN requirements is to accomodate legacy namespaces. ISBN,
UPC, VIN, SICI, ISAN, ISWC, ... are all namespaces that identify
important content. Further, they are easy to map to the URN Syntax draft
as it currently exists. There is no need to say all URNs must be 32digit
random numbers. Such a namespace canbe created if you want, but there is
no reason to preclude the ones I cite above.

Cc: URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs 
Date: Thu, 30 Jan 1997 18:32:03 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

> Thus spoke Keith Moore:
> 
>> If we disallow unencoded '/' within URNs for now, we can always add 
>> relative URNs later when we understand them better.

I couldn't disagree more.

If '/' is disallowed in URNs, then a conforming parser will reject
a URN containing '/'.  That means you will never be able to introduce
relative URNs.  Creating barriers to technology just because it isn't
understood is a mistake, particularly when the only time '/' is
meaningful for *any* URI is when it is used as a base for parsing
relative URIs.

If you aren't using relative forms, then there is no reason to encode '/'.
If you are, then you don't want '/' encoded.  There does not exist a
situation in which it is beneficial to disallow '/' in URNs.

.....Roy

From: "Ron Daniel Jr." <[email-masked]>
To: "Ian Higgs +44 171 542 8595" <[email-masked]>
Cc: "URN Mailing list" <[email-masked]>
Subject: Re: [URN] Fragment references.
Date: Thu, 30 Jan 1997 16:22:59 -0700
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Ian Higgs

> Has everybody already agreed that a URN is NOT a form of URI
> and the "/" character does NOT imply a hierarchy as stated in RFC1630?

No. That is pretty much the discussion we are having now.

My current position is that:
 1  URNs are one of the two forms of URI.
 2  URLs are the other form of URI.
 3  URNs are not URLs although they have a similar syntax. In fact,
    we purposefully try to align our syntax with that of URLs in order
    to avoid gratuitous differences. However, we don't adopt all of the
    URL syntax features until we see how they impact the core purpose of
    URNs - persistent, location-independent, resource identifiers.
        (The difference, to me, is that URNs MUST NOT specify any
         resolution-system specific hints, like protocol, port, host, etc.
         while URLs typically do specify such things.)
        (As a side note, the question of whether there really is a
         difference between URNs and URLs has been beaten to death and has
         been declared out of bounds for this list. The URN-WG charter
         assumes there is such a difference, and if there is not then the
         worst that happens to the world is that our work is moot.)
 4  In the absence of good arguments to the contrary, unencoded '/' in URNs
    will end up denoting hierarchy as stated in RFC 1630.
 5  Since we have only just started seriously discussing relative URNs,
    we have not reached consensus on the existance or absence of such a
    good argument.
 6  Since the URN-WG is chartered to produce a URN Syntax draft, and
    neither the charter or URN requirements RFC mentions relative URNs, we
    should not stop the syntax draft while we discuss them.
 7  Therefore, the syntax draft should leave an escape hatch for relative
    URNs.
 8  This is easy to do, we just state that '/' SHOULD (not MUST) be
    %encoded, leaving the door open for people not to encode it if they
    think
      a) they are following the letter and spirit of 1630
      b) whatever we do decide will be in line with 1630

> I think that I missed that.
> If so then there can be no such thing as relative URNs and all URNs
> might as well be 32 digit random numbers (for which there IS a case).

One of the URN requirements is to accomodate legacy namespaces. ISBN,
UPC, VIN, SICI, ISAN, ISWC, ... are all namespaces that identify
important content. Further, they are easy to map to the URN Syntax draft
as it currently exists. There is no need to say all URNs must be 32digit
random numbers. Such a namespace canbe created if you want, but there is
no reason to preclude the ones I cite above.

Mr-Received: by mta REC.MUAS; Relayed; Thu, 30 Jan 1997 22:53:50 +0000
Mr-Received: by mta RE6; Relayed; Thu, 30 Jan 1997 22:53:53 +0000
Mr-Received: by mta RITIG4; Relayed; Thu, 30 Jan 1997 22:53:26 +0000
Disclose-Recipients: prohibited
Date: Thu, 30 Jan 1997 22:53:50 +0000 (GMT)
From: Ian Higgs +44 171 542 8595 <[email-masked]>
Subject: Re: [URN] Fragment references.
To: Terry Allen <[email-masked]>
Cc: URN Mailing list <[email-masked]>
Autoforwarded: false
Importance: normal
Priority: urgent
Sensitivity: Company-Confidential
Ua-Content-Id: 11B1F5B52F00
X400-Mts-Identifier: [;5650532230011997/A33094/RE6]
Hop-Count: 2
Sender: [email-masked]
Reply-To: Ian Higgs +44 171 542 8595 <[email-masked]>

Sorry to confuse you
- I may be crossing threads and discussing two things at once.

] This assumes that a "relative URN" is a "fragment reference."  That's
] not obvious.

I see them as two very different things:
    fragment refs are "#something"
but
    relative refs are "../something".

i.e.
    fragment refs are 'pointers' within the current resource
    and (probably) do not imply a fetch
but
    relative refs are refs to another resource and do imply a fetch.

] I would say that relative URNs have not been specified.

Has everybody already agreed that a URN is NOT a form of URI
and the "/" character does NOT imply a hierarchy as stated in RFC1630?
I think that I missed that.
If so then there can be no such thing as relative URNs and all URNs
might as well be 32 digit random numbers (for which there IS a case).

/Ian Higgs

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 30 Jan 1997 16:01:35 -0600 (CST)
To: "Ron Daniel Jr." <[email-masked]>
Cc: "Daniel LaLiberte" <[email-masked]>, "Ryan Moats" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > Please note that Ryan's message says "SHOULD NOT", not "MUST NOT".

Ah, right you are.  Sorry for going overboard.  Too much coffee and
arguing at the same time is making me jumpy.

dan

Date: Thu, 30 Jan 1997 13:57:42 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] Fragment references.
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Ian Higgs wrote:
| Somebody asked:
| > How is a location within a resource really different from a relative
| > URN?
| 
| I would say that a relative reference always implies a new request,
| but an internal fragment reference does not. An internal fragment 
| reference just implies a scroll in the display.

I would say that relative URNs have not been specified.

| However, as I understand the existing specifications, there could be 
| two possible understandings of fragment references.

This assumes that a "relative URN" is a "fragment reference."  That's
not obvious.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Mr-Received: by mta REC.MUAS; Relayed; Thu, 30 Jan 1997 21:11:09 +0000
Mr-Received: by mta RE6; Relayed; Thu, 30 Jan 1997 21:11:09 +0000
Mr-Received: by mta RITIG4; Relayed; Thu, 30 Jan 1997 21:10:44 +0000
Disclose-Recipients: prohibited
Date: Thu, 30 Jan 1997 21:11:09 +0000 (GMT)
From: Ian Higgs +44 171 542 8595 <[email-masked]>
Subject: [URN] Fragment references.
To: URN Mailing list <[email-masked]>
Autoforwarded: false
Importance: normal
Priority: urgent
Sensitivity: Company-Confidential
Ua-Content-Id: 11B1F54B0800
X400-Mts-Identifier: [;4109112130011997/A32374/RE6]
Hop-Count: 2
Sender: [email-masked]
Reply-To: Ian Higgs +44 171 542 8595 <[email-masked]>

Somebody asked:
> How is a location within a resource really different from a relative
> URN?

I would say that a relative reference always implies a new request,
but an internal fragment reference does not. An internal fragment 
reference just implies a scroll in the display.

However, as I understand the existing specifications, there could be 
two possible understandings of fragment references.

++++

Imagine a resource includes a link <A HREF="#somewhere">...

++ Case 1

The browser "knows" that # means relative, scans the current resource 
for the matching <A NAME="somewhere"> and adjust the display to that 
location.

++ Case 2

The browser takes the reference used to get the resource in the first
place (URL or URN), strips off any existing "#xxx" and adds the new
"#somewhere".

The resulting reference is passed to a lower part of the software
which is asked to fetch the resource.

The "fetcher" strips the "#somewhere" off again, looks in the cache 
and finds a resource matching the reference or sends out a new
request for it.

The browser gets the returned resource and THEN performs the scan
as in case 1.

++++

In the first case, the browser does not repeat the request.
In the second case it may.

Current practice seems to be the first case, so that:

- the "browser" does not include the "#somewhere" in the request.
- the "#somewhere" is not used or meaningful to the resolver or server.
- the COMPLETE resource is always returned.

For a URL this raises interesting questions. If the URL refers to 
a script rather than a fixed resource, then the first case is 
displaying a stale result and the second case implies a refresh 
which may return a different result if the resource is not cached.

If we say that the value of a URN is the persistence of the resource,
regardless of the physical location, then I assume that the two 
cases are equivalent, since the resource should not have changed.

If we say that the value of a URN is the implied indirection that 
insulates us from the physical location of the resource, then it is 
possible that the resource can change between requests or that the 
requests are resolved to different copies/versions of the resource.

Does this possibility matter to us?

/Ian Higgs

From: "Ron Daniel Jr." <[email-masked]>
To: "Daniel LaLiberte" <[email-masked]>, "Ryan Moats" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Date: Thu, 30 Jan 1997 13:02:45 -0700
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Daniel LaLiberte:
> Ryan Moats writes:
>  > documented separately.  In the interim, namespace developers SHOULD
NOT
>  > use an unecoded "/", but rather use %-encoding for "/" ("%2F").
> 

> The only sensible proposal is to *allow* unencoded '/', with the
> warning that they must be used in conformance to the relative URI
> spec.  That's my final offer.

Please note that Ryan's message says "SHOULD NOT", not "MUST NOT".
The spec will allow '/' characters, but will discourage their
use. This is to try to reduce backward compatability problems if,
during the course of discussing relative URNs, we find that 1630's
semantics on '/' are not quite right. Of course, we will probably
not find that, so "should" instead of "must" will let people go
ahead and try to predict the future.

I think he is doing a reasonable thing, and I think it meets the
needs you and Tim have expressed.

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  

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 30 Jan 1997 13:15:16 -0600 (CST)
To: David Durand <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

David Durand writes:
 > ... Now, if we have to encode FPIs to
 > make them into URNs that is OK, but if the relative URN stuff comes
 > out, it will make sense to unescape the slashes again. So there will
 > be two canonical representations for the same URN, depending on  when
 > it was issued, kind of defeating the goals of persistence.

Allowing multiple names for things does not defeat the persistence or
uniqueness properties.  The persistence property is that the name is
never used again for anything else.  The uniqueness property is that a
name is only the name of one resource (which may be a mutable
resource) not that the resource only has one name.

 > ... If we make no special allowances now,
 > and later decide that we really need relative URNs we could add
 > another kind of resolution service that takes a base URN and a
 > relative URN and returns the "real" URN.

This service is call concatenation.  Clients can do it themselves.

dan

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 30 Jan 1997 12:58:03 -0600 (CST)
To: Ryan Moats <[email-masked]>
Cc: [email-masked]
Subject: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ryan Moats writes:
 > documented separately.  In the interim, namespace developers SHOULD NOT
 > use an unecoded "/", but rather use %-encoding for "/" ("%2F").

Curious development.  

The whole reason I went along with the recent work (the NAPTR
mechanism and the "urn:" prefix for subscheme with opaque strings) was
that I could still see how the hierarchical path scheme could be
deployed.

This requirement means that either all name spaces under "urn:" will
be flat, or if a name space uses a hierarchy, it must use a different
delimiter thus destroying the possibility of using relative URIs and
getting scalable resolution without later creating new names for
everything.

I object strongly.

Disallowing unenconded '/' can only serve the flat name spaces, which
I believe are unscalable.  This does not serve the internet well.

Protecting the world from hierarchical name spaces because you don't
understand how they work is unnecessarily over constraining.  Why not
allow some name spaces to be hierarchical and see if the resolution
services can make them work?  What harm is there in that?  If a name
space fails, it fails.  Other name spaces will fail too - I believe
the flat name spaces will fail.  I'm not opposed to allowing flat
name spaces to try, however.

The only sensible proposal is to *allow* unencoded '/', with the
warning that they must be used in conformance to the relative URI
spec.  That's my final offer.

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

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 30 Jan 1997 12:40:38 -0600 (CST)
To: Keith Moore <[email-masked]>
Cc: Tim Berners-Lee <[email-masked]>, Daniel LaLiberte <[email-masked]>, "Martin J. Duerst" <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, URL mailing list <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: Relative URLs and URNs 
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Keith Moore writes:
 > > Keith, you make a good point that relative URIs are limited in
 > > persistence to the persistence of the two URIs.
 > 
 > I don't know which two URIs you're talking about.

The two URIs are something like an http URL and a URN of some kind.  A
relative URI could be relative to either kind of absolute URI.  Of
course, if the scheme of an absolute URI does not support relative
URIs, the URI could not be used as the base URI of a document.

 > The persistence problem, as I see it, comes from wiring
 > non-persistent information into the URI -- in this case, the
 > grouping of subsets of URI space -- and depending on that
 > information to be persistent.

Relative URIs may or may not wire non-persistent information depending
on how your resolution service works.  The grouping of subsets of a
URI space is a grouping of the *identifiers*, but that does not
necessarily mean that the *resources themselves* are similarly
grouped.  A redirection can be returned by the resolution service for
any part of the group pointing the client off to where the resource
currently lives (or closer to it anyway).  In fact, a hierarchical
subdivision of the group can make it even easier for the resolution
service to provide that redirection, and more importantly, for the
client to (more scalably) remember the redirection for a whole
subdivision.  All this and a bit more is supported by the path
scheme resolution mechanism.

Keith, you seem to be arguing not only against relative URNs but
against any hierarchical structuring of the URN space.  The two issues
are closely related since once you have hierarchical structuring, you
can also easily have relative identifiers.  

What is the difference between always using absolute URNs such as

  urn://path/A/B/C/D.doc
  urn://path/A/B/C/E.doc
  
and using relative URNs such as

  C/D.doc
  C/E.doc

within a document having a base URN of

  urn://path/A/B/index.doc

It might be the case that for some resolution mechanisms, you resolve
the relative part by itself in a different way than you resolve the
corresponding absolute URI.  So you might not be able to resolve
urn://path/A/B/C/D.doc directly but instead, after resolving
urn://path/A/B/, you find out about some different kind of service (say
an HTTP server) that you request C/D.doc from.

 > Tim B.L. said:
 > > But Dan La L was right too in pointing out that the relative URI
 > > may in fact be longer lived than the absolute. So it is not a
 > > clear case.
 > 
 > Unless I misunderstood his argument, it seemed to be predicated on
 > the idea that old name spaces will go away and need to be changed.
 > But since the URN framework is specifically designed so that old name
 > spaces do not need to be changed, I don't accept the premise.

The old name space may live forever with no problem - we only have to
guarantee that the names are never used again - no problem (even for
human-meaningful names).  The real problem is in finding a resolution
service that will resolve the old names.  Say a name space is created
in such a way that it is really difficult to actually resolve
identifiers in a scalable way.  One way to solve this problem is to
create a new name space with better resolution mechanisms.  The
relative URIs in the documents could remain unchanged if both the old
and new name spaces supported relative URIs.  

(Footnote: Another different kind of problem for finding a resolution
service could occur if hardly anyone cares about the resources any
more, no matter how scalable the resolution service might be.  The
problem might be to find a cheap enough resolution service.)

(Footnote: Finding (looking up) a resolution service is an essential
part of the resolution process.  You have to have a specific place
(location/address) to start the lookup process.  That's what makes a
name logically the same as an address, but we are not allowed to talk
about that on the URN list - email me replies on that.)

 > As far as I can tell, if we're going to have persistent relative URNs
 > (or equivalently, URNs that reference portions of a single resource)
 > we're going to need a level of indirection for relative URNs just like
 > we have for normal URNs.  

Yes, and providing that indirection is no more of a problem for
relative URNs than for absolute URNs, depending on how your resolution
service works.

If you are thinking only of resolution services that work with flat
name spaces, then indeed relative URNs will be a problem.  Obviously,
document writers will not be able to use URNs in non-hierarchical name
spaces as base URIs.

 > That is, 
 > 
 > given a resource a1 with URN "A1" and a similar resource a2 with URN "A2",
 > (for some meaning of "similar"), it's not reasonable to assume that
 > the portion of a1 named by "A1/foo" is similar to the portion of
 > a2 named by "A2/foo".

Correct. It would be an error to assume that.  Relative URNs can not
be directly compared for equivalence without prepending the context of
the base URN that makes them absolute.  If you know that A1 and A2
are alternative (equivalent) URNs for the same resource, then you *do*
know that "A1/foo" is equivalent to "A2/foo", otherwise you do not
know they are equivalent.

The same is true of absolute and relative URLs, by the way.

 > My view is that since persistence is an important property of URNs,
 > we should not define relative URNs (or URNs that specify portions of
 > documents) until we understand how to define them without diluting
 > the persistence of URNs.

Relative URNs do not dilute the persistence of URNs any more than
hierarchically structured URNs are non-persistent.

 > If we disallow unencoded '/' within URNs for now, we can always add 
 > relative URNs later when we understand them better.

True, but you would also be disallowing hierarchical name spaces such
as the path scheme defines.  Understanding relative URNs is a good
idea, but I don't understand why it is so difficult to understand
them.

Earlier, regarding locations within a resource, you said,

 > Even then, I'm not sure what it means to talk about references 
 > relative to a "Base URN" ...because this assumes that the "Base URN"
 > will need to change while the intra-resource reference names 
 > need to stay the same.  

Important difference: The base URN *may* change (e.g. to a newer
better name space), while the intra-resource (or inter-resource - same
can of worms) relative identifiers *need not* change.

All this talk of hierarchy should be extended to also include Tim's
matrix space with relative URIs of the form ";name=value;name=value".
John Mallery has suggested a URN scheme that is entirely matrix based.
John, it might be useful for you to briefly describe it now.
I need to give it more thought myself, to figure out how to make
the resolution scalable.

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

From: "Ron Daniel Jr." <[email-masked]>
To: "David Durand" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Date: Thu, 30 Jan 1997 10:54:58 -0700
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke David Durand:

>   The one thing that strikes me here is that FPIs use the "/"
> character to indicate syntactic divisions in the name (actually they
> use "//", but the idea is the same. Now, if we have to encode FPIs to
> make them into URNs that is OK, but if the relative URN stuff comes
> out, it will make sense to unescape the slashes again.

We are starting to do some FPI resolution here and are encoding
the '/' characters. I am not so sure that we would want to unescape
the '//' sequences in the future. I don't know that FPI's hierarchy
follows the letter and spirit of the relative URL spec. I am very
doubtful that it follows implementation practice for that spec. Also,
sometimes "::" is used instead of "//".

I think there are two basic arguments for relative URIs. One is to
make it easier to move a connected set of resources, the other is
for concision. As far as URNs and FPIs go, neither is compelling.
The primary place to use FPIs is in SGML, where they are typically
hidden behind an entity reference. That takes care of concision.
Moving a collection does not require changes to the documents, only
to the name->location resolution info. For FPIs this will typically be
a local SGMLopen catalog, or a catalog accessed through a fallback
resolution procedure such as NAPTR.

(At least, that is the approach we are taking)

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: Thu, 30 Jan 1997 09:17:29 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: [email-masked]
Subject: [URN] Reltive URNs
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

This almost seems like a replay of the old question of whether URNs should
be human readable or not. If the only goal of URNs is persistence then
there is an argument aginst relative URNs , namely that their
interptertation become context dependent, and so they can't really be
called peristent. There is some merit to this point of view.

If URNs are thought of as abstract, location independent names, then I
think reltive URNs make a lot of sense. There is no necessary relationship
between URI hierchies and physical representation. One could well imagine
a URN like this

HTMLObjects:Corporate:Intel:Product-Lines:Overview:gee-whiz-chip:version7

I don't mean to suggest this is a good URN scheme, but it is an example of
how a name could be hierarchical in structure without being tied in any way
to physical representation. 

If URNs are only meant to be permanent identifiers then it makes snse to
just use something like 12 byte idntifier or some such thing, and then it
doesn't make sense to speak of raltive URNs. If URNs are abstract names for
resources, it makes a lot of sense. In other words, it seems to me that
this is the same fundamental issu reappearing in a different context.

---
[email-masked]    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
to come up with a better one.

From: David Durand <[email-masked]>
Date: Thu, 30 Jan 1997 12:11:16 -0500 (EST)
To: [email-masked]
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: David Durand <[email-masked]>

	Mainly, I am thinking of creating a "reserved" set, that
	contains "%" and "/".  The reason's for "%" being reserved are well
	known, and that text would be moved to that section.

	For "/", Ron and I worked out the following proposed text:

	...
	"/" is RESERVED for future developments.  It might be used for
	denoting hierarchy to allow for relative URN processing, but the WG
	has not yet reached consensus on this, so such developments will be
	documented separately.  In the interim, namespace developers SHOULD NOT
	use an unecoded "/", but rather use %-encoding for "/" ("%2F").
	...

	Comments?

  The one thing that strikes me here is that FPIs use the "/"
character to indicate syntactic divisions in the name (actually they
use "//", but the idea is the same. Now, if we have to encode FPIs to
make them into URNs that is OK, but if the relative URN stuff comes
out, it will make sense to unescape the slashes again. So there will
be two canonical representations for the same URN, depending on  when
it was issued, kind of defeating the goals of persistence.

   Perhaps the best thing is to recognize that "relative URNs" may
well be naming scheme dependent in the long run, and thus not good
candidates for syntax hacking. If we make no special allowances now,
and later decide that we really need relative URNs we could add
another kind of resolution service that takes a base URN and a
relative URN and returns the "real" URN. This could be handled as a
single "relative" scheme with an opaque string, since the actual name
assignment scheme could be determined by looking at the base URN.

   -- David

Date: Thu, 30 Jan 1997 10:45:18 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Although I've only been lurking on what I call the "relative..."
discussions, I did talk with Ron Daniel on the phone earlier today,
and I think that some good ideas have arisen out of this that
should be incorporated in the syntax draft.

Mainly, I am thinking of creating a "reserved" set, that
contains "%" and "/".  The reason's for "%" being reserved are well
known, and that text would be moved to that section.

For "/", Ron and I worked out the following proposed text:

...
"/" is RESERVED for future developments.  It might be used for
denoting hierarchy to allow for relative URN processing, but the WG
has not yet reached consensus on this, so such developments will be
documented separately.  In the interim, namespace developers SHOULD NOT
use an unecoded "/", but rather use %-encoding for "/" ("%2F").
...

Comments?

Ryan

From: "Ron Daniel Jr." <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Tim Berners-Lee" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, "Daniel LaLiberte" <[email-masked]>, "Martin J. Duerst" <[email-masked]>, "URL mailing list" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs 
Date: Wed, 29 Jan 1997 18:54:23 -0700
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke Keith Moore:

> If we disallow unencoded '/' within URNs for now, we can always add 
> relative URNs later when we understand them better.

I couldn't agree more.

Encoding '/' is a bit cumbersome, but it is worth it for the potential
gain in the future.

From: Keith Moore <[email-masked]>
To: Tim Berners-Lee <[email-masked]>
Cc: Keith Moore <[email-masked]>, Daniel LaLiberte <[email-masked]>, "Martin J. Duerst" <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: [URN] Re: Relative URLs and URNs 
Date: Wed, 29 Jan 1997 18:35:05 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >> If all URNs are syntactically opaque URLs, are we not imposing a
> >> restriction on all URNs that they cannot use the relative URL mechanism?
> >
> >Yes, but this is a feature.  Relative URLs wire relationships between
> >resources into the resource name itself, which hurts long-term persistence.
> 
> Keith, you make a good point that relative URIs are limited in persistence to
> the persistence of the two URIs.   

I don't know which two URIs you're talking about.  The persistence 
problem, as I see it, comes from wiring non-persistent information
into the URI -- in this case, the grouping of subsets of URI space --
and depending on that information to be persistent.

> But Dan La L was right too in pointing  out that 
> the relative URI may in fact be longer lived than the absolute. So it is
> not a clear case.

Unless I misunderstood his argument, it seemed to be predicated on
the idea that old name spaces will go away and need to be changed.
But since the URN framework is specifically designed so that old name
spaces do not need to be changed, I don't accept the premise.

As far as I can tell, if we're going to have persistent relative URNs
(or equivalently, URNs that reference portions of a single resource)
we're going to need a level of indirection for relative URNs just like
we have for normal URNs.  

That is, 

given a resource a1 with URN "A1" and a similar resource a2 with URN "A2",
(for some meaning of "similar"), it's not reasonable to assume that
the portion of a1 named by "A1/foo" is similar to the portion of
a2 named by "A2/foo".  What we would need is some mapping layer which
we could ask "what portion of a2 is equivalent to the portion of a1 named
by "A1/foo"?".  (and just because "A1/foo" maps to "A2/bar" doesn't
mean that A2/bar maps to A1/foo)

> So one should not forbid them.  Disabling a consistent function in a special
> case is normally a kludge, not a feature.  In general, specs which tell
> people what to do against their better judgement are typically suspect too.
> This would be something to put in a usage document: "When relative
> URIs are considered harmful and when not"

My view is that since persistence is an important property of URNs,
we should not define relative URNs (or URNs that specify portions of
documents) until we understand how to define them without diluting
the persistence of URNs.

If we disallow unencoded '/' within URNs for now, we can always add 
relative URNs later when we understand them better.

Keith

Date: Wed, 29 Jan 1997 17:46:52 -0500
To: Keith Moore <[email-masked]>, Daniel LaLiberte <[email-masked]>
From: Tim Berners-Lee <[email-masked]>
Subject: [URN] Re: Relative URLs and URNs 
Cc: "Martin J. Duerst" <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, URL mailing list <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Tim Berners-Lee <[email-masked]>

At 11:12 am 29-01-97 -0500, Keith Moore wrote:
>> If all URNs are syntactically opaque URLs, are we not imposing a
>> restriction on all URNs that they cannot use the relative URL mechanism?
>
>Yes, but this is a feature.  Relative URLs wire relationships between
>resources into the resource name itself, which hurts long-term persistence.

Keith, you make a good point that relative URIs are limited in persistence to
the persistence of the two URIs.   But Dan La L was right too in pointing
out that 
the relative URI may in fact be longer lived than the absolute. So it is
not a clear case.
So one should not forbid them.  Disabling a consistent function in a special
case is normally a kludge, not a feature.  In general, specs which tell
people what to do against their better judgement are typically suspect too.
This would be something to put in a usage document: "When relative
URIs are considered harmful and when not"

[...]

(Dan L:)
>> Another advantage of relative identifiers is that they are shorter
>> than their equivalent full identifiers.  

Yes.

>It's not necessarily true that a URN is shorter than a relative URL.

(That wasn't what Dan said (that relative URIs in general are shorter than
absolute URIs) , I  assume it's the reverse of what you meant
to say, that "It's not necessarily true that a relative URL is shorter than
a URN" )

>Since URNs don't need to be human-meaningful, they can be allocated
>from a denser space than is typical for URLs.

There is nothing to *stop* URLs being allocated extremely densely.
Following my comment in Leslie's message, it is a social issue that
URLs are typically not dense and not always persistently maintained.

Since HTTP URLs don't need to be human-meaningful, they can be
allocated from a denser space than may equally become typical for URNs.

>Keith

Tim

Date: Wed, 29 Jan 1997 17:26:39 -0500
To: Leslie Daigle <[email-masked]>, [email-masked], [email-masked]
From: Tim Berners-Lee <[email-masked]>
Subject: Re: [URN] what's in a syntax?
Sender: [email-masked]
Reply-To: Tim Berners-Lee <[email-masked]>

I don't follow this consistently, but I am granting myself
the luxury of responding here (with my w3c hat off)
as I think it is important.

At 03:25 pm 27-01-97 -0500, Leslie Daigle wrote:
>	. If we align the syntaxes wrt reserved characters, etc, will
>	  
>		URN:<see syntax draft of the day>
>
>	  necessarily imply that URNs are a "scheme" of URLs?

It would be sufficiently confusing that I would certainly oppose
it if it didn't.

>	  If so, then URNs will have to go through the URL vetting process,
>	  and potentially the string "URN" will be objected to.

I don't see any reason why anyone should object to a string.
(It would be nice if one were to admit the possibility  of other schemes
which match the URN requirements but are in fact different schemes,
just as you can consider "URL" to be one requirement and "HTTP"
to be a protocol meeting it.  But if the only thing in one's way is an
arbitrary string, then it should not really prevent progress!)

>	  Also, will this imply that URNs are equivalent to URLs in terms
>	  of semantics?  (There are those that think the are, and those that
>	  think they aren't). 

No, no 1000 times no!   I have tried so many times to say that universal
URI syntax is more universal than the semantics of any "name",
"address", "locator" space.  It is social issues not technical ones
which in the end make the differences between names and addresses
in a global information space.

>	. Alternatively, can we align the syntaxes and succeed in having
>
>		URN:<see syntax draft of the day>
>
>	  treated as a special case by URL resolvers, (treated as an 
>	  opaque URL, as Ryan described it).

Hands up those who like special cases.

>These questions have little to do with implementation details -- i.e., 
>any of the above can certainly be implemented.  The real questions, to my
>way of thinking, lie in:
>
>	. Does lining up the syntaxes increase the likelihood of getting
>	  URNs handled sooner rather than later by existing software (i.e.,
>	  are the necessary differences in handling going to mean that
>	  existing software can't handle them anyway?)
>
>	. What issues will we have to address in terms of 
>	  supporting/distinguishing URN/URL semantics?  (E.g., if URNs
>	  are supported as URL "schemes",  can we make the distinction
>	  between names and addresses).

The semantics of any URI scheme, http: and urn: included, are defined by

  - The specification of hte scheme in the rules it allows for changing
   the mapping of URI to content;
 - the social systems set up to ensure that the rules are followed;
 - the extent to which those social systems work;
 - The rules set up, in a hierarchical system, by delegates such as
   URN authorities for URNs or webmasters for HTTP which determine
  how specifically the mapping of URI to content in any given subtree;
 - Similarly, the social systems to enforce those rules and the extent 
 that they work.

Historians and librarians of the future will be able to say what worked
in terms of being persistent.

>I have not been successful in trying to make this an even-handed message
-- it
>is pretty clear that I am concerned that we are heading back into rough
>waters regarding "why do we need URNs when we have URLs". 

If the URN group is going to set up a new name space with good properties,
then that seems to me to have some value.  I also believe in the coexistence
of alternative schemes and (especially when social factors are involved)
the real world and the market testing them and choosing in the end.

Tim BL

From: Keith Moore <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: "Martin J. Duerst" <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, Tim Berners-Lee <[email-masked]>, URL mailing list <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: Relative URLs and URNs 
Date: Wed, 29 Jan 1997 11:12:51 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> If all URNs are syntactically opaque URLs, are we not imposing a
> restriction on all URNs that they cannot use the relative URL mechanism?

Yes, but this is a feature.  Relative URLs wire relationships between
resources into the resource name itself, which hurts long-term persistence.

> Long term, support for some name
> spaces will eventually fade out completely, so moving to a new name
> space is not only a possibility, it seems to be a certainty.

Yes, for newly-created names.  But there's no reason why resolution
services cannot continue to exist for old namespaces, even though
they may use new resolution methods and protocols.

> How is a location within a resource really different from a relative
> URN?

The answer depends on whether the relationship between locations within
a resource can change over time.  But you're right - the ability to
reference different portions of a resource opens up a very similar
can of worms as the ability to reference one resource relative to another.

If you want persistent references for portions of a resource, you need 
similar rules for assignment as you would for persistent identifiers 
for resources themselves -- e.g. don't use section numbers (they'll change)
or human-meaningful section names (because the document will be 
reorganized into sections that don't correspond to the original one).

Even then, I'm not sure what it means to talk about references 
relative to a "Base URN" ...because this assumes that the "Base URN"
will need to change while the intra-resource reference names 
need to stay the same.  

> Another advantage of relative identifiers is that they are shorter
> than their equivalent full identifiers.  

It's not necessarily true that a URN is shorter than a relative URL.
Since URNs don't need to be human-meaningful, they can be allocated
from a denser space than is typical for URLs.

Keith

Date: Wed, 29 Jan 1997 18:48:35 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] what's in a syntax? (fwd)
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

The following is a mail I sent to Leslie regarding her request
on the URN list. I am posting it now, as mentionned before,
because I think that it gives some more background to some
things currently discussed about URNs and URLs. Not that
I think that the things I discuss here should be realized
immediately, though.

Regards,	Martin.

---------- Forwarded message ----------
Date: Tue, 28 Jan 1997 10:01:53 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Leslie Daigle <[email-masked]>
Subject: Re: [URN] what's in a syntax?

On Mon, 27 Jan 1997, Leslie Daigle wrote:

> It seems to me that we are at a crossroads with the URN syntax, and we need to 
> get some concrete sense of direction quickly.
> 
> I'd like to outline the situation below and then ask for everyone to send
> feedback to me directly -- and please, do send feedback, if only to let me
> know people are still thinking about this :-)

Hello Leslie,

I'm definitely still caring about it, although my main concern is
internationalization. Even for this, the syntactic parallels between
URLs and URNs are important, whereas semantically (e.g. why do we
need internationalization), there are wide differences.

> Ryan, our URN syntax document editor, has spent a good deal of time trying
> to get URN syntax to line up reasonably well with the existing URL syntax
> document (i.e., the de facto "URI" syntax document).
> 
> This document is currently under review, and there are efforts afoot to 
> determine a review process for vetting new URL schemes. 
> 
> As part of the discussion of this (on the [email-masked] mailing list),
> the issue of URN conformance with URL syntax has come up.  There are some
> specific changes that would (still) have to be made to accomplish this.
> While these are not necessarily stressing in terms of syntax, there
> are some particular ramifications that need to be considered:
> 
> 	. If we align the syntaxes wrt reserved characters, etc, will
> 	  
> 		URN:<see syntax draft of the day>
> 
> 	  necessarily imply that URNs are a "scheme" of URLs?

No, URNs are not, and should not be, a special scheme. They are on
par with URLs. But syntactically, they look like a (not so) special
scheme, and this has many advantages. And they might be processed
by many browsers like a scheme, i.e. look at part before first ":",
decide which subroutine to call, and pass the rest to this subroutine.

> 	  If so, then URNs will have to go through the URL vetting process,
> 	  and potentially the string "URN" will be objected to.

No, URNs are one level higher.

> 	  Also, will this imply that URNs are equivalent to URLs in terms
> 	  of semantics?  (There are those that think the are, and those that
> 	  think they aren't). 

That's not my field of expertise, but I think finally, usage will
show it. In some sense, they are similar (you get something back if
you type it into a browser), in some sense, they are hopefully different
(persistency,...).

> 	. Alternatively, can we align the syntaxes and succeed in having
> 	  
> 
> 		URN:<see syntax draft of the day>
> 
> 	  treated as a special case by URL resolvers, (treated as an 
> 	  opaque URL, as Ryan described it).

An opaque URL, in terms of URLs, is nothing special. A lot of URLs
are opaque URLs, such as "mailto" or "data". URNs conform to URL
syntax. They just don't conform to the syntax for generic URLs,
but that's not necessary.

The question might arise whether relative addressing of URNs is
necessary or desirable. The way I see URNs, their persistency
implies that they are rather big and independent, so that
relative addressing is not of much use. One of the scenarios
I see is that an URN (e.g. for a book) is resolved to an URL
that is the top of the hypertext structure that actually
represents that book, and that that hypertext structure
is internally linked using relative URLs.

This may lead to the question whether we need a way to not only
say "book X" (with urn:isbn:0-12345678-9) but "paragraph m on page n
of chapter y". There would be no need for such things to use
relatively, as other means can be used for addressing inside
a document, and as the main advantage of relative addressing,
invariance under coordinated movement to another place, is
irrelevant because URNs don't change if the actual resource
is moved to another place. But still, the requirement of
addressing a point inside an URN may remain.

The problem is that such addressing can be done in many different
ways (pages vs. chapters and sections, or seconds for a video,...).
The #name feature looks promising, but it restricts references
to only those places that have been tagged beforehand, not a
good thing for maybe very bulky documents.

What I think is worth contemplating, if not already done, are
ways to identify locations inside an URN. This is quite an
architectural question, because we might require that
URN resolvers resolve locations inside a resource at the
same time they resolve the URN itself, or that it is just
something done syntactically. In the first case, an URN
	urn:isbn:0-12345678-9=page34line20
would be passed as
	0-12345678-9=page34line20
to some isbn resolver, which, maybe with the help of other
resolvers, could return an URL such as
	http://xxx.yyy.lib/books/shelfNN/ourBook/chapter3/section2#anchor
which might be the closest identifiable point to line 20 on page 34.
The alternative would be to have an URN
	urn:isbn:0-12345678-9=/chapter3/section2#anchor
which would be chopped apart either by the URN software or an
isbn resolver (depending on whether a generic syntax is choosen
or not). The resolving process would then return only
	http://xxx.yyy.lib/books/shelfNN/ourBook
and the client would append
	/chapter3/section2#anchor
to get the same result. In the above, the fact that the first example
uses lines and pages should not give the impression that this variant
is more oriented towards physical location; the important thing is
that it (potentially) allows various addressing modalities and
transformation from one modality to another. The character "=" has
been choosen just as an example. If we decide that addressing
inside a resource is a desired syntactical property of (potentially)
all URNs and that it should be handled syntactically (i.e. by
string concatenation with the resulting URL, with all the problems
of non-portability), then it might become "#". If URN resolvers
are responsible for this part also, there is no need for a convention,
although it is not bad to have an informal one. The main problem
in this case is that URN schemes have to plan for such things
in advance; it is difficult to start with an "isbn" scheme
without such a feature and later add one. There is also the
danger of fragmentation, i.e. from an isbn scheme, somebody
might create an isbnpageline scheme, whereas somebody else
might create an isbnchaptsect scheme. If done with enough
foresight, this is of course not necessessary, because
	urn:isbn:0-12345678-9=page34line20
and
	urn:isbn:0-12345678-9=chapt2sect3
(which in both cases would need a little bit more of syntax after
the "=") can both coexist.

> These questions have little to do with implementation details -- i.e., 
> any of the above can certainly be implemented.  The real questions, to my
> way of thinking, lie in:
> 
> 	. Does lining up the syntaxes increase the likelihood of getting
> 	  URNs handled sooner rather than later by existing software (i.e.,
> 	  are the necessary differences in handling going to mean that
> 	  existing software can't handle them anyway?)

The syntaxes are already lined up (apart from internationalization issues).

> 	. What issues will we have to address in terms of 
> 	  supporting/distinguishing URN/URL semantics?  (E.g., if URNs
> 	  are supported as URL "schemes",  can we make the distinction
> 	  between names and addresses).
> 
> 
> I have not been successful in trying to make this an even-handed message -- it
> is pretty clear that I am concerned that we are heading back into rough
> waters regarding "why do we need URNs when we have URLs".  _However_, I 
> know there are other people who have seen all of this and think that there
> is no real issue at all.

The rough question might be "do we need some mechanism to identify
'locations' inside a resource".

> So, please send feedback -- if you think there is an issue here, and why, or
> if you think there is no issue here, and why not.  Please send directly
> to me -- I will summarize for the list, and make the collected messages
> available.  

It turns out that I have written a lot here. If you think that it
makes sense to send this directly to the list for further
discussion, please do so or tell me to do so.

Regards,	Martin.

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 29 Jan 1997 09:58:08 -0600 (CST)
To: "Martin J. Duerst" <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, Tim Berners-Lee <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Martin J. Duerst writes:
 > As far as I understand, the first part after the "urn" prefix is
 > not an authority (work is going on on mechanisms to actually
 > find such authorities or resolvers), but more akin to a scheme
 > in the URL case. So the use of ":" instead of "//" has some
 > merit.

That is one way to look at it.  I like to think of the <authority> as
a scheme name because it determines how the rest of the identifier is
interpreted, just as for other identifiers.  But this nested notation
does not fit in the current generic URI notation.  We could probably
change the generic URI notation to allow this nesting, but there are
some other considerations.  For one thing, there was some discussion
about whether the <authority> itself should be hierarchical to allow
subauthorities.  Scheme names are not (currently) hierarchical.

But if the <authority> in the identifier is used to find or look up an
authority or resolver, then the <authority> is at least the *name* of
the authority or resolver.

 > I beg to disagree. URNs are designed to be syntactically equivalent to
 > opaque URLs.

Whether URNs are syntactically opaque URLs is still open for discussion.

If all URNs are syntactically opaque URLs, are we not imposing a
restriction on all URNs that they cannot use the relative URL mechanism?

 > Ron Daniels said:
 > > At this time we have not defined any relative URN specification.

True, but we wouldn't need to define a new relative URN specification
if we simply inherited the relative URL specification so that it applies
to URNs also.

 > Because URNs are persistent, the main advantage of relative URNs,
 > namely invariance on coordinated movements to other locations,
 > is irrelevant.

Not true, for several reasons.  One reason is that, although URNs are
*intended* to be persistent, there will be multiple names for things,
each possibly providing different associated services or different
reliability or speed of resolution.  Long term, support for some name
spaces will eventually fade out completely, so moving to a new name
space is not only a possibility, it seems to be a certainty.
Therefore, making the identifiers within a document relative to the
base identifier is a good idea.  This is not really different from
what you suggest next:

 > What could be more relevant is the possibility to address parts of
 > resources, or 'locations' within resources, together with URNs.

How is a location within a resource really different from a relative
URN?

What makes an identifier be relative is that part of the context for
interpreting it is missing from the identifier itself.  That context
is the base URL of a document, but it could just as well be a base URN
of the document.

So both relative URNs and relative URLs are better thought of as
relative identifiers of some kind.  What kind of identifier they are
depends on the context, the base URI.  The very same relative
identifier could be both a relative URL (e.g. http) and a relative URN
(e.g. path), if the URN supported hierarchy at that level.

Another advantage of relative identifiers is that they are shorter
than their equivalent full identifiers.  This becomes a significant
issue when there are large numbers of identifiers in a document.
(This is analogous to the flyweight pattern, if you are familiar with
OO design patterns.)

 > I have sent some considerations about this to Leslie as a
 > response to her request on the URN mailing list; I can make
 > this available if somebody is interested.

If Leslie includes that in her summary, I can wait.

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

Date: Tue, 28 Jan 1997 10:21:38 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: "Ron Daniel Jr." <[email-masked]>
Cc: Tim Berners-Lee <[email-masked]>, URL mailing list <[email-masked]>, [email-masked]
Subject: [URN] Re: Relative URLs, // and ;
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Mon, 27 Jan 1997, Ron Daniel Jr. wrote:

> [I'm adding [email-masked] to the Cc list since that is the
> list for the IETF's URN-WG.]
> 
> Thus spoke Tim Berners-Lee:
> 
> >The URN scheme should be
> >mapped onto
> >urn1://authority/nameissuedbyauthority

As far as I understand, the first part after the "urn" prefix is
not an authority (work is going on on mechanisms to actually
find such authorities or resolvers), but more akin to a scheme
in the URL case. So the use of ":" instead of "//" has some
merit.

> The proposed URN syntax is laid out in draft-ietf-urn-syntax, but
> the short description is:
>    urn:namespace_id:namespace_specific_string
> for example
>    urn:isbn:1-234-5678-9
>    urn:upc:42709-10150
> etc.
> 
> Some namespaces, such as ISO Formal Public Identifiers, already make
> use of '//'. For such namespaces we say they need to %encode occurances
> of '/' that do not follow the rules of RFC1639. Those rules were that
> '/' denoted hierarchy with the most significant component on the left.

I beg to disagree. URNs are designed to be syntactically equivalent to
opaque URLs. In an opaque URL, escaping of '/' is not needed, unless
it is syntactically significant. See e.g. section 2.1 of draft-fielding-...
The only reserved characters that URN syntax itself uses is ":",
and this doesn't have to be escaped because it cannot appear in the
first two parts ("urn" and e.g. "isbn"). The need of escaping
of reserved characters after the second ":" is determined by the
needs of the namespace. These will usually be rather low, as
some of them don't use many characters so that there is no
problem identifying reserved characters, and others will
most certainly have their own way to get around this problem.
E.g. in the case of "isbn", "-" is a reserved character, but
it is not also used at the place of a digit (or X). In the
case of ISO Formal Public Identifiers, either "/" is also
disallowed between structurally meaningful "/", or there
must be a way to escape such "/".

> At this time we have not defined any relative URN specification.

Because URNs are persistent, the main advantage of relative URNs,
namely invariance on coordinated movements to other locations,
is irrelevant.
What could be more relevant is the possibility to address parts of
resources, or 'locations' within resources, together with URNs.
I have sent some considerations about this to Leslie as a
response to her request on the URN mailing list; I can make
this available if somebody is interested.

Regards,	Martin.

Date: Mon, 27 Jan 1997 16:23:45 -0700
To: Tim Berners-Lee <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: [URN] Re: Relative URLs, // and ;
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

[I'm adding [email-masked] to the Cc list since that is the
list for the IETF's URN-WG.]

Thus spoke Tim Berners-Lee:

>The URN scheme should be
>mapped onto
>urn1://authority/nameissuedbyauthority

The proposed URN syntax is laid out in draft-ietf-urn-syntax, but
the short description is:
   urn:namespace_id:namespace_specific_string
for example
   urn:isbn:1-234-5678-9
   urn:upc:42709-10150
etc.

Some namespaces, such as ISO Formal Public Identifiers, already make
use of '//'. For such namespaces we say they need to %encode occurances
of '/' that do not follow the rules of RFC1639. Those rules were that
'/' denoted hierarchy with the most significant component on the left.

>At 11:29 am 27-01-97 -0600, Daniel LaLiberte wrote:
>>Are you just putting your foot down now  .. finally.
>
>I've been out of the loop.  URIs are not supposed to be irrevocably linked
>to DNS!
>Unfortunately there have been many demands on my time.

I don't understand your assertion about DNS. No URN namespace is
required to use domain names, as shown by the examples above. Certainly the
namespaces we are considering for use at the lab have NO tie to the DNS.
(They may be resolved through the DNS, but the names themselves don't
use domain names).
Members of the URN-WG have expressed a desire for a namespace that is
easy for people to get started with, and lots of people think that using
the domain name hierarchy (perhaps with some augmentations to overcome
the reassignment problem) is the way to go. Such a namespace might
look like
  urn:inet:acl.lanl.gov(1):fy97_budget
but I emphasize that this is only one namespace out of many.

[Lots of stuff on "///", "//", "/" deleted.]
At this time we have not defined any relative URN specification.
Nevertheless we do not allow unencoded occurances of '/' in URNs
unless they follow the rules in RFC1630. Similarly, '?', '#', and
a few other characters must be encoded unless they follow the
rules of RFC1630.

One of the URN requirements was to allow old namespaces to be grandfathered
into URNs. Because of this, I am wary about requiring ALL URN namespaces
to use '//'. Some namespaces will not have the notion of a relative identifier,
others (such as path) may not need '//'. What we do require is that
when representing a name from an old namespace as a URN, reserved
characters are encoded unless they meet the semantics established by 1630.

Ron Daniel Jr.                       email: [email-masked]
Advanced Computing Lab,  MS B287     voice: +1 505 665 0597
Los Alamos National Laboratory         fax: +1 505 665 4939
Los Alamos, NM, USA  87545            http://www.acl.lanl.gov/~rdaniel/
 Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

From: Leslie Daigle <[email-masked]>
Date: Mon, 27 Jan 1997 15:25:07 -0500
To: [email-masked]
Subject: [URN] what's in a syntax?
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

It seems to me that we are at a crossroads with the URN syntax, and we need to 
get some concrete sense of direction quickly.

I'd like to outline the situation below and then ask for everyone to send
feedback to me directly -- and please, do send feedback, if only to let me
know people are still thinking about this :-)

Ryan, our URN syntax document editor, has spent a good deal of time trying
to get URN syntax to line up reasonably well with the existing URL syntax
document (i.e., the de facto "URI" syntax document).

This document is currently under review, and there are efforts afoot to 
determine a review process for vetting new URL schemes. 

As part of the discussion of this (on the [email-masked] mailing list),
the issue of URN conformance with URL syntax has come up.  There are some
specific changes that would (still) have to be made to accomplish this.
While these are not necessarily stressing in terms of syntax, there
are some particular ramifications that need to be considered:

	. If we align the syntaxes wrt reserved characters, etc, will
	  
		URN:<see syntax draft of the day>

	  necessarily imply that URNs are a "scheme" of URLs?

	  If so, then URNs will have to go through the URL vetting process,
	  and potentially the string "URN" will be objected to.

	  Also, will this imply that URNs are equivalent to URLs in terms
	  of semantics?  (There are those that think the are, and those that
	  think they aren't). 

	. Alternatively, can we align the syntaxes and succeed in having

		URN:<see syntax draft of the day>

	  treated as a special case by URL resolvers, (treated as an 
	  opaque URL, as Ryan described it).

These questions have little to do with implementation details -- i.e., 
any of the above can certainly be implemented.  The real questions, to my
way of thinking, lie in:

	. Does lining up the syntaxes increase the likelihood of getting
	  URNs handled sooner rather than later by existing software (i.e.,
	  are the necessary differences in handling going to mean that
	  existing software can't handle them anyway?)

	. What issues will we have to address in terms of 
	  supporting/distinguishing URN/URL semantics?  (E.g., if URNs
	  are supported as URL "schemes",  can we make the distinction
	  between names and addresses).

I have not been successful in trying to make this an even-handed message -- it
is pretty clear that I am concerned that we are heading back into rough
waters regarding "why do we need URNs when we have URLs".  _However_, I 
know there are other people who have seen all of this and think that there
is no real issue at all.

So, please send feedback -- if you think there is an issue here, and why, or
if you think there is no issue here, and why not.  Please send directly
to me -- I will summarize for the list, and make the collected messages
available.  

Thanks,
Leslie.

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

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

Date: Mon, 20 Jan 1997 10:58:54 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Last ?? Pre-release of syntax-02.
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

--------------2C1F68322435
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks-

Here is the next (and if I'm lucky last) pre-release of syntax-02.

Changes from the last pre-release are that I've moved characters
around to align with the URL specification, and added an Appendix
on how URN's should be handled by URL resolvers.  Please look at this
as it could probably use some hammering.

If I don't see any comments by next monday I'll send it to the i-d
editors.  (Actually if the comments are slight enough I'll do that
anyway).

Ryan

--------------2C1F68322435
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-02.txt                                        AT&T
Expires in six months                                       January 1997

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-02.txt

Status of This Memo

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

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

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

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent
   resource identifiers. This document sets forward the canonical syntax
   for URNs.  Support for both existing legacy and new namespaces is
   discussed. 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
   resource identifiers and are designed to make it easy to map other
   namespaces (which share the properties of URNs) into URN-space. The
   URN syntax therefore provides a means to encode character data in a
   form that can be sent in existing protocols, transcribed on most
   keyboards, etc.

Expires 7/31/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                   January 1997

2. Syntax

   All URNs have the following syntax:

                     <URN> ::= "urn:" <NID> ":" <NSS>

   <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading case-insensitive "urn:" sequence is
   required.  The Namespace ID is used to determine the _syntactic_
   interpretation of the Namespace Specific String (as discussed in
   [1]).

   RFC 1737 [2] presents additional requirements on URN encoding, which
   all 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> [ *<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 [3] (which

Expires 7/31/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                   January 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 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>

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

   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 a 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.  Therefore, the

Expires 7/31/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                   January 1997

   process of registering a namespace identifier shall include
   publication of a definition of which characters have a special
   meaning to that namespace.

2.3 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 a URN, MUST be %encoded:

   <excluded> ::= octets 0-32 (0-20 hex) | "\" | """ | "#" | "&" | "<"
                  | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | octets 127-255 (7F-FF hex)

   A 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 a URN-
   namespace and fulfills the criteria of URN-namespaces MUST be
   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

   URN-aware applications MAY support "natural" display of URNs which
   contain characters encoded using "%" notation.  However, they MUST
   provide for display of URNs in canonical form (i.e. in a format
   suitable for transcription).

   URNs MUST be transported in canonical format.

5. Lexical Equivalence in URNs

For various purposes, such as caching, it is necessary to determine
equivalence without actually resolving the URN. This done by testing for
"lexical equivalence". 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

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

Expires 7/31/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                   January 1997

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. Functional Equivalence in URNs

   Functional equivalence is determined by URN resolvers and is
   therefore outside the scope of this document.  Namespace registration
   MUST include documentation on how to determine functional equivalence
   for that namespace.

7. Examples of equivalence

   The following URN comparisons highlight the difference between these
   types of equivalence:

     urn:isbn:1-23485-8-29, urn:isbn:1-23485-8-29 are lexically equiv.
     urn:isbn:1-23485-8-29, URN:ISBN:1-23485-8-29 are lexically equiv.
     urn:isbn:1-23485-8-29, urn:isbn:123485829 are not lexically equiv.
        but may be functionally equivalent.

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]         K. Sollins, L. Masinter.  "Functional Requirements

Expires 7/31/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                   January 1997

                     for Uniform Resource Names," RFC 1737.  December
                     1994.

         [3]         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>".

   A URN MUST be considered an opaque URL by URL resolvers and either
   passed (with the "urn:" tag) to a 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, a 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 July 31, 1997.

Expires 7/31/97                                                 [Page 6]

--------------2C1F68322435--

Date: Mon, 13 Jan 1997 13:06:52 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Martin J. Duerst" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL  syntax draft]
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Martin J. Duerst wrote:
> 
> On Thu, 9 Jan 1997, Ryan Moats wrote [regrouped]:
> 
> > 1. The URN syntax is more restrictive in the types of characters
> > allowed vis-a-vie the URL syntax.  Specifically, the characters
> > ";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format)
> > in the URL syntax while not in the URN syntax.
> 
> > My current thoughts are to move the characters in note 1 above from the
> > excluded character set to the allowed character set to more closely
> > align the URN and URL character sets.  IF SOMEONE THINKS THIS IS A BAD
> > IDEA THIS IS A GOOD TIME TO LET ME KNOW!
> 
> With exception of "~", for which some change has been going on in
> the URL syntax draft, they should be in. The reasoning for this is
> that we don't know what kind of reserved characters a namespace would
> like to use, but we know that it can only use those that we include.

I haven't seen anything on this.  Is "~" going to be moved to the
excluded
URL character set?

> > 2. The URL syntax document makes a claim that the its syntax is the
> > syntax for URIs in general so that URNs may be used in any data field
> > that might otherwise hold a URL.
> >
> > Issue 2 is handled (I believe) by adding an appendix to the URN syntax
> > document that covers how a URL resolver should react to a URN. My
> > proposal is that the URN be considered an opaque URL that gets handed
> > off to a URN resolver. There are alternate solutions, but they become
> > progressively more ugly.
> 
> Yes, this is a good way to describe it. Please make sure you don't
> write "an URL resolver SHOULD", but that you describe this as a possible
> way to proceed that clarifies the relationship between URLs and URNs.

My view is that a URL resolver that doesn't understand URN syntax MUST
treat
the URN as an opaque URL and not try to do anything with it (other than
pass
it to a URN resolver).  A URL resolver that understands URNs... well
that's a
beast of a different hue.

Ryan

Date: Mon, 13 Jan 1997 18:54:58 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL  syntax draft]
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 9 Jan 1997, Ryan Moats wrote [regrouped]:

> Well, here we are in the week of 1/6/97 and some issues have come up
> vis-a-vie the URL syntax document.  Here are the technical issues (as I
> see them, and I've probably missed/ignored some):
> 
> 1. The URN syntax is more restrictive in the types of characters
> allowed vis-a-vie the URL syntax.  Specifically, the characters
> ";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format)
> in the URL syntax while not in the URN syntax.

> My current thoughts are to move the characters in note 1 above from the
> excluded character set to the allowed character set to more closely
> align the URN and URL character sets.  IF SOMEONE THINKS THIS IS A BAD
> IDEA THIS IS A GOOD TIME TO LET ME KNOW!

With exception of "~", for which some change has been going on in
the URL syntax draft, they should be in. The reasoning for this is
that we don't know what kind of reserved characters a namespace would
like to use, but we know that it can only use those that we include.

> 2. The URL syntax document makes a claim that the its syntax is the
> syntax for URIs in general so that URNs may be used in any data field
> that might otherwise hold a URL.
> 
> I'll admit that there are a lot of political issues that I am ignoring
> for now, but I want to see if we can move forward with the technical
> issues.

> Issue 2 is handled (I believe) by adding an appendix to the URN syntax
> document that covers how a URL resolver should react to a URN. My
> proposal is that the URN be considered an opaque URL that gets handed
> off to a URN resolver. There are alternate solutions, but they become
> progressively more ugly.

Yes, this is a good way to describe it. Please make sure you don't
write "an URL resolver SHOULD", but that you describe this as a possible
way to proceed that clarifies the relationship between URLs and URNs.

> Note that issues 1 and 2 are somewhat independent.  Given the current
> allowed characters and the above suggested appendix, any URN could be
> used in place of a URL.  
> 
> Although I've considered it in the past, I think that defining URN's as
> a URL "scheme" is a less optimal solution than the above proposals.

I agree we should not say that an URN is an URL "scheme".
Syntactically, it is equivalent to an URL scheme, but semantically,
it is something different.

Regards,	Martin.

Date: Thu, 9 Jan 1997 12:24:06 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL syntax draft]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Ryan's suggestions sound okay to me.

>Obviously, I am soliciting input to try and gain an idea about consensus
(and fairly quickly, too).
                            
Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Thu, 09 Jan 1997 12:54:06 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL syntax draft]
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

--------------5232E4A818
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

For some reason, this didn't go anywhere the first time???!

Ryan

--------------5232E4A818
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Sender: jayhawk
Date: Tue, 07 Jan 1997 13:02:04 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: Proposed URN Syntax Draft changes to align with URL syntax draft

Ryan Moats wrote:
> 
> Folks-
> 
> There have been some good comments about the syntax draft and some
> good stuff coming out of meshing it with the URL syntax, so I am
> planning the following (i.e. you have been warned!).
> 
> There will be another pre-release of syntax-02 coming out on
> 12/26 ( Holidays, what are Holidays ;-} ).  The target is to
> have -02 be sent to the i-d editors on 1/6/97.
> 
> This way folks (who don't have anything else to do between 12/25
> and 1/1) can read the new version...

Well, here we are in the week of 1/6/97 and some issues have come up
vis-a-vie the URL syntax document.  Here are the technical issues (as I
see them, and I've probably missed/ignored some):

1. The URN syntax is more restrictive in the types of characters
allowed vis-a-vie the URL syntax.  Specifically, the characters
";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format)
in the URL syntax while not in the URN syntax.

2. The URL syntax document makes a claim that the its syntax is the
syntax for URIs in general so that URNs may be used in any data field
that might otherwise hold a URL.

I'll admit that there are a lot of political issues that I am ignoring
for now, but I want to see if we can move forward with the technical
issues.

My current thoughts are to move the characters in note 1 above from the
excluded character set to the allowed character set to more closely
align the URN and URL character sets.  IF SOMEONE THINKS THIS IS A BAD
IDEA THIS IS A GOOD TIME TO LET ME KNOW!

Issue 2 is handled (I believe) by adding an appendix to the URN syntax
document that covers how a URL resolver should react to a URN. My
proposal is that the URN be considered an opaque URL that gets handed
off to a URN resolver. There are alternate solutions, but they become
progressively more ugly.

Note that issues 1 and 2 are somewhat independent.  Given the current
allowed characters and the above suggested appendix, any URN could be
used in place of a URL.  

Although I've considered it in the past, I think that defining URN's as
a URL "scheme" is a less optimal solution than the above proposals.

Obviously, I am soliciting input to try and gain an idea about consensus
(and fairly quickly, too).

Ryan

--------------5232E4A818--

From: "Ronald E. Daniel" <[email-masked]>
Date: Thu, 9 Jan 1997 11:00:24 -0700 (MST)
To: [email-masked]
Subject: [URN] new HTTP conventions draft
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-http-conv-01.txt             Los Alamos National Laboratory
                                                               9 Jan, 1997

             Conventions for the Use of HTTP for URN Resolution

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 21 July, 1997.

Abstract:
=========

The URN-WG was formed to specify persistent, location-independent names
for network accessible resources, as well as resolution mechanisms to retrive
the resources given such a name. At this time the URN-WG is considering
one particular resolution mechanism, the NAPTR proposal [1]. That proposal
specifies how a client may find a "resolver" for a URN, when the URN
does not contain a domain name for that resolver. A resolver is a database
that can tell the client where the resource is, can provide information (such
as a bibliographic citation) on the resource, or may even be able to provide
the resource itself to the client. While the NAPTR draft specifies how to
locate a resolver, it does not specify how the client should speak to the
resolver. Instead, the NAPTR draft provides a field that can be used to
specify the "resolution protocol" the client may use to speak to the
resolver.

This draft establishes conventions for using HTTP as one such resolution
protocol. It specifies how to encode URN resolution requests and responses
in HTTP 1.0 (and 1.1) requests and responses. Once a client has used
NAPTR records to locate a resolver that speaks the "http" resolution
protocol, these are the conventions it must follow. The primary goal of
this draft is to define a convention that is simple to implement
and will allow existing HTTP servers to easily add support for URN
resolution. We expect that the resolution databases that arise will be
useful when more sophisticated resolution protocols are developed later.

1.0  Introduction:
==================

The NAPTR draft[1] describes a way of using DNS to locate resolvers for
URIs.  That draft provides the services field to specify the "resolution
protocol" spoken by the resolver, as well as the "resolution services"
it offers. As of this writing, the "resolution protocols" allowed by the
NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow
over time). The NAPTR draft also lists a variety of resolution services,
such as N2L (given a URN, return a URL); N2R (Given a URN, return the
named resource), etc. This draft specifies the conventions to follow to
encode resolution service requests in the HTTP protocol, allowing
widely available HTTP daemons to serve as URN resolvers. This is the
specification to follow when the services field ina NAPTR record
begins with "http".

The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3]
specifications. Implementors of this specification should be familiar with
CGI scripts for database lookups.

2.0 General Approach:
=====================

The general approach used to encode resolution service requests in HTTP
is quite simple: 

    GET /uri-res/<service>/<uri>  HTTP/1.0

For example, if we have the URN "urn:cid:[email-masked]" and want a URL,
we would send the request:

    GET /uri-res/N2L/urn:cid:[email-masked] HTTP/1.0

Because of the character set limitations on URIs, we might wish to
encode the '@' character as its hex equivalent, thus the request would be

    GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0

The request could also be encoded as an HTTP 1.1 request. This would look
like:

    GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.1
    Host: <whatever host we are sending the request to>

Handling these requests on the server side is easy to implement in a
number of ways. The N2L request could be handled by a CGI script that
took the incoming URN, looked it up in a database, and returned the URL
as an HTTP redirect. Service requests like N2R or N2C could be set up
so that the daemon answered the request by returning files out of N2R/
and N2C/ directories, or they could also be handled by a script that
accessed a database of information.

One caveat should be kept in mind. The URN syntax draft[4] discusses
the notion of lexical equivalance. This means that two URIs are equivalent
under certain conditions of case-insensitivity and/or %encoding of characters.
Resolvers MUST return identical results for all lexically equivalent encodings
of a URI. For example, the requests below must return identical results:
    GET /uri-res/N2L/urn:cid:[email-masked] HTTP/1.0
    GET /uri-res/N2L/URN:CID:[email-masked] HTTP/1.0
    GET /uri-res/N2L/urn:cid:foo%40huh%2ecom HTTP/1.0

Responses from the HTTP server follow standard HTTP practice. Status
codes, such as 200 (OK) or 404 (Not Found) shall be returned.
The normal rules for determining cachability, negotiating formats, etc.
apply.

3.0 Service-specific details:
=============================

This section goes through the various resolution services established
in the URN services draft[5] and states how to encode each of them,
how the results should be returned, and any special status codes that
are likely to arise.

Unless stated otherwise, the HTTP requests are formed according to
the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response
is assumed to be an entity with normal headers and body unless stated
otherwise. (N2L is the only request that need not return a body).

3.1  N2L (URN to URL):
----------------------

The request is encoded as above. The URL MUST be returned in a Location:
header for the convienience of the user in the most common case of wanting
the resource. If the lookup is successful, a 30X status line SHOULD be
returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0
clients should be sent the 302 (Moved temporarily) status code unless the
resolver has particular resons for using 301 (moved permanently) or 304
(not modified) codes.

Note that access controls may be applied to this, or any other, resolution
service request. Therefore the 401 (unauthorized) and 403 (forbidden)
status codes are legal responses. The server may wish to provide a body
in the response to explain the reason for refusing access, and/or to provide
alternate information about the resource, such as the price it will cost
to obtain the resource's URL.

3.2  N2Ls (URN to URLs):
------------------------

The request is encoded as above. The result is a list of 0 or
more URLs. The Internet Media Type (aka ContentType) of the result
may be negotiated using standard HTTP mechanisms if desired. At a
minimum the resolver should support the text/uri-list media type.
(See Appendix A for the definition of this media type). That media
type is suitable for machine-processing of the list of URLs. Resolvers
may also return the results as text/html, text/plain, or any other
media type they deem suitable.

No matter what the particular media type, the result MUST be a list
of the URLs which 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].

If the client has requested the result be returned as text/html or
application/html, the result should be encoded as:
<UL>
<LI><A HREF="...url 1...">...url 1...</A>
<LI><A HREF="...url 2...">...url 2...</A>
 etc.
</UL>
where the strings ...url n... are replaced by the n'th URL in the list.

3.3  N2R (URN to Resource):
---------------------------

The request is encoded as above. The resource is returned using
standard HTTP mechanisms. The request may be modified using the
Accept: header as in normal HTTP to specify that the result
be given in a preferred Internet Media Type.

3.4  N2Rs (URN to Resources):
-----------------------------

This resolution service returns 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 request is encoded as above. The result shall be a MIME
multipart/alternative message with the alternative versions of the
resource in seperate body parts. If there is only one version of
the resource identified by the URN, it MAY be returned without the
multipart/alternative wrapper. Resolver software SHOULD look at the
Accept: header, if any, and only return versions of the resource
that are acceptable according to that header. 

3.5  N2C (URN to URC):
----------------------

URCs (Uniform Resource Characteristics) are descriptions of other
resources. This request allows us to obtain a description of the
resource identified by a URN, as opposed to the resource itself.
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 resolver to another.

The format of any response to a N2C request MUST be communicated using the
ContentType header, as is standard HTTP practice. The Accept: header
SHOULD be honored.

3.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 us obtain lists of URNs that
are believed equivalent at the time of the request. As the weathermap
example shows, some of the equivalances will be transitory, so the
standard HTTP mechanisms for communicating cachability MUST be honored.

The request is encoded as above. The result is a list of all the
URNs, known to the resolver, which identify the same resource as the
input URN. The result shall be encoded as for the N2Ls request
above (text/uri-list unless specified otherwise by an Accept: header).

3.7  L2Ns (URL to URNs):
----------------------

The request is encoded as above. The response is a list of any URNs
known to be assigned to the resource at the given URL. The result
shall be encoded as for the N2Ls and N2Ns requests.

3.8  L2Ls (URL to URLs):
------------------------

The request is encoded as described above. The result is a list of
all the URLs that the resolver knows are associated with the resource
located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns
requests.

3.9  L2C (URL to URC):
----------------------

The request is encoded as above, the response is the same as for the
N2C request.

Appendix A: The text/uri-list Internet Media Type
=================================================
[This appendix 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.

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

Appendix B:  n2l.pl script
==========================

This is a simple CGI script for the N2L resolution service. It
assumes the presence of a DBM database to store the URN to URL
mappings. This script does not specify standard behavior, it is
provided merely as a courtesy for implementors. In fact, this
script does not process incoming Accept: headers, nor does it
generate status codes. Such behavior should be part of a real
script for any of the resolution services.

    #!/bin/perl
    # N2L  - performs urn to url  resolution 

    $n2l_File = "...filename for DBM database...";

    $urn = $ENV{'PATH_INFO'} ;
    if(length($urn)<3)
    {
        $error=1;
    }

    if(!$error)
    {
        $urn =~s/^(\/)(urn:)?(.*)/$3/i;
        # Additional operations should be performed here
        # to convert lexically equivalent versions of a URI into
        # a canonical version for DB lookups.

        dbmopen(%lu,$n2l_File,0444);
        if($lu{$urn})
        {
        $url=$lu{$urn};
        print STDOUT "Location: $url\n\n";
        }else{
        $error=2;
        }
        dbmclose(%lu);
    }

    if($error)
    {
        print "Content-Type: text/html \n\n";
        print "<html>\n";
        print "<head><title>URN Resolution: N2L</title></head>\n";
        print "<BODY>\n";
        print "<h1>URN to URL resolution failed for the URN:</h1>\n";
        print "<hr><h3>$urn</h3>\n";
        print "</body>\n";
        print "</html>\n";
    }

    exit;

References:
===========

[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System", draft-ietf-urn-naptr-01.txt,
    November, 1996.

[2] RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee,
    R. Fielding, H. Frystyk, May 1996.

[3] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee,
    "Hypertext Transfer Protocol -- HTTP/1.1", draft-ietf-http-v11-spec-06,
    July 1996.

[4] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997.

[5] URN Resolution Services Draft -  (That document is in preparation.
    It will actually be strongly based on the content of this document and
    the NAPTR draft[1]). 

[6] 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.

Security Considerations
=======================
  Communications with a resolver may be of a sensitive nature. Some
  resolvers will hold information that should only be released to
  authorized users. The results from resolvers 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 rightsholders. Resolution
  requests may be of interest to traffic analysts. The requests may also
  be subject to spoofing.

  The requests and responses in this draft are amenable to encoding,
  signing, and authentication in the manner of any other HTTP traffic.

Author Contact Information:
===========================

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]

    This draft expires 21 July, 1997.
Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab, MS B287  voice: (505) 665-0597
Los Alamos National Laboratory     fax: (505) 665-4939
Los Alamos, NM, USA 87545         http://www.acl.lanl.gov/~rdaniel/
Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

From: "Ronald E. Daniel" <[email-masked]>
Date: Thu, 9 Jan 1997 10:52:13 -0700 (MST)
To: [email-masked]
Subject: [URN] next version of NAPTR
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Hi all,

Hope you had a happy holiday season. Now that I'm back at work,
I've edited the NAPTR and HTTP conventions drafts. The NAPTR draft
is appended, I'll send the HTTP conventions draft in a seperate
message. The new versions are also available from:
  http://www.acl.lanl.gov/URN/naptr.txt
  http://www.acl.lanl.gov/URN/http_res.txt

Old versions are available from
  http://www.acl.lanl.gov/URN/naptr-03.txt
  http://www.acl.lanl.gov/URN/http_res-00.txt
in case you care.

Some of the references need to be cleaned up - both drafts refer to
the URN Resolution Services draft we decided needed to be written.
Also, the NAPTR draft has a couple of other citations I have some
questions about. Other than that I think these are complete. Your
comments please!

Regards,
Ron
===================

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-naptr-02.txt                 Los Alamos National Laboratory
                                                          Michael Mealling
                                                   Network Solutions, Inc.
                                                             08 Jan., 1996

                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 14 July, 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).

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.

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 locating
resources on the Internet. 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. Every URI has a
colon-delimited prefix.  NAPTR resolution begins by taking this prefix,
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[3] 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.

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 [4]. 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[5], and
  their behavior in a particular resolution protocol will be given in
  the specification for that protocol (see [4] 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)[6]
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 [3] 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 [7]. 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 replacement
domain names. An additional difference will be illustrated later.

Example 2 
---------

Consider a URN namespace based on MIME Content-Ids. The URN might look
like this:
  
        urn:cid:[email-masked]
  
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:.+@([^@]+)$/\1/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 \1 part of the
substitution expression returns the string "mordred.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,
"mordred.gatech.edu").

While mordred could have its very own NAPTR, maintaining those records
on all the machines at a site as large as Georgia Tech would be an
intolerable burden. Instead, a wildcard may be used so that the domain
administrator at Georgia Tech has only a single NAPTR record to
maintain. That record 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.

(Unlike all the other example records in this draft, the one above
is the contents of a zone file, not the response received by the
client. That is so that the wildcard can be seen.)

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 \1 to extract a domain name
from the CID. There is a significant caveat about the use of
backslashes in DNS zone files. DNS treats backslashes as the escape
character so that '.' can be escaped when necessary. This means that
when a regular expression is entered into the zone file, the
backslashes 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 "/.+@([^@]+)/\\1/i".  When the client code actually
receives the record, the pattern will have been converted to
"/.+@([^@]+)/\1/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 104 [this is being changed, we believe it will be assigned 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[8]):

           service_field = [ [protocol] *("+" rs)]
           protocol      = "rcds" / "http" / "hdl" / "rwhois"
           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[6], hdl[9] (binary,
       UDP-based protocols),  http[4] (a textual, TCP-based protocol), and
       rwhois[10] (textual, UDP or 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 [5], 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. [4]). 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 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 [11], section 2.8.4)
  repl         = dns_str /  backref / repl dns_str  / repl backref
  dns_str      = ...... which RFC can I cite for this? 1035 seems obsolete .....
  backref      = "\" 1POS_DIGIT
  flags        = "i" 
  DNS_CHAR     = "_" / "0" / "1" / ... / "9" / "a" / ... / "z"
  POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref value

The result of applying the substitution expression to the original URI shall
be a legal domain name. Since it is possible for the regexp field to be
improperly specified, such that a non-conforming domain name can be
constructed, client software SHOULD verify that the result is a legal
domain 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-WG is discussing the use of international characters in URNs.
Regular expressions for strings in international character sets are likely
to 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) {
      sprintf(key, "%s.urn.net", extractNS(URN));  // prepend prefix to urn.net
      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'

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

References:
===========

[1] RFC-1737, "Functional Requirements for Uniform Resource Names", Karen
    Sollins and Larry Masinter, Dec. 1994.

[2] Urn implementors article in DLIB?
Perhaps
[2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming
    Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.

[3] RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)",
    A. Gulbrandsen and P. Vixie, October 1996.

[4] RFC-xxxx, "Conventions for the Use of HTTP for Resolution of URNs",
    Ron Daniel Jr., currently available as draft-ietf-urn-http-conv-01.txt,
    Dec. 1996.

[5] 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]).

[6] Keith Moore, "Resource Cataloging and Distribution Service", ???

[7] Paul Vixie, personal communication.

[8] RFC-822, "Standard for the Format of ARPA Internet Text Messages",
    Dave H. Crocker, August 1982.  

[9] Charles Orth, Bill Arms; Handle Resolution Protocol Specification,
    http://www.handle.net/docs/client_spec.html

[10] RFC-1714, "Referral Whois Protocol (RWhois)", S. Williamson and
     M. Kosters, November 1994.

[11] 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

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. 

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 14 July, 1997.

Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab, MS B287  voice: (505) 665-0597
Los Alamos National Laboratory     fax: (505) 665-4939
Los Alamos, NM, USA 87545         http://www.acl.lanl.gov/~rdaniel/
Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

From: "Ronald E. Daniel" <[email-masked]>
Date: Thu, 9 Jan 1997 10:26:55 -0700 (MST)
To: [email-masked]
Subject: [URN] http conventions draft version 01
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Hi,

I've made an editing pass through the HTTP conventions draft. The
new version (01) is appended. Also, you can fetch it from
http://www.acl.lanl.gov/URN/http_res.txt

Regards,
Ron

=================================

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-http-conv-01.txt             Los Alamos National Laboratory
                                                               9 Jan, 1997

             Conventions for the Use of HTTP for URN Resolution

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 21 July, 1997.

Abstract:
=========

The URN-WG was formed to specify persistent, location-independent names
for network accessible resources, as well as resolution mechanisms to retrive
the resources given such a name. At this time the URN-WG is considering
one particular resolution mechanism, the NAPTR proposal [1]. That proposal
specifies how a client may find a "resolver" for a URN, when the URN
does not contain a domain name for that resolver. A resolver is a database
that can tell the client where the resource is, can provide information (such
as a bibliographic citation) on the resource, or may even be able to provide
the resource itself to the client. While the NAPTR draft specifies how to
locate a resolver, it does not specify how the client should speak to the
resolver. Instead, the NAPTR draft provides a field that can be used to
specify the "resolution protocol" the client may use to speak to the
resolver.

This draft establishes conventions for using HTTP as one such resolution
protocol. It specifies how to encode URN resolution requests and responses
in HTTP 1.0 (and 1.1) requests and responses. Once a client has used
NAPTR records to locate a resolver that speaks the "http" resolution
protocol, these are the conventions it must follow. The primary goal of
this draft is to define a convention that is simple to implement
and will allow existing HTTP servers to easily add support for URN
resolution. We expect that the resolution databases that arise will be
useful when more sophisticated resolution protocols are developed later.

1.0  Introduction:
==================

The NAPTR draft[1] describes a way of using DNS to locate resolvers for
URIs.  That draft provides the services field to specify the "resolution
protocol" spoken by the resolver, as well as the "resolution services"
it offers. As of this writing, the "resolution protocols" allowed by the
NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow
over time). The NAPTR draft also lists a variety of resolution services,
such as N2L (given a URN, return a URL); N2R (Given a URN, return the
named resource), etc. This draft specifies the conventions to follow to
encode resolution service requests in the HTTP protocol, allowing
widely available HTTP daemons to serve as URN resolvers. This is the
specification to follow when the services field ina NAPTR record
begins with "http".

The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3]
specifications. Implementors of this specification should be familiar with
CGI scripts for database lookups.

2.0 General Approach:
=====================

The general approach used to encode resolution service requests in HTTP
is quite simple: 

    GET /uri-res/<service>/<uri>  HTTP/1.0

For example, if we have the URN "urn:cid:[email-masked]" and want a URL,
we would send the request:

    GET /uri-res/N2L/urn:cid:[email-masked] HTTP/1.0

Because of the character set limitations on URIs, we might wish to
encode the '@' character as its hex equivalent, thus the request would be

    GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0

The request could also be encoded as an HTTP 1.1 request. This would look
like:

    GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.1
    Host: <whatever host we are sending the request to>

Handling these requests on the server side is easy to implement in a
number of ways. The N2L request could be handled by a CGI script that
took the incoming URN, looked it up in a database, and returned the URL
as an HTTP redirect. Service requests like N2R or N2C could be set up
so that the daemon answered the request by returning files out of N2R/
and N2C/ directories, or they could also be handled by a script that
accessed a database of information.

One caveat should be kept in mind. The URN syntax draft[4] discusses
the notion of lexical equivalance. This means that two URIs are equivalent
under certain conditions of case-insensitivity and/or %encoding of characters.
Resolvers MUST return identical results for all lexically equivalent encodings
of a URI. For example, the requests below must return identical results:
    GET /uri-res/N2L/urn:cid:[email-masked] HTTP/1.0
    GET /uri-res/N2L/URN:CID:[email-masked] HTTP/1.0
    GET /uri-res/N2L/urn:cid:foo%40huh%2ecom HTTP/1.0

Responses from the HTTP server follow standard HTTP practice. Status
codes, such as 200 (OK) or 404 (Not Found) shall be returned.
The normal rules for determining cachability, negotiating formats, etc.
apply.

3.0 Service-specific details:
=============================

This section goes through the various resolution services established
in the URN services draft[5] and states how to encode each of them,
how the results should be returned, and any special status codes that
are likely to arise.

Unless stated otherwise, the HTTP requests are formed according to
the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response
is assumed to be an entity with normal headers and body unless stated
otherwise. (N2L is the only request that need not return a body).

3.1  N2L (URN to URL):
----------------------

The request is encoded as above. The URL MUST be returned in a Location:
header for the convienience of the user in the most common case of wanting
the resource. If the lookup is successful, a 30X status line SHOULD be
returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0
clients should be sent the 302 (Moved temporarily) status code unless the
resolver has particular resons for using 301 (moved permanently) or 304
(not modified) codes.

Note that access controls may be applied to this, or any other, resolution
service request. Therefore the 401 (unauthorized) and 403 (forbidden)
status codes are legal responses. The server may wish to provide a body
in the response to explain the reason for refusing access, and/or to provide
alternate information about the resource, such as the price it will cost
to obtain the resource's URL.

3.2  N2Ls (URN to URLs):
------------------------

The request is encoded as above. The result is a list of 0 or
more URLs. The Internet Media Type (aka ContentType) of the result
may be negotiated using standard HTTP mechanisms if desired. At a
minimum the resolver should support the text/uri-list media type.
(See Appendix A for the definition of this media type). That media
type is suitable for machine-processing of the list of URLs. Resolvers
may also return the results as text/html, text/plain, or any other
media type they deem suitable.

No matter what the particular media type, the result MUST be a list
of the URLs which 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].

If the client has requested the result be returned as text/html or
application/html, the result should be encoded as:
<UL>
<LI><A HREF="...url 1...">...url 1...</A>
<LI><A HREF="...url 2...">...url 2...</A>
 etc.
</UL>
where the strings ...url n... are replaced by the n'th URL in the list.

3.3  N2R (URN to Resource):
---------------------------

The request is encoded as above. The resource is returned using
standard HTTP mechanisms. The request may be modified using the
Accept: header as in normal HTTP to specify that the result
be given in a preferred Internet Media Type.

3.4  N2Rs (URN to Resources):
-----------------------------

This resolution service returns 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 request is encoded as above. The result shall be a MIME
multipart/alternative message with the alternative versions of the
resource in seperate body parts. If there is only one version of
the resource identified by the URN, it MAY be returned without the
multipart/alternative wrapper. Resolver software SHOULD look at the
Accept: header, if any, and only return versions of the resource
that are acceptable according to that header. 

3.5  N2C (URN to URC):
----------------------

URCs (Uniform Resource Characteristics) are descriptions of other
resources. This request allows us to obtain a description of the
resource identified by a URN, as opposed to the resource itself.
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 resolver to another.

The format of any response to a N2C request MUST be communicated using the
ContentType header, as is standard HTTP practice. The Accept: header
SHOULD be honored.

3.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 us obtain lists of URNs that
are believed equivalent at the time of the request. As the weathermap
example shows, some of the equivalances will be transitory, so the
standard HTTP mechanisms for communicating cachability MUST be honored.

The request is encoded as above. The result is a list of all the
URNs, known to the resolver, which identify the same resource as the
input URN. The result shall be encoded as for the N2Ls request
above (text/uri-list unless specified otherwise by an Accept: header).

3.7  L2Ns (URL to URNs):
----------------------

The request is encoded as above. The response is a list of any URNs
known to be assigned to the resource at the given URL. The result
shall be encoded as for the N2Ls and N2Ns requests.

3.8  L2Ls (URL to URLs):
------------------------

The request is encoded as described above. The result is a list of
all the URLs that the resolver knows are associated with the resource
located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns
requests.

3.9  L2C (URL to URC):
----------------------

The request is encoded as above, the response is the same as for the
N2C request.

Appendix A: The text/uri-list Internet Media Type
=================================================
[This appendix 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.

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

Appendix B:  n2l.pl script
==========================

This is a simple CGI script for the N2L resolution service. It
assumes the presence of a DBM database to store the URN to URL
mappings. This script does not specify standard behavior, it is
provided merely as a courtesy for implementors. In fact, this
script does not process incoming Accept: headers, nor does it
generate status codes. Such behavior should be part of a real
script for any of the resolution services.

    #!/bin/perl
    # N2L  - performs urn to url  resolution 

    $n2l_File = "...filename for DBM database...";

    $urn = $ENV{'PATH_INFO'} ;
    if(length($urn)<3)
    {
        $error=1;
    }

    if(!$error)
    {
        $urn =~s/^(\/)(urn:)?(.*)/$3/i;
        # Additional operations should be performed here
        # to convert lexically equivalent versions of a URI into
        # a canonical version for DB lookups.

        dbmopen(%lu,$n2l_File,0444);
        if($lu{$urn})
        {
        $url=$lu{$urn};
        print STDOUT "Location: $url\n\n";
        }else{
        $error=2;
        }
        dbmclose(%lu);
    }

    if($error)
    {
        print "Content-Type: text/html \n\n";
        print "<html>\n";
        print "<head><title>URN Resolution: N2L</title></head>\n";
        print "<BODY>\n";
        print "<h1>URN to URL resolution failed for the URN:</h1>\n";
        print "<hr><h3>$urn</h3>\n";
        print "</body>\n";
        print "</html>\n";
    }

    exit;

References:
===========

[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System", draft-ietf-urn-naptr-01.txt,
    November, 1996.

[2] RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee,
    R. Fielding, H. Frystyk, May 1996.

[3] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee,
    "Hypertext Transfer Protocol -- HTTP/1.1", draft-ietf-http-v11-spec-06,
    July 1996.

[4] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997.

[5] URN Resolution Services Draft -  (That document is in preparation.
    It will actually be strongly based on the content of this document and
    the NAPTR draft[1]). 

[6] 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.

Security Considerations
=======================
  Communications with a resolver may be of a sensitive nature. Some
  resolvers will hold information that should only be released to
  authorized users. The results from resolvers 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 rightsholders. Resolution
  requests may be of interest to traffic analysts. The requests may also
  be subject to spoofing.

  The requests and responses in this draft are amenable to encoding,
  signing, and authentication in the manner of any other HTTP traffic.

Author Contact Information:
===========================

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]

    This draft expires 21 July, 1997.

Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab, MS B287  voice: (505) 665-0597
Los Alamos National Laboratory     fax: (505) 665-4939
Los Alamos, NM, USA 87545         http://www.acl.lanl.gov/~rdaniel/
Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

From: "Ronald E. Daniel" <[email-masked]>
Date: Wed, 8 Jan 1997 16:38:27 -0700 (MST)
To: [email-masked]
Subject: [URN] naptr draft URL
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

The latest version of the naptr draft is also available at
http://www.acl.lanl.gov/URN/naptr.txt
and at
http://www.acl.lanl.gov/URN/naptr-04.txt

(The reason for the -04 in the filename while the draft itself
says -02 is that the first two versions were individual submissions,
while the subsequent versions have been the product of the URN-WG).

Regards,
Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab           voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011         fax: (505) 665-4939
Los Alamos National Lab           http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    obscure_term: "hypernym"

Date: Wed, 08 Jan 1997 16:25:21 -0700
To: [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: [URN] NAPTR draft - version 2
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Hi,

Here is the NAPTR draft, with edits to incorporate the comments from
the San Jose meeting. There are two references that need to be
cleaned up, other than that I think it is ready to go. Your comments
please!

Regards,
Ron
===========

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-naptr-02.txt                 Los Alamos National Laboratory
                                                          Michael Mealling
                                                   Network Solutions, Inc.
                                                             08 Jan., 1996

                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 14 July, 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).

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.

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 locating
resources on the Internet. 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. Every URI has a
colon-delimited prefix.  NAPTR resolution begins by taking this prefix,
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[3] 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.

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 [4]. 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[5], and
  their behavior in a particular resolution protocol will be given in
  the specification for that protocol (see [4] 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)[6]
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 [3] 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 [7]. 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 replacement
domain names. An additional difference will be illustrated later.

Example 2 
---------

Consider a URN namespace based on MIME Content-Ids. The URN might look
like this:
  
        urn:cid:[email-masked]
  
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:.+@([^@]+)$/\1/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 \1 part of the
substitution expression returns the string "mordred.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,
"mordred.gatech.edu").

While mordred could have its very own NAPTR, maintaining those records
on all the machines at a site as large as Georgia Tech would be an
intolerable burden. Instead, a wildcard may be used so that the domain
administrator at Georgia Tech has only a single NAPTR record to
maintain. That record 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.

(Unlike all the other example records in this draft, the one above
is the contents of a zone file, not the response received by the
client. That is so that the wildcard can be seen.)

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 \1 to extract a domain name
from the CID. There is a significant caveat about the use of
backslashes in DNS zone files. DNS treats backslashes as the escape
character so that '.' can be escaped when necessary. This means that
when a regular expression is entered into the zone file, the
backslashes 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 "/.+@([^@]+)/\\1/i".  When the client code actually
receives the record, the pattern will have been converted to
"/.+@([^@]+)/\1/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 104 [this is being changed, we believe it will be assigned 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[8]):

           service_field = [ [protocol] *("+" rs)]
           protocol      = "rcds" / "http" / "hdl" / "rwhois"
           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[6], hdl[9] (binary,
       UDP-based protocols),  http[4] (a textual, TCP-based protocol), and
       rwhois[10] (textual, UDP or 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 [5], 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. [4]). 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 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 [11], section 2.8.4)
  repl         = dns_str /  backref / repl dns_str  / repl backref
  dns_str      = ...... which RFC can I cite for this? 1035 seems obsolete .....
  backref      = "\" 1POS_DIGIT
  flags        = "i" 
  DNS_CHAR     = "_" / "0" / "1" / ... / "9" / "a" / ... / "z"
  POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref value

The result of applying the substitution expression to the original URI shall
be a legal domain name. Since it is possible for the regexp field to be
improperly specified, such that a non-conforming domain name can be
constructed, client software SHOULD verify that the result is a legal
domain 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-WG is discussing the use of international characters in URNs.
Regular expressions for strings in international character sets are likely
to 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) {
      sprintf(key, "%s.urn.net", extractNS(URN));  // prepend prefix to urn.net
      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'

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

References:
===========

[1] RFC-1737, "Functional Requirements for Uniform Resource Names", Karen
    Sollins and Larry Masinter, Dec. 1994.

[2] Urn implementors article in DLIB?
Perhaps
[2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming
    Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.

[3] RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)",
    A. Gulbrandsen and P. Vixie, October 1996.

[4] RFC-xxxx, "Conventions for the Use of HTTP for Resolution of URNs",
    Ron Daniel Jr., currently available as draft-ietf-urn-http-conv-01.txt,
    Dec. 1996.

[5] 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]).

[6] Keith Moore, "Resource Cataloging and Distribution Service", ???

[7] Paul Vixie, personal communication.

[8] RFC-822, "Standard for the Format of ARPA Internet Text Messages",
    Dave H. Crocker, August 1982.  

[9] Charles Orth, Bill Arms; Handle Resolution Protocol Specification,
    http://www.handle.net/docs/client_spec.html

[10] RFC-1714, "Referral Whois Protocol (RWhois)", S. Williamson and
     M. Kosters, November 1994.

[11] 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

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. 

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 14 July, 1997.

Ron Daniel Jr.                       email: [email-masked]
Advanced Computing Lab,  MS B287     voice: +1 505 665 0597
Los Alamos National Laboratory         fax: +1 505 665 4939
Los Alamos, NM, USA  87545            http://www.acl.lanl.gov/~rdaniel/
 Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

Date: Tue, 07 Jan 1997 13:02:04 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Proposed URN Syntax Draft changes to align with URL syntax draft
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Ryan Moats wrote:
> 
> Folks-
> 
> There have been some good comments about the syntax draft and some
> good stuff coming out of meshing it with the URL syntax, so I am
> planning the following (i.e. you have been warned!).
> 
> There will be another pre-release of syntax-02 coming out on
> 12/26 ( Holidays, what are Holidays ;-} ).  The target is to
> have -02 be sent to the i-d editors on 1/6/97.
> 
> This way folks (who don't have anything else to do between 12/25
> and 1/1) can read the new version...

Well, here we are in the week of 1/6/97 and some issues have come up
vis-a-vie the URL syntax document.  Here are the technical issues (as I
see them, and I've probably missed/ignored some):

1. The URN syntax is more restrictive in the types of characters
allowed vis-a-vie the URL syntax.  Specifically, the characters
";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format)
in the URL syntax while not in the URN syntax.

2. The URL syntax document makes a claim that the its syntax is the
syntax for URIs in general so that URNs may be used in any data field
that might otherwise hold a URL.

I'll admit that there are a lot of political issues that I am ignoring
for now, but I want to see if we can move forward with the technical
issues.

My current thoughts are to move the characters in note 1 above from the
excluded character set to the allowed character set to more closely
align the URN and URL character sets.  IF SOMEONE THINKS THIS IS A BAD
IDEA THIS IS A GOOD TIME TO LET ME KNOW!

Issue 2 is handled (I believe) by adding an appendix to the URN syntax
document that covers how a URL resolver should react to a URN. My
proposal is that the URN be considered an opaque URL that gets handed
off to a URN resolver. There are alternate solutions, but they become
progressively more ugly.

Note that issues 1 and 2 are somewhat independent.  Given the current
allowed characters and the above suggested appendix, any URN could be
used in place of a URL.  

Although I've considered it in the past, I think that defining URN's as
a URL "scheme" is a less optimal solution than the above proposals.

Obviously, I am soliciting input to try and gain an idea about consensus
(and fairly quickly, too).

Ryan