Subject: [urn] implementing q-components, consensus check

From: Sean Leonard <[email-masked]>
Date: Sun, 8 Nov 2015 20:38:51 -0800

This is a consensus check 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".

We need to conceptualize urn: URI processing into the following 
components in a client-server model:

on client:
urn: URI dereferencer: takes string, splits into NID, NSS, r-component, 
q-component
  (never sees f-component)

client CALLS server(s) on the network:
URN resolver / URN resolution / URN resolution service: takes NID, NSS, 
r-component
  RETURNS "stuff"

urn: URI dereferencer (client): receives "stuff" *
  combines "stuff" with q-component
  results in a set of absolute-URIs or other data items, with optional 
attributes

THEN URI dereferencing can happen (on the absolute-URIs).

Agree? Disagree?

Sean

PS In constructing this e-mail I relied on several recent e-mails 
including those by Keith Moore, who insists "that q-components should 
not be passed to resolvers" 
<http://mailarchive.ietf.org/arch/msg/urn/FQ-KSeUercGp2X1oSd3dOsdYOAA>.
* I am struggling to see how this is implementable. But I want to check 
our consensus first.

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 09 Nov 2015 12:18:45 +0000

Sean Leonard writes:

> . . .
> urn: URI dereferencer: takes string, splits into NID, NSS,
> r-component, q-component
>  (never sees f-component)
>
> URN resolver / URN resolution / URN resolution service: takes NID,
> NSS, r-component
>  RETURNS "stuff"
>

Disagree.  Why load so much on the client?  Why make this so different
from how 'real' query-strings are understood and processed today?

In particular, this effectively means that I can't write a resolver
which assumes almost nothing about the user agent that sent the
resoution request except that it will handle 302 responses correctly.
That is, consider the following (made up) URN

 urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml

It would, if we _don't_ follow the rule you propose above, be trivial to
implement a resolver service as follows.

First, do

  registerProtocolHandler('urn','rfcsearch?uri=%s','IETF RFC Search')

on the containing page, say, https://www.rfc-editor.org/latest/, and
configuring the rfc-editor server to respond to

  https://www.rfc-editor.org/latest/rfcsearch?uri=urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml

with a 302 response status code and the header

  Location: https://rfc-editor.yourNearestIETFMirror.ietf.org/search/rfc_search_detail.php?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml

Done.  No muss, no fuss, no plugin installation, all under the control
of the hosting server.

> * I am struggling to see how this is implementable. But I want to
> check our consensus first.

I have only skimmed Keith's messages, my apologies if one of his points
directly addresses the above.  But it seems to me that the desire to do
something like the above follows more-or-less directly from 2141's
requirement that resolvable URN namespaces must provide a mapping from
URNs with 'their' namespace to retrieval-enabled (non-URN) URIs.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Keith Moore <[email-masked]>
Date: Mon, 9 Nov 2015 07:22:22 -0500

> THEN URI dereferencing can happen (on the absolute-URIs).

Mostly agree.   In particular, the resolution service should never see 
the q-component.   If the URN resolves to one or more URLs, the 
q-component becomes the query portion of those URLs.   If the URN 
resolves to a resource in some other way, the q-component should be 
reserved for transmitting input to the resource.

(The above assumes that the goal of this resolution operation - whether 
implicit or explicitly stated in the r-component - is to access the 
resource itself.   If the goal is instead to obtain metadata, it's not 
immediately clear to me whether the q-component can have a role, whether 
it should simply be ignored, or whether it should be an error.   To me, 
the simplest, and probably best, model is that the q-component is only 
used to send input to the resource itself, and all resolution parameters 
are supplied in the r-component.   That seems to assure a clean 
separation of function between the two and remove any conflict about 
whether a q-component goes to a resource or a resolution service in any 
particular case.)
> check our consensus first.

I am working on a description of how to implement this, and also how the 
various pieces fit together.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 9 Nov 2015 07:42:13 -0500

> from how 'real' query-strings are understood and processed today?

I believe Sean's description is consistent with how real query strings 
are understood and processed today.   In both URN and URL cases the 
client must first obtain the address of the resource server.   Then it 
sends the query to the resource server.   This isn't a significant 
'load' except when the resolution service can provide multiple URLs for 
the resource - then the client has the burden of selecting one.   (It 
can, however, just pick one at random.  And the client is generally in a 
better position to choose between multiple URLs than the server is.)

What would be inconsistent is to let resolution services try to 
interpret query strings and second-guess what those strings mean to the 
resources.   It would be inconsistent both in that the same query string 
associated with the same resource would be interpreted different ways 
depending on whether the resource were accessed via URN or URL, and it 
would be inconsistent in the way relative URIs containing query strings 
were handled.

> Done.  No muss, no fuss, no plugin installation, all under the control

Having the resolution service "control" what the client does is, IMO, an 
extremely bad idea.   Having the client's input sent to the resolution 
service violates the client's privacy rights.   Giving the resolution 
service the ability to alter the client's input, or refuse to complete 
the requests, is even worse than that.   The role of a namespace is to 
dole out unique names and ensure their continued uniqueness, not to be a 
"big brother" that mediates access to resources.

> URNs with 'their' namespace to retrieval-enabled (non-URN) URIs.

I don't think 2141 requires that this be done with a simple, one URL, 
HTTP redirect.

Keith

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 09 Nov 2015 13:06:08 +0000

Keith Moore writes:

> interpret query strings and second-guess what those strings mean to
> the resources.

I call FUD.

>  It would be inconsistent both in that the same query string
> would be inconsistent in the way relative URIs containing query
> strings were handled.

How does that follow at all from what I illustrated?

> Having the resolution service "control" what the client does is, IMO,
> an extremely bad idea.

I call FUD again.

> Having the client's input sent to the resolution service violates the
> client's privacy rights.

Hunh?  The only way to get anything resolved is by sending it to the service.

> Giving the resolution service the ability to alter the client's input,
> or refuse to complete the requests, is even worse than that.

Once you allow, as you _must_, the conversion of _any_ part of the URN
into a retrieval-enabled URI by the resolution service, then you have
handed over the interpretation of that URN to a 3rd party.

> The role of a namespace is to dole out unique names and ensure their
> continued uniqueness, not to be a "big brother" that mediates access
> to resources.

I call FUD.  I encourage you to examine carefully the documentation for
registerProtocolHandler [1] before responding again.

> I don't think 2141 requires that this be done with a simple, one URL,

Agreed.  It just points the way to a relatively trivial way to implement
generic resolution.

ht

[1] http://www.w3.org/TR/html5/webappapis.html#custom-handlers

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 09 Nov 2015 13:11:26 +0000

Keith Moore writes:

> (... To me, the simplest, and probably best, model is that the
> q-component is only used to send input to the resource itself, and all
> resolution parameters are supplied in the r-component.  That seems to
> assure a clean separation of function between the two and remove any
> conflict about whether a q-component goes to a resource or a
> resolution service in any particular case.)

Agreed.

ht