Subject: [urn] resolver profiles: a generative POWER-UP for r-component

From: Sean Leonard <[email-masked]>
Date: Fri, 25 Sep 2015 06:23:59 -0700

URNies:

What URNs really need is a way to ensure that the resolution process 
delivers more consistent and predictable results.

Since the introduction of the r-component, URNs are now able to address 
(speak to) the resolver directly to control aspects of the resolution 
process. Yet the specifics are woefully absent in 
draft-ietf-urnbis-rfc2141bis-urn-13.

I propose that the r-component begin with a resolver profile (or 
resolution profile, or directive), which is an opaque string that 
identifies the nature of the resolution services being requested by the 
particular urn: URI. It's a POWER-UP 🍄 for the r-component!

Consider our favorite urn:isbn. Given an ISBN, what can we do with it? 
What do we want to get for it? And how can we make the f-component 
meaningful, if the urn: URI string is not going to give us back some 
kind of predictable media type/type of resource?

Answer: the namespace registration can include profiles, and these 
profiles better specify what happens when resolution occurs. In our ISBN 
case, profiles can include:
showbook
librarycatalog
pricing
buybook
covershot
bibliographicinfo
referencedworks
...and a potentially infinite range of other resolution things to do.

The absence of a profile string does not imply a "default" action. If 
you specify urn:isbn:0385537670, you are left with just the identifier. 
The implementation (context) can figure out whatever it wants to do.

To the extent that the resolver profile needs or accepts additional 
data, this data can follow the profile string.

Examples include:

urn:isbn:0385537670?productphoto:dpi=600
urn:isbn:0385537670?pricing:au;used
urn:oid:1.3.6.1.5.5?info
urn:ietf:rfc:3986?getspec:ct=text/html#section-2.1

The syntax is:

       namestring    = assigned-name
                       [ "?" r-component ]
                       [ "#" f-component ]
       assigned-name = "urn" ":" NID ":" NSS
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = word
       r-component   = profile [":" query]
       profile       = NID
       ; query is from RFC 3986
       word          = pchar *(pchar / "/")
       f-component   = fragment

Unlike the NSS, which needs to be well-defined, durable, immutable, 
etc., profiles are intended to be very lightweight and capricious. To 
the extent that a namespace uses profiles at all, registration of 
profiles would be either First-Come, First-Served, or Specification 
Required. The namespace registration can impose restrictions on profiles 
(including disallowing profiles altogether), but anyone should be 
permitted to invent a new profile, document it, and register it. [This 
is a generative proposition--see David G. Post, The Theory of 
Generativity, <http://ir.lawnet.fordham.edu/flr/vol78/iss6/2/>.]

Resolver profiles are namespace-specific, so "info" for the oid: URN 
would have totally different semantics from "info" for the nato: URN or 
service: URN.

The profile functions as a contract on how specific resolvers should 
behave, including how the resolver should interpret the query parameters 
(string) and translate the information into resources (or into URLs that 
can be dereferenced into resources).

With this definition, there is no longer a q-component. Everything is on 
the r-component. Effectively the r-component is the query, but it's 
addressed to and interpreted by the resolver.

That's the proposal. Comments welcome.

Sean