Using http: for naming not so obvious

(Dan, I would have replied to you privately, but as this follows on  
from our telecon, and the TAG does its technical work in public, I  
thought I would cc the list. I hope I don't create another storm...)

On IRC Henry scribed me as saying:

     JR: A durable solution needs more than a TAG finding - there  
needs to be a manual or something
     that helps groups like XRI when they have a need for a naming  
scheme

(and I went on to utter the word "normative".)

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.

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.

To invent a naming system outside of http: is a natural impulse and  
it has to be understood on its own terms if we are not to be snobs.  
There is some precedent to the idea that information such as the  
meanings of names (http or otherwise) can spread in other ways than  
DNS/HTTP and would survive DNS-level failures - the URI schemes  
themselves are one example, as are the many naming systems that were  
successful prior to the invention of the transistor. For a dignified  
old-timer such as the periodic table, as well as many newcomers, the  
idea of being at the mercy of these mysterious upstarts IETF and IANA  
would really grate. Scientists in particular are anti-authority, and  
naturally gravitate to systems like LSID that eliminate any reference  
to anything they don't control. (LSIDs rely on a locally maintained  
mapping table that can bypass any DNS nonsense that any user comes  
across. Yes, it doesn't scale, but that's not their concern, it's ours.)

You know, I hope, that I fall on the pro-http: side; I don't think  
adopting http: puts you at anyone's mercy and so far it appears to me  
that a combination of technical and legal machinations *might* be  
able to create an http:-based naming scheme satisfying, say, archival  
needs (probably the most demanding customers). But the first step to  
recovery is realizing one has a problem, and nobody on either side of  
the debate seems to be doing this. I recognize that Henry, Noah, and  
others have put a lot of effort into the issue, and while TAG  
findings will help, I don't think they will be sufficient to get  
everyone on board who I would like to have on board.

Jonathan

Received on Thursday, 12 June 2008 19:43:31 UTC