Subject: [urn] Review of rfc2141bis-16 and semantics-clarif-03, Part 2

From: Sean Leonard <[email-masked]>
Date: Wed, 4 May 2016 10:01:15 -0700

Stuff that is controversial or that the WG is still struggling to conclude:
****
How much to specify how the query production (r-component, q-component) works. This includes ABNF and syntactic issues.

Distinguishing between r-component and q-component served an important and commendable function during the development of this draft. It is no longer useful.

The struggles with q-component reflect that it’s impossible to implement something useful with it. I therefore urge the group to drop q-component entirely.

Syntactically, “?+” and “?=” have been proposed. These will not work. If q-component is based on another URI scheme (which, inevitably, it will be), it *can* contain “?+” and that will cause an URN parser to switch to r-component. It is ambiguous and insecure. I have tried implementing it already.

I don’t see what the obsession is with making the order of r-component and q-component interchangeable. The only way to avoid this parsing fiasco is to put r-component first, and to restrict r-component so that it *never* can contain the escape sequence to q-component (e.g., if a second “?” delimits q-component, make sure r-component *never* contains “?”).

Semantically, q-component makes no sense, especially when r-component is around. If a URN resolver service (because it’s a service, not a resource) is going to take a crack at the URI string, it can return resource representation(s) itself, or in some hypothetical formulations, can return URLs. In the former case, the q-component is ignored, so you may as well not put it in, in the first place. In the latter case, you don’t know what the URL is going to be when writing the URN, so appending q-component arbitrarily to the end of whatever is returned, isn’t going to make any sense. Maybe the URL already has a query production; maybe not; maybe stuff gets double-specified.

Make the RFC 3986 query production === r-component. The “resolvers” or “resolution services” of the URN gets to see the entire query production.

Regarding the inner syntax and semantics of r-component: I have made my case for a resolver operation identifier, a reg-name, and name/value parameter pairs. resolverID got picked up (in mutilated form) in -15, then dropped in -16.

It is satisfactory to me to punt on further specifying r-component in rfc2141bis in order to get this done, provided that a new Internet-Draft be created that attempts to specify it. I can supply initial text. Juha Hakala has expressed that specification is needed for development projects in the library community. <mid:[email-masked]>

****
How much “semantically” URNs are URIs.

URNs are URIs. RFC 3986 URIs can identify principles and abstract ideas. A URI can point to a (potentially unbounded) family of resource representations, or none at all. How the path and query components work is scheme-specific. So, URN can say that the query production doesn’t *name* the resource (the name for which, in the path production, is persistent and unchanging); it just helps resolvers with returning particular resources & representations. This is consistent with the URI framework.

Pontificating was useful for a time, but to get these drafts done, pontification ought to be removed from rfc2141bis-16 and semantics-clarif-03. This means dropping publishing semantics-clarif entirely, and simplifying/clarifying rfc2141bis itself.
****

Sean