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

Hello Roy

> Please show me the location in
> 
>     http://registry.govt.nz/dogs/registration/1-0
> 
> that is somehow not present in
> 
>     urn:nzl:govt:registering:dogs:registration:1-0

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.

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.

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 

D) Social factor: They increased their chances that people won't associate
the URN to a document located on the web. A locator indicates that you will
locate something. A name simply tells you its name, not its location. For
instance, Roy Fielding as a name do not convey where you live. You email
address or physical address does. Roy is you name, a way to hopefully give
you a unique identity (hard to do, there is a possibility of more than one
Roy Fielding - as I discovered myself that there is more than one Didier
Martin writing books :-). 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.

> Apparently, you haven't read the URN requirements document.

Yes I did. And if you look back to the archives, I even participated to the
workgroup a couple of year ago. During this time I had the occasion to
learn, share and evolve on the matter of name, location, etc.. I was coming
from the research field on distributed computing and knew that a good
distributed computing architecture is dependent on a good name service. So,
be precise in what way I haven't read or as you maybe implied what I didn't
understood in the documents. Is this the URN part or the URN to URL
resolution using the DNS record part? Let's go beyond preconceived ideas
here.

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

 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. So if would use the same one
I would say that you have half the number of years than me thinking about
the same issues. I prefer not to use that kind of argument. A quality of
aging is to gain also wisdom Roy.

Going back to the real stuff and going beyond all the classical reflection
flaws:

a) We may say that their naming convention is not well designed: in that
case to say why (Potential collisions with other names, lack of a serious
registration process, etc...) To say something intelligent about this I
would need to think more about their context, usage, process, etc...

b) We may say that URN never got, up to day the social acceptance that, for
instance URL got. This doesn't mean that in some niche URN may not succeed.
People learn and evolve, sometime they regress and resume. Technical
evolution is not linear.

c) A good observer may deduce that the acceptance of URN was/is dependent on
the browsers; by performing the right DNS query. A potential cause is that
anyway browsers need to locate things to get them. The URN when compared to
URL in the context of browsers do not provide a 10X factor nor do they
resolve a big problem. However, when we need to provide a location
independent name to something, a URN can be useful since, it is possible to
design a naming convention with low collision potential. For instance, the
ROC UID as used by Microsoft and previously by the OSF consortium reduce
tremendously the probability of a name collision when a new name is
generated.

Bottom line: When I look back to what happened in the last years:

a) We regressed on some points and we progressed on others. For instance,
speaking of web apps, in terms of the "reach" factor, we made tremendous
progresses. In term of the "rich" factor we regressed to the mainframe era.
It seems that these days the pendulum is slowly going moving toward a new
state combining "rich" and "reach".

b) In terms of naming in the context of distributed computing we regressed
using an ad hoc technology invented at the right time for the right problem.
Not to diminish the value of that technology since it made the reach
possible. I still observed that it is inferior as a solution to the previous
schemes invented in the 80s and well documented by Tanenbaum in his books on
distributed computing. The web name resolution is very dependent on the
domain name and a domain name is dependent on an IP address. People will
have a lot of difficulties to associate a URL to a dog since this latter is
not connected to the web (not yet :-) but they will understand we need to
give it a name to identify it. A name convention is name convention and
location convention is a location convention. URL is a real progress when
compared to IP, URN when compared to URL only in some context where URL
poses a problem, and this is not yet the case on the web. Excepted for some
niche problems.

C) in the context of grid computing, rich applications (not based on a
"mainframe" like architecture but more distributed on the basis on the
processing power - to reduce a 3 gHz machine to the role of a dumb terminal
is not my definition of "progress") need to change they location but still
need to keep the same name for client applications. The whole system should
be as resilient as possible. This is translated into replicating the
service. The DNS is resilient with its caching mechanism, etc...

On the other hand:

a) URN and URL could potentially compete for the same mind space and offer a
solution to similar problems. Different alternatives are possible:

1- Resistance: I did that when the web appeared. I was used to more
sophisticated technologies and saw we would regress with this kind of
technology. However, what I didn't saw at the time is that we regressed to
improve the "reach" factor. I now know that we have sometime to regress in
order to progress....

2- Examine it in its global context: Gee, this requires wisdom my dear.

3- implementation: using it and debugging it. We'll know for sure what are
the problems and if it is a superior solution. URL got this opportunity and
we now know the limits (both from a social and technical point of view). URN
still didn't have this opportunity but in some niche market is proved to be
the answer to the problem. Will it ever go beyond the niche solution? I
don't know.

Cheers
Didier PH Martin

Received on Monday, 14 February 2005 14:42:45 UTC