RE: I-D ACTION:draft-hendrikx-wallis-urn-nzl-00.txt

Hello Roy,

> It could be, if the URN is tied to DNS and the people who mint the
> URNs also have control over the associated DNS zone file.  If that
> system were deployed, it would make a URN a locator with DNS as
> its resolution mechanism.  I see no difference between that and
> existing URI schemes aside from deployment.

You are absolutely right, people extended the actual URL schema to do what
they want. Other prefers to use a different specification which explains
what a Uniform Resource Name is. A matter of choice. Exactly like before
when we used OID or UUID to identify a resource on a net (ref: CORBA, DCOM,
OSF PRC, ONC). Again, it's a matter of choices. The URN schema is more
flexible than the URL schema. We can use other naming convention than the
strict "/" delimitated path. There is obviously the procrustean resolution
mechanism and fit everything into URL or to allow alternative naming
schemas. URNs are simply more versatile than URLs. 

> I don't follow that reasoning at all.  An http URI based on a DNS
> hostname will indirect via common-place DNS address records and
> depend on the addresses returned (any modern CDN can remove the
> single points of failure for you). A URN resolved with DNS depends
> on specially-crafted zone files and extended record caching, such
> that it is dependent on each name server contacted.  To remove the
> single points of failure from that system requires every local
> name server to be upgraded in addition to special-purpose DNS
> load balancing (caching the entire DNS response instead of just
> the addresses+TTL).

Yes to resolve URNs with DNS you need to allow clients to dynamically change
the record involved in the URN/URL translation. Then you may need a URL/IP
translation. I agree with you, this involves two queries. Then some may be
tempted to use URN/IP direct translation. Not a big advantage I concede. It
remains the flexibility of the URN scheme in terms of naming convention left
to the namespace administrator. Could be useful to port some actual naming
convention on the web like for instance the facetted classification
convention, the ISBN convention and so on and so forth. Otherwise they will
have to retrofit their actual naming convention into the URL schema: a
procrustean mechanism.  

> 
> > C) The information conveyed by the URN is as follow: the namespace is
> > owned
> > or is part of a name space identifier. Then all the names after that
> > can
> > follow different conventions as stated by the name space provider. It
> > could
> > be as well urn:nzl:registration(dogs)-1.0
> 
> Likewise for http URIs.

Off course, since a both URLs and URNs are URIs.

> 
> > D) Social factor: They increased their chances that people won't
> > associate
> > the URN to a document located on the web.
> 

> That is true, and I consider it to be a negative difference.

You are probably right for the web in general and probably wrong in some
niche markets where porting their actual naming convention is an advantage.


> 
> > Bottom line: a name has nothing to do with a
> > location. It could be resolved to a location if the named thing is
> > locatable
> > on the net but this is not a necessity. It's a name. In contrast, a
> > locator
> > tells me _where_ (i.e. the location) is located something. It's all a
> > matter
> > of semantics.
> 
> Sure, but if the thing being named is information that will be
> used in an information system, isn't it natural to conclude that
> it will be used as more than just a name?  Isn't it easier to simply
> use an existing information system with names that are every bit as
> persistent as any system based on URNs-as-locators?

Or we can look at it as they use their naming convention for off the web and
still use the same for online access. Otherwise it requires to modify the
naming convention for on-off line. For instance, take the following book
naming convention ISBN: 0066214130. Any onfo about this book but this time
on-line could be referred as urn:isbn:0066214130 or in a URL schema as:
http://www.amazon.com/exec/obidos/tg/detail/-/0066214130/ref=pd_nfy_gw_nr/00
2-9269393-1065606?v=glance as actually used by Amazon. The former is more
uniform for off-on line reference. Like I said, URNs are superior in certain
niche market. Books are a good example of that. Now, can we say that from
the social point of view one is easier to remember than the other? Maybe for
some autistic persona but probably not for most of the people. So, we can
say that in our last example, at least we have some consistency on "naming"
things by keeping their name on both the on and off line world. Can URNs
support all naming conventions. In its actual incarnation, no, and this is
maybe the main criticism we can have about it.

> I did not intend it to be scientific.  There were many naming systems
> that predated the Web and many that have been defined since the Web,
> but none of them have succeeded beyond the scope of a limited group
> of people who either were not given a choice or who whose grant
> money was tied to their use.  Metcalfe's Law is at best a principle
> of economics, not a scientific argument, yet we have all seen it
> in practice.  I didn't say that the Web is perfect -- I said that
> the Web is already deployed and already performs the only service
> that they need.

You are right, the web does a good but still partial job. It also needs to
be improved. We just increased the reach and this not totally due to the
technological merits. Do we should stick to the same web as today with all
its goodness and limitations? Some are trying to go beyond its current
limitations and make it evolve.

> 
> >  This is not a problem
> >> that technology can solve, and so far the most persistent names
> >> on the Internet are the ones that have the most usefulness.
> >> Personally, I think my 12 years studying this particular problem
> >> is more than sufficient to reach a conclusion, but you are free
> >> to disagree with any of my conclusions.
> >
> > Roy, this time you use the authority argument.
> 
> I merely responded to your ridiculous suggestion that I should
> look at the problem again, completely ignoring the fact that I just
> spent three years revising the URI specification and working on
> Webarch (not to mention all of the other times I've written about
> it going all the way back to MOMspider).  I am just trying to save
> them from the same costly mistake made by dozens of others.

So, all your arguments are based on the deep investment you did on this
schema. It's understandable then.... It's not the first time I see that in
both the scientific and technological worlds. I also did the same error in
the past sometimes. It's human, I can understand that. However, why the URNs
would be a so bad enemy? It's a URI with its own advantages and limitations.
It represents the advantage of allowing to port existing naming conventions.
The other didn't necessarily made mistakes, it was simply that the social
and economical situation was totally different than what made the web
possible. Its even possible that these "mistakes" come back this time
adapted to the new network realities just to resolve the actual "mistakes"
that people are doing today. So let's call them simply "solutions" and let's
not get our ego in the way Roy.

I was too resistant to the URNs at first, but when I met with librarians and
when they told me about the problem of adapting the facetted classification
to the web I started to see that some niche need a naming convention adapted
to their reality. The melting pot is not always the best solution Roy even
if it is tempting at first sight to resolve the Babel tour syndrome. 

Look at the following URL and think if it makes it easier to locate or name
something. Does it have any innate characteristics to make it easier to
remember?


http://www.amazon.com/exec/obidos/tg/detail/-/0066214130/ref=pd_nfy_gw_nr/00
2-9269393-1065606?v=glance

And in which ways it is superior to 

urn:isbn:0066214130 ?

Cheers
Didier PH Martin

Received on Monday, 14 February 2005 21:07:00 UTC