Re: [URN] About realtive URNs

Ron Daniel, Jr. writes:
 > As several people on this list know, I'm not a big fan of relative
 > URNs. However, I think they are pretty much unavoidable.

Your statement that relative URNs are unavoidable is news to me, and
I'm curious why you think that is so.

 > There are about three conditions I would like to see fullfilled by
 > any relative URN scheme.

 >   1) Unambiguous determination of the base URN

No problem.  This is well defined by the relative URI document with
the one clarification (that I mentioned previously) that the default
base URI for a document, if not specified by the document or the
delivery package of the document, is the last URI known by the client
in accessing the document, not the first URI.

This means that if the client uses a proxy is in resolving a URI and
the proxy receives a redirection to another URI, then the proxy must
return that redirection URI to the client whether or not the proxy also
follows the redirection to continue the resolution itself.  I expect
that HTTP proxies behave this way already since redirections are
already in widespread use.

BTW, this same requirement is also important even if there are no
relative URNs.  If a URN is redirected to a URL, and the URL is
resolved to a document containing relative URIs, then they are
relative to the URL (if the base is not otherwise specified), not the
URN.

 >   2) Allowing some namespaces to say that they are not to be processed
 >      as relative URNs.

No problem.  If naming authorities never use unencoded '/' in any
identifier that is registered, then there is never any chance of it
allowing relative URNs, is there?

 >   3) Using the same rules for building relative URNs as are used for
 >      relative URLs.  (This one is a pragmatic concern, not a principle).

Absolutely.

 > I am not so sure how to handle relative URNs when the document does not
 > cleary indicate one and only one base identifier. Dan has put up the
 > rules for resolving relative URLs before, we need to make sure they
 > will generalize to different protocols in the future. If we can't come
 > up with rules that can guarantee unique base IDs, then we are
 > begging for trouble with relative URNs.

I believe that the above clarification should be sufficient.

 > Some namespaces may hide a hierarchical structure. If they are hiding it,
 > we should not presume to make them expose it. I think that if we are to
 > have relative URNs, some namespaces should be able to say not to ever
 > try to build a URN in that namespace using relative processing rules.
 > This means that they can't use unencoded '/' characters, and the document
 > specifying such a namespace needs to say that they are not to be handled
 > in a relative manner.

Actually, I think it might be possible to allow unencoded '/' in
identifiers without any implication of support for relative URIs.  The
author of a document should know what base URI is intended to be used
with any relative URIs that the author puts in the document.  Any
other relative URIs that are not "published" by the author would be
mere guesses on the part of users.  Unless we require servers to
provide some non-trivial response to requests for any '/'-terminated
prefix of a URI, then there does not appear to be any requirement that
the existence of '/'s in an identifier means anything.  The only
context in which '/' in an identifier means anything (currently) is if
the identifier is used as a base URI *and* there are relative URIs
that are relative to that base.

There might be another context in which '/' has meaning.  Security
realms are relative to directories.  So two URIs with the same
'/'-terminated prefix may be identifiers for resources contained in
the same security realm, and clients may cache security info relative
to that realm.  I'm not clear on whether this is the case or where it
is specified.

As much as I've argued above that '/' doesn't mean much (currently),
I'd also argue that it should be reserved to mean only things relative
to hierarchical contexts.

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

Received on Thursday, 1 May 1997 11:02:08 UTC