Subject: [urn] Consensus check (novel): q-component is URI scheme-specific?

From: Sean Leonard <[email-masked]>
Date: Thu, 26 Nov 2015 05:47:07 -0800

This is a consensus check (possibly novel) on our understanding of 
q-components.

A urn: URI is parseable into the following components:
"urn:"
NID
NSS
"?"
r-component
q-component
"#"
f-component

(Forget about the specific order for the time being. The list above is 
unordered.)

The q-component is a string that is transmitted to the "resource" that 
is identified after "resolution" takes place with the "URN resolver".

Thus far we have been very handwavy about how q-component gets smushed 
into the products of the resolution services. Said products could be 0-n 
URIs (URLs). So, some post-resolver component (likely, the client urn: 
URI handler) gets to smush them together.

Is it the case that the act of "smushing" is URI-scheme specific? 
Consider a resolver that takes urn:isbn:9999... with a q-component of 
"userid=[email-masked]". The ISBN URN gets resolved to an https:// URL, 
and the point is that the userid q-component gets appended to the query 
string with "&", consistent with current practice.

But if the resolver returns things other than https: URIs, maybe the 
handler should smush them together in different ways. For example in an 
LDAP URL, the q-component should be sub-parsed into [attributes], 
[scope], [filter], and [extensions], each of which is piecemeal appended 
to the [attributes], [scope], [filter], and [extensions] of whatever 
LDAP URLs that are returned by the resolver.

The act of "smushing the q-components" might be categorized as:
ignore
replace
append
prepend
sub-parse and distribute
special

Of these, ignore, replace, append, and prepend can be done without 
scheme-specific knowledge. "Sub-parse and distribute" requires 
scheme-specific knowledge that can be encoded in a limited-purpose or 
regular grammar, for example, "parse the & characters, match the = 
characters, and intersperse". "Special" is a generic catch-all that is 
obviously scheme specific and would likely require an executable 
language specification.

I am not proposing any solution to this (although one solution, if you 
want to have one, is to make q-component have a URI scheme parameter, 
such as <http>HTTPQUERYCHARACTERS <magnet>MAGNETQUERYCHARACTERS 
<ldap>LDAPQUERYCHARACTERS). Just making an observation.

Sean

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Nov 2015 13:15:33 -0500

> is identified after "resolution" takes place with the "URN resolver".

Yes.   (at least, that's its purpose, and it will work that way in 
practice for any URL scheme that transmits the query portion of the URL 
to the resource.)

> into the products of the resolution services. Said products could be 
> 0-n URIs (URLs). So, some post-resolver component (likely, the client 
> urn: URI handler) gets to smush them together.

In all cases in which the path to a resource is obtained via a URL, the 
q-component should become the query component of the URL.

(if the resource is accessed via some other means, the specific means by 
which the q-component is used should be undefined for now. This leaves 
open the possibility for the use of the q-component in other resolution 
scenarios.)

> "userid=[email-masked]". The ISBN URN gets resolved to an https:// 
> URL, and the point is that the userid q-component gets appended to the 
> query string with "&", consistent with current practice.

No.   The q-component must not get appended to the query string with 
"&", because that presumes (without justification) that the resource 
interprets queries as if they were HTTP form data.   The q-component 
must _become_ the query string.   If the resolution service returns a 
URL that already contains a query, that query must be discarded.   (The 
alternative is to declare this an error from the resolution service, and 
thus, invalid output - the client could continue by consulting a 
different resolution service.)

There are several reasons for this:

1. The resolution service should not be in the business of interpreting 
user requests.   This is a privacy and security concern.  An 
architecture that permits the resolution service to interpret user 
requests (including q-components / queries) is one in which the 
resolution service can record such requests and/or filter those which it 
does not like.   The architecture should not permit the resolution 
service to play the role of Big Brother.

2. The user, or the author of the content, is in a better position to 
know what it wants from the resource and how to request it from the 
resource, than the resolution service is.   Burdening the resolution 
service with the knowledge of every resource's protocol is bad layering.

> handler should smush them together in different ways. For example in 
> an LDAP URL, the q-component should be sub-parsed into [attributes], 
> [scope], [filter], and [extensions], each of which is piecemeal 
> appended to the [attributes], [scope], [filter], and [extensions] of 
> whatever LDAP URLs that are returned by the resolver.

This is another reason that "smushing" the components is a Bad Idea.   
The sole purpose of the q-component should be to allow the user or 
content-author to send a query to the resource.    The means by which 
this is done should be to copy the q-component to the query portion of 
any URL resulting from resolution.   But for the sake of consistency and 
simple layering, this should be the behavior even if that specific URL 
scheme interprets "query" differently.   That's simple, easy to define, 
and doesn't require URN clients (or for that matter, resolution 
services) to have specific knowledge of URL schemes or the ways that 
resources interpret queries.

Keith