Subject: [urn] rethinking r-components

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 17:52:08 -0400

I originally proposed r-components for two reasons:

1) every single discussion of URN resolution I can recall revealed a 
desire to incorporate resolution service requests into URNs
2) somewhat along the same lines, there was expressed interest in using 
q-components / queries to communicate requests to resolution services, 
and I wanted to avoid the potential for this to conflict with use of 
q-components to transmit queries to resources that were capable of 
accepting them.

But now I'm wondering whether r-components are worth the trouble, and if 
they are, whether we can keep them from getting out-of-hand.

Our discussions have revealed several issues:

- Syntax and specification delay.   If we're going to define 
r-components, we need to do it now.   But it's hard to nail down 
r-component syntax if we can't tell what we need, and hard to tell what 
we need if we can't agree on how they're likely to be used.
- Even if we settle on name-value pairs, there's some reluctance to 
create a registry of names for r-components.   Without a registry, there 
seems to be a significant risk of expecting clients to be aware of 
namespace-specific r-components for several different namespaces, and 
that threatens to degrade the long-term utility of URNs that aren't from 
namespaces that are supported by clients.
- In addition to r-components being transmitted to resolution services, 
it appears that clients also have to be aware of r-components.
- If r-components are used to narrow the result set from a resolution 
service (as I originally assumed) it seems that they're likely to be 
both very lengthy and difficult for humans to parse/read, due to the 
necessity of encoding such information in URI syntax.
- The left vs right discussion that John and I have been having is a 
relatively minor concern, but it does highlight the potential for 
q-components to require an extra layer of encoding as a result of 
r-component syntax decisions.

So I'm now back to thinking that narrowing of results from a resolution 
query is perhaps best done in a conventional programming language 
(presumably JavaScript in the web environment) and that perhaps defining 
a standard URN resolution API for use by programming languages will 
result in better interoperability and robustness than trying to cram 
queries and selectors into URN r-components.   And that leaves me 
wondering what's left for r-components to do.   Maybe just service 
requests like  U2C, U2L, U2R?

Also, it seems to me that in most cases of web usage, the service 
desired from the resolution server can be inferred from context. e.g.

<A HREF="urn:example:foo">  is an interactively-clickable link, and a 
browser can reasonably implement a click by presenting the resource, OR 
presenting its metadata and allowing a click-through to the resource, 
and the behavior might even be different for different resources (e.g. 
if some sort of payment or authentication is required).

<IMG SRC="urn:example:foo">  requires that the content be accessed 
without prompting the user, so the browser will need to either get the 
content directly from the resolution service (U2R) or get a location of 
the content (U2L) and download the content from there.

<FORM ACTION="urn:example:foo"> - the browser must do a U2L request and 
submit the form to one of those locations.

So now my questions are:

- should we dispense with r-components entirely, and can we do so 
without inviting overloading of q-components for resolution service 
parameters?  (I think the latter is still important.)
- if we keep r-components, should we try to limit how they're used so 
that people don't try to cram a general purpose query language into them?