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

On Feb 14, 2005, at 6:34 AM, Didier PH Martin wrote:
> It could be rigorously the same if we want to as it is often the case 
> with
> technical solutions. This said, here are the differences if well done:
>
> a) The URN schema could be resolved with a DNS entry. This latter 
> contains
> both the location and the name. In fact, this is what is really 
> happening
> today with a URL being transformed into an IP. Its only that in the 
> case of
> a URN both entries are of higher level not directly related to an IP 
> address but more to a URL.

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.

> B) in the case you illustrated, there is a URL to URL locator. This is
> basically what we have today with indirections. However, the drawback 
> is
> that the real thing is hidden; your front end is a single place and
> therefore has a single point of failure, a bad name resolution 
> mechanism
> indeed. On the other hand, a URN, if resolved with a DNS do not share 
> the
> same flaw of a single point of failure.

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

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

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

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

>> Feel free to repeat yourself as often as you like -- deployment
>> experience has so far proven you wrong.
>
> Roy, this is social factor, not technology. In the 90s people invested 
> in
> stock really overvalued. They did that in the past with cars, tulips,
> electricity, radio, etc... A winning technology is not necessarily the 
> best
> one, only the one accepted by most of the people. It may change 
> overtime as
> people learn; it may change because of a paradigm shift or any other 
> social
> reason. Some people may find themselves in a minority when they use a
> superior technology at first like, for instance, using a car instead 
> of a
> horse. Even if the horses are at that moment the best deployment 
> experience
> doesn't necessarily means that it's the best technology answering a
> particular need. Bad example Roy, you use the argument of social 
> acceptance,
> not a sound scientific argument.

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.

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

....Roy

Received on Monday, 14 February 2005 19:16:35 UTC