Re: "resolution mechanism"

> The problem is not a protocol to be able to resolve any URI.
> The problem is to give something an identifier which can later
> be resolved.  The appropriate scheme is http.

HTTP is good for many things, but URNs were specifically designed 
to handle cases for which HTTP URLs were observed to not work well 
in practice.  In particular, there are cases for which it's more 
important to have a long-term persistent name for a resource than 
it is to make that resource universally accessable using that name.

Can HTTP URIs be made reasonably stable?  Yes, but it's difficult
to guarantee stability of HTTP URIs, since they depend on DNS names 
which are subject to change for reasons outside your control.
If you want to make your HTTP URIs stable then you need to avoid 
embedding any information in the content or structure of those URIs 
that is likely to need to change.  That includes your company name,
the organization of the files on your server, etc.  Yes, you can 
sometimes use HTTP redirects to make old URIs work, but frankly,
even the HTTP protocol portion of the URI is suspect.  Not everyone 
thinks that it's a good idea to tie a resource name to a particular 
protocol, or to make a long-term committment to providing access 
(or even redirects) to such resources via any particular protocol.

Is it reasonable to expect random HTTP URIs to be stable?
Absolutely not, and it probably never will be.

Will URNs ever intended to replace HTTP, or could they ever do so?  
Of course not.  They were designed for very different purposes.

It's not as if everyone who uses URIs is trying to solve the same
problem.  For many applications, universal access in the short-term 
is more important than stability of the name-to-resource binding in
the long-term (decades or more).  For a few applications, the opposite
is true.  Folks who assign resource names should attempt to understand
the characteristics of both HTTP URIs and URNs and use whichever one
is appropriate to their application (or in some cases, both).  Most 
folks quite reasonably choose HTTP, but that doesn't mean it's the
best choice in all cases.  In particular, folks who do cataloging 
and archiving understand why URNs are designed the way they are, 
and tend to be more receptive to them.


> Don't use URNs.  They don't have a protocol.  

Of course URNs don't have "a" protocol.  They were specifically 
designed to be independent of any protocol - and with the explicit
assumption that multiple resolution protocols were inevitable.

Keith

Received on Friday, 12 April 2002 11:09:56 UTC