URNsAndRegistries-50: Stepping back a bit

1. Grandmother observations about the Web

• "Global naming leads to global network effects"
  • A prerequisite for citation
  • A challenge for many existing schemes
• "To benefit from and increase the value of the World Wide Web, agents should provide [http:] URIs as identifiers for resources"
  • I.e. not just any global name, but a particular kind of global name

2. More from Grandma Webarch

• It's good for the ownership of a name (URI) to be manifest in the form of that URI
  • We need to know who is responsible for the name and its use
• "A URI owner should not associate arbitrarily different URIs with the same resource."
• "A URI owner should provide representations of the resource it identifies"

3. Connection with "persistent indentifiers"

• The TAG is concerned not only to protect the Web as it is
  • but also to extend its reach and value
• This often amounts to strenuous efforts to combat the NIH syndrome
  • It's so hard to accept that the solution to your problem is already available, off the shelf, but with someone else's name on it
• "No scheme or syntax guarantees persistence of any kind" (John Kunze)
  • Accordingly persistent identifier efforts can and should save huge amounts of fuss by focussing on the non-technology substrate issues involved in producing persistence
  • Just use http: URIs as the technology substrate

4. Lookup plus hierarchy

• Virtually all public distributed naming system proposals we have seen have these properties
  • Some kind of global lookup to establish a context
  • Some kind of navigation through a structured space determined by that context
• These properties address the fundamental needs of such a naming system
  • It's distributed (no single central source of name bindings)
  • It's scalable (no intrinsic upper bound on what can be named)
• The http URI scheme is such a system
  • The domain name part (e.g. www.w3.org) can be resolved by appeal to a distributed lookup mechanism (DNS)
  • The path part (e.g. /2001/tag/webarch/) provides for scalable navigation to a particular name binding within that context
• There are huge benefits to using an existing, well-tried approach, that is, http URIs
  • So you need a very good reason to attempt to launch a new public distributed naming story

5. (Parenthesis on distributed, secure and human-readable)

• You can have any two :-(
• See SFS (Self-certifying File System)
• The simplest kind of secure names are names which include a one-way unique hash of the thing that they name.

6. Just what is the problem?

• If http: is so cool
  • Why do people keep proposing new naming stories?
    • urn:nzl
    • RFC 3688
    • UBL
    • xri:
    • RFC 4452
    • info:
    • LSID
    • to name just a few. . .
• Surely there must be good reasons for all of this?
• To make this finding effective, we have to adopt the role of salesman
  • Which means starting be establishing our credibility by identifying (with) our audience's pain points ("Sell problems, not solutions")

7. Legitimate concerns

• Symptomatic complaints:
  1. Dependence on DNS
  2. Apparent lack of central control
  3. Commitment to serve a representation (esp. relevant for info:)
• The real issue
  • Trusting the proprietor
  • The core motive for positions that look like NIH from our perspective
  • Communities want to centralise, with a well-known authority close to home
  • IANA/DNS doesn't qualify
• For example, info: looks more attractive than lccn.info because the ownership of info: is established via a document, namely RFC 4452, which doesn't depend on any institution other than one the relevant community already trusts
  • In principle it also depends on the IETF not screwing with the URI scheme registry, but somehow that doesn't feel like a risk -- perhaps because the scale is so different to the scale of domain name space -- 64 registered URI schemes, perhaps another 50 unregistered but in use, compared to at least millions of domain names. . .
  • Also, people have experience of domain names going away or getting misappropriated, whereas there's no such experience wrt URI schemes.

8. Shift in Strategy required

• We can't push a simple "http: good, myRIs bad" story, it lacks credibility
• Shift to
  • Recognising the legitimate concerns ("we feel your pain")
    • Also, a more extensive analysis of the dimensions of and variant takes on 'persistence
  • Framing the comparison in terms of tradeoffs (in some cases, not all)
    • But don't pull punches -- point out that history suggests that commiting to a single entity, particularly a commercial one, to hold the keys is a mistake -- five of the first six URN namespaces have been abandoned by their owners, and as far as I can tell only info: of the semi-private/private URI schemes has any substantial non-proprietary usage and implementation base.
    • info: is the real hard case
      • We want to argue that dereferencing will eventually be what you want, even if you don't start out wanting it
      • But info: appears to view a strong commit to never providing resolution as a selling point.
  • Acknowledging the real remaining hole (domain-name vulnerability)
    • Pointing to workarounds/insurance schemes already available (e.g. ARK);
    • Promising to explore remedial action (W3C/TAG/EU/DCC/LC/??? workshop on name protection -- towards a Persistent Name Holding Company???