Re: [URN] Re: Relative URLs and URNs

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