W3C home > Mailing lists > Public > www-tag@w3.org > June 2008

Re: Using http: for naming not so obvious

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 12 Jun 2008 19:15:15 -0700
Message-Id: <DA4CB689-4D55-4261-9AA3-B63BD2308D43@gbiv.com>
Cc: Dan Connolly <connolly@w3.org>, "www-tag@w3.org WG" <www-tag@w3.org>
To: Jonathan Rees <jar@creativecommons.org>

On Jun 12, 2008, at 12:42 PM, Jonathan Rees wrote:
> You then said:
>
>      not obvious? really? everybody and his brother makes  
> namespaces out of http/dns. It might be worth
>      writing up/down, but LOTS of people figure it out by themselves.
>
> I would say it is *empirically* nonobvious. Consider the following  
> examples:
>
> XRI - as discussed.
> DOI - these look like URIs, but aren't, and they certainly aren't  
> http: URIs.
> Handle system (of which DOI is a part) - similarly.
> info: URI scheme - nonresolvable URIs.
> urn:lsid: - similarly.
> tag: as specified by a W3C team and TAG member - if http: is  
> universal, why wasn't it used here?
> NCBI database cross-references ("dbxrefs") - why don't they just  
> use http: URIs?
> http://jama.ama-assn.org/cgi/content/short/299/19/2316  - they crop  
> up every day.
>
> These people are not stupid; they would not have passed over an  
> "obvious" solution to unnecessarily invest quite a lot of effort in  
> a different solution.

No, that is contrary to organizational dynamics.  When presented
with a problem, the first thing folks do is invent their own solution.
What happens next is largely a function of funding and size of
institution.  We only see the efforts of the well-funded and
extremely stubborn folks.

It isn't about being smart or stupid -- just being able to perceive
the issues of change over time requires quite a bit of smarts.
It is about pride, NIH syndrome, and an endemic belief that people
would behave more like computers if we'd just take away some of
their options.

And, no, it isn't because the people involved were not aware of the
fallacies inherent in the DNS-is-short-term argument.  I explained it
in detail, many times, and it hasn't prevented a single one of those
efforts being repeated, as before, and failing, exactly as before.

> The problem comes from people who don't think a DNS domain name and  
> the server connected to it can survive mergers, acquisitions,  
> rebranding, bankruptcies, carelessness, lawsuits, and other forces  
> of nature. They think (a) that their naming system if http-based  
> would catastrophically fail if DNS failed in one of these ways, and  
> (b) that they can set up a naming system that is more abstract and  
> timeless than is http: so that DNS risks are avoided. In some cases  
> they have the wisdom to see that the best bet for surviving DNS  
> vagaries (or any other kind of protocol calamity) would come from  
> replication (so that names can be looked up in more than one way,  
> just as physical books are found in more than one library), but  
> that is rare.

Really, it has far more to do with a basic misunderstanding of
web architecture, namely that you have to use HTTP to get a
representation of an "http" named resource.  I don't think there
is any simple solution to that misbelief aside from just explaining
it over and over again.  It's like trying to explain Akamai's CDN to
someone who has only read textbooks on Internet networking -- there
are a lot of basic assumptions shared by technical folks which
are just plain wrong.

People think that they can create a naming system that is just as
valuable as DNS (as in, people actually use it to name things)
without suffering from the exact same vagaries as DNS.  However,
all of those hazards above are caused by people placing value on
names, not the naming technology itself.  Names have value because
they are useful to others outside our normal range of control.
The more value they have, the more likely they will be maintained
*and* the more likely they will be at risk to acquisition, etc.

There is one theory that says that we can solve the DNS problem
by creating a separate namespace with a supposedly neutral central
monitor whose mandate is to preserve some unknown sense of sameness
in names for all eternity.  In fact, that only duplicates DNS, and in
a way that is far less successful because this new central system
is not necessary for basic communication and incapable of scaling
like DNS.

There is a second theory that we can solve the DNS problem by
making names so ugly that they wouldn't ever convey any inherent
value on their own.  The problem with that is rather obvious:
they are too ugly for people (just like IP addresses), so people
create aliases for them which aren't so ugly (just like DNS), and
it is those alias names that are given value (just like domains).
We are back at square one.

There are probably other theories about "how to do better than
DNS" out there, some of them even based on altruistic beliefs
instead of commercial gain.  They have no chance of success
unless they can replace DNS itself, which is quite a difficult
task.  And, if they do, http URIs will use those names just
as well as they use domains today.  Because http URIs are not,
in fact, dependent on DNS.

....Roy
Received on Friday, 13 June 2008 02:15:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:58 GMT