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

From: "Hakala, Juha E" <[email-masked]>
Date: Mon, 5 Oct 2015 10:53:35 +0000

Hello,

some comments below. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Sean Leonard
> Sent: 25. syyskuuta 2015 15:24
> To: [email-masked]
> Subject: [urn] resolver profiles: a generative POWER-UP for r-component
> 
> URNies:
> 
> What URNs really need is a way to ensure that the resolution process
> delivers more consistent and predictable results.

All PIDs must be made "smarter". If resolution only links identifier (name) to 1-n locations, it is possible to argue that this is an extra step that can / should be avoided. But if resolution can facilitate persistent access to all kinds of information about the identified resource, it is hard to achieve similar results with e.g. HTTP (which is itself not persistent).  

It has not been easy to improve URN syntax so that smart resolution is possible. One problem is URI syntax, which has left us with a limited tool set (? for query and # for fragment). Using ?? for r-component is in these circumstances the best thing we can do. Alas, other PID systems may not be able to do even this.   

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

The intention is to proceed in two steps: first to establish r-component, and then to establish mechanism with which the r-component syntax and semantics are maintained.  Since the technical infrastructure within which resolution happens changes all the time, it is not possible to create a fixed list of resolution services and service parameters. But we can have for instance IANA registry for shared services (and their parameters) and some other arrangements for namespace specific services (if any). 

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

This is one option that we can consider. 

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

And also: what do / can we do now, and what is possible 50 or 100 years from now? We do not have any idea of what library systems / digital archives will be capable of in the distant future, but we do now that books will still have the same ISBNs by then. Of course, all manifestations valid now will be rendered useless for most users in 2115; only those with specialized tools can still render the original documents. All others will use migrated modern versions of the works.  

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

Indeed; I could easily add a lot of stuff into this list ;-). 
 
> 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.

This is the current status and definitely not one that we should be happy with. It is important to give the user a choice between different options. IMO the role of metadata will be essential: how much will this resource cost? is there a Finnish translation? what can I do with this resource once I have downloaded it? what tools shall I need to render it? who owns the rights for this work? And so on. 

> 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

Although these information needs are definitely valid it is not necessary to nail the syntax yet. 

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

Whatever rule a URN namespace applies for naming, only applies to NSS. The components can be added by anybody any time. I suppose that they will often be machine generated. A GUI which enables the user to retrieve metadata about the resource will modify the actual component accordingly when protocols and metadata formats change. Users do not need to know anything about these changes. And we standard makers only need to provide new services and parameters when requested. 

As regards the syntax of r-component, IMO it is useful to provide some generic services. Backwards compatibility with RFC 2483 requires that. But we also know that RFC 2483 had too simple view on services; for instance, there can be many different metadata formats, and asking each one of them via different service would not make sense.  

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

I am afraid that making resolver profiles solely namespace-specific might create problems. But it is certain that different namespaces will support different services. For instance, ISBN and ISNI (International Standard Name Identifier) will not have much common from service point of view. But same people will be using both, provided that ISNI acquires a URN namespace. 

Best regards, 

Juha

> 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

---

From: Sean Leonard <[email-masked]>
Date: Tue, 6 Oct 2015 02:26:51 -0700

Hello,

Thank you for this response. I think we are making progress.

> It has not been easy to improve URN syntax so that smart resolution is possible. One problem is URI syntax, which has left us with a limited tool set (? for query and # for fragment). Using ?? for…

The invention of the r-component is (in my view) a major step forward. 
Making the r-component mean something, i.e., enabling and channeling the 
resolution process, is the next step forward.

> The intention is to proceed in two steps: first to establish r-component, and then to establish mechanism with which the r-component syntax and semantics are maintained.  Since the technical infras…

Yes, that is the idea.

> And also: what do / can we do now, and what is possible 50 or 100 years from now? We do not have any idea of what library systems / digital archives will be capable of in the distant future, but we…

Yes we should design for the future as well.

> This is the current status and definitely not one that we should be happy with. It is important to give the user a choice between different options. IMO the role of metadata will be essential: how…

Yes.

> Whatever rule a URN namespace applies for naming, only applies to NSS.
Yes.

> The components can be added by anybody any time.

Yes, that is part of the "generative principle": we are designing 
systems that will generate innovation by making the registration process 
as free and open as possible to disruptive new technologies.

> I suppose that they will often be machine generated. A GUI which enables the user to retrieve metadata about the resource will modify the actual component accordingly when protocols and metadata formats change. Users do not need to know anything about these changes. And we standard makers only need to provide new services and parameters when requested.
>

I do not consider RFC 2483 backwards compatibility a design goal (for 
one thing, it includes URCs, which don't really exist now), but it's 
good to know. I have now been made aware of the text/uri-list media type.

> I am afraid that making resolver profiles solely namespace-specific might create problems. But it is certain that different namespaces will support different services. For instance, ISBN and ISNI (…

Yes, that is the tension between universal resolver profiles and ones 
that are namespace-specific: identifiers (or, more specifically, 
identified objects) may not have much in common with each other's 
applicable services. Delineating by namespace is one way to group 
services, but it is not the only way. I will follow-up with a dedicated 
post on this topic.

Best regards,

Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 6 Oct 2015 03:26:43 -0700

On 10/5/2015 3:53 AM, Hakala, Juha E wrote:
> As regards the syntax of r-component, IMO it is useful to provide some 
> generic services. [...]
>> Resolver profiles are namespace-specific, [...]
>>
> I am afraid that making resolver profiles solely namespace-specific might create problems. But it is certain that different namespaces will support different services. [...]

Let us look at where we are now:

urn:ietf:rfc:3986?getspec:ct=text/html#section-2.1
      |   \      / \      |  \        / \         /
     NID   NSS    ? profile : params   # fragment
    <-p-component-><-- r-component --> <-f-component->

The "profile" here could easily be called the "service" or "operation".

It is a design goal to make the "profile" as open to new registrants as possible. We also know that the NID only constrains the rest of the p-component. There is some tension about whether the NID (namespace) should also constrain or define the universe of resolution services that apply, and whether services can be limited to one namespace. As we have said, urn:ietf probably needs different services than urn:isbn. The counterpoint is that urn:ietf:rfc:XXXX may share many service needs in common with urn:iso:std:iso:9999:-1:ed-1:en (both being identifiers for standards documents). In contrast, urn:ietf:params:oauth:redirect_uri (see <http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml>) shares very few service needs in common with urn:ietf:rfc:3986.

Here is an additional proposal to the structure of "profile":

   profile     =  ( service [ "@" r-authority ] ) /
                  ( r-token service )

   service     =  NID / utf-8-pct-encoded

   r-authority =  host

   r-token     =  "*" / "!" / "?"

A resolver profile can identify a service, optionally AT (@) a specific, named resolver: the r-authority. The r-authority can be a host name on the network, or can be a keyword of some kind that identifies a "service space" (by analogy to how the NID identifies the namespace--perhaps a Service Identifier or SID). Therefore:

    urn:isbn:0385537670?[email-masked]:au;used

means to get the resource(s) for the ISBN 0385537670 using the service "pricing" as resolved by amazon.com. In proposing this syntax, I am vaguely invoking RFC 2168, with a vague premise that the DNS is supposed to be involved with the resolution process. This syntax only permits host names, not IP address literals.

If people object to embedding DNS names directly in the urn URI, consider:
1) The r-component is not the URN, it's the r-component of the urn URI, so it doesn't affect equivalence.
2) We are supposed to keep the URN (p-component) part stable, but the r-component does not need to be so--resolution is supposed to happen with some network interactions, so the topology of the network is expected to change over time.
3) When embedding such a urn: URI in a resource like HTML, the HTML itself is pretty dynamic and expected to change over time.

Instead of a DNS name, the r-authority could simply name a generic "service space" (SID). How that service space gets defined (registration? First-Come, First-Served? etc.) is up to this WG.

I have provided an alternate syntax to segregate different kinds of services with the r-token, which could take on various meanings. For example, "universal" service keywords could be identified with service and X-specific (namespace-specific, domain-specific, etc.) services could be identified with *service, or vice-versa. If the r-authority is the namespace (specifically, if the r-authority name is the same as the NID, i.e., is defined by the same organization that issues the URNs), then !service could be a shorthand for service@NID, sparing the repetition. For example:

    urn:ietf:rfc:3986?!getDependentInternet-Drafts

could be syntactic sugar for:

    urn:ietf:rfc:3986?getDependentInternet-Drafts@ietf

assuming that the "service space" "ietf" is well-defined. (Obviously, @ietf.org has a different proposed meaning, per above.) The nice thing about SIDs that are also NIDs like "ietf", "oasis", and "iso" is that although the organizations have specific locations on the network today (ietf.org, oasis-open.org, iso.org), the URN r-component formulation is not dependent on the network name, which could change, or could be subsumed by successor organizations.

In the production above, the service name could be any Unicode name, thus greatly expanding the space or names.

Sean

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Oct 2015 20:29:23 -0600

On 10/6/15 3:26 AM, Sean Leonard wrote:
>> All PIDs must be made "smarter". If resolution only links identifier
>> (name) to 1-n locations, it is possible to argue that this is an extra
>> step that can / should be avoided. But if resolution can facilitate
>> persistent access to all kinds of information about the identified
>> resource, it is hard to achieve similar results with e.g. HTTP (which
>> is itself not persistent).
>>
>> It has not been easy to improve URN syntax so that smart resolution is
>> possible. One problem is URI syntax, which has left us with a limited
>> tool set (? for query and # for fragment). Using ?? for r-component is
>> in these circumstances the best thing we can do. Alas, other PID
>> systems may not be able to do even this.
>

The major questions are: where and by whom will the next step be taken?

In my opinion:

1. Where is not draft-ietf-urnbis-rfc2141bis-urn but it might be a 
document that updates or obsoletes RFC 2483.

2. By whom might be this working group but I think that energy to do 
this work might lie elsewhere (among those who are more actively 
implementing and deploying URN resolution services).

Peter