Re: [URN] Re: Relative URLs and URNs

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

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

Many thanks for the clarification. This means that *if* you have
some kind of resolution chain, then it is the last result in this
chain that is relevant. So in the case of a simple resolution chain
URN -> URL -> Resource, this means that it's the URL, and not
the URN, that is used for relative operation. This, and the
fact that you always can specify the base of the relative operations
with <BASE>, means that you always have a way out.

Now the next question is: What happens if resolution is "direct",
and the original URN becomes the base of relative operations?
Actually, that might not be as bad as some of us think. First,
relative operations are purely syntactical, so the client will
just chop off on the URN and either construct something (or get
stuck). This is actually in contrast with what Daniel suggests
or supposes in some of his mails, namely that the browser is using
some knowledge about the hierarchy for retrieval: It doesn't
presently for URLs.

Second, the document provider, which may not be identical
to the URN provider, but anyway has to be somewhat related to it,
and is certainly lumped together with it by the user on the client
side, has control over what the base of the document will be, and
knows whether the base, concatenated (more or less) with the
relative references in the document, lead to sensible things
(whether they be URLs or URNs).

Third, a spec for a certain scheme says whether this scheme is
generic or not, but the relativity processing machinery of the
client doesn't need to know. If it sees a relative reference
(no "urn:" prefix nor any scheme prefix and so on), and has
to resolve it, it just works ahead with the base and produces
something according to well-defined rules. If some HTML document
has <BASE HREF="mailto:[email protected]">, and a relative reference
HREF="aaa/bbb", the client will just come up with a mailtool
for aaa/bbb (at least that was what I got on my few tests),
which means that it has, hopefully according to some provisions
in the relative URL spec, constructed an URL of mailto:aaa/bbb.

Fourth, the "/" is reserved for hierarchy (and nothing else)
according to RFC 1630, but not so according to RFC 1738.
An opaque scheme can use the "/" for whatever it wants.
Of course, this might not be a good idea because it might
give the impression of hierarchy where there is none, but
it's not a problem.

So for URN syntax and stuff, this may have the interesting
consequence that we don't really have to worry about it :-).
If an URN namespace wants to use the "/", for whatever purpose,
it can do so. If an URN producer wants to produce URNs with
a slash in them, (s)he may do so, given that the namespace
allows it (or may have to use slashes if the namespace requires it).
If a content provider wants to take advantage of hierarchical
resolution, (s)he may do so given that the URIs that will be
produced after the prescribed syntactical operations refer
to the intended resource.

The whole thing actually works on Netscape (Sun and Mac)
and probably on other browsers. For a document with
<BASE HREF="urn:isbn:xyz/"> and a link with <A HREF="abc/def">
I get the error:
	URN's not internally supported,
	use an HTTP proxy server: urn:isbn:xyz/abc/def
This, apart from the "'" in "URN's", makes good sense with
respect to the above.

So for Daniel, this means that the idea of having path:
and http: in parallel will work. But the idea of a client
using the relative structure to find something more quickly
will not work (it might work on a resolver close to the client,
and for a certain namespace, though).

For those that are sceptical with respect to relative namespaces,
it means just not to allow slashes in your namespace or your URNs.

For the syntax document, it means that "/" can be a character like
e.g. a letter, without any special provisions. If it's used in
a reserved function in a namespace, and this namespace has the
requirement to encode it in functions other than the reserved
function, it has to be escaped, as is the case for other characters.

We would have to add that in terms of relative addressing, URNs
are treated in the same way as URLs (if they ever have to be
treated that way).

The only thing that is not clear to me currently is what happens
with the "#". This is more dangerous than "/" because a "#" actually
means "don't send the part after me to the resolver", which is not
the thing that an average URN scheme might want to happen.
The examples I have just tested with my browser (where the part
after the "#" actually does get sent off sometimes), and my understanding
of relative processing are not as thourough to make any conclusions
on this issue. Another thing that might get in the way of "relative
URNs" is the second ":". In simple cases, it seems to work, but
I don't know about more complicated cases.


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

Agreed.


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

If that is done, it will be scheme/namespace-specific. Currently,
the closest thing to this is the ftp: scheme, where you *could* have
a connection open over subsequent downloads and move across the
directories with "cd" commands. It's not possible now with URLs
to deduce some "localized" information just from the fact that
an URL contains some slashes. We shoudn't try to introduce such
an assumption for URNs, where relativity seems to have less merrit
than for URLs.


> 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

So no distribution is preferable to random distribution which is
preferable to organized distribution? Why then do you stress
organised distribution so much?
 


Regards,	Martin.