Re: [urn] q-component copied verbatim

[John C Klensin <[e-mail]>]

--On Sunday, May 15, 2016 01:37 -0700 Sean Leonard
<[e-mail]> wrote:

>...
> In your very useful example, you are saying that the URN
> resolver is going to see the q-component, and put it in the
> resulting URL(s).
> 
> But in prior discussions, a motivator for the q-component was
> "privacy", namely, that resolvers can see the r-component
> but not the q-component. The implication was that URN client
> applications would take the results of the resolver and do
> their own merging on the client side.

I don't recall that discussion, certainly not that a privacy
claim of that sort was dominant in the q-component discussion.
AFAICT, it is not reflected in 2141bis in any way, especially
because I've tried to carefully guard against (over Juha's
objections btw) turning the architectural description of the
pieces and components associated into URNs for a requirement
about a particular implementation model.  

> This example supports the premise that URN resolvers see the
> entire query production (q-component and r-component), and are
> expected to return complete URLs to a URN client, with the
> q-component folded into the URLs. Consequently, we have a
> distinction without a difference between q-component and
> r-component. They should be merged into one (i.e., query ===
> r-component).

No.  There is still a difference.  The WG has discussed it at
great length.  Just as we should not constrain that
implementation model out of existence by the language of the
spec, we should not require it.  Put differently, Juha gave an
example of a situation and implementation strategy.  He did not
claim it was the only possible one.

>...

>...
> The example provided here is fine for HTTP/HTTPS URLs, but it
> fails on everything else. Try copying the URN q-component
> "verbatim" into the following URI schemes: 
> data
> ldap
> ftp

First, the text says that the q-component relationships,
including the "copied" sentence, applies only to URLs, so
arbitrary URI schedules are not relevant here.  If you are
making a case that scope statement should really say "HTTP or
HTTPPS URLs" and there is sympathy for that in the WG, the scope
sentence is easily changed.   However, it appears to me that,
for URLs including at least most of those you have listed, the
non-specific language in 3986 about what URI (really URL)
processors (or "resources" are supposed to do with queries they
don't understand would seem to cover the situations.

>...
> ...and none of them work the way you want them to (except,
> perhaps, Gopher, and that is a stretch because there are all
> of 70 servers left).

I won't comment here on what I think a criterion of "there are
only 70 servers, therefore the protocol or scheme doesn't count"
would, if generalized, mean to the Internet.

> Making the URN resolver map the query production to the
> resulting URL provides much more flexibility and protocol
> independence. For example, the URN resolver can break out the
> components (version, operation, startRecord, etc.) and
> reassemble them into the scheme-specific string, such as
> something like
> <ldap:///cn=book,serialNumber=0888543433??version=1.1,operatio
> n=searchRetrieve>.

Speaking personally, I've argued all along for allowing (but not
requiring) that sort of implementation model.  I believe that
the WG decided rather firmly against it during the discussion of
whether q-component handling was a function of the namespace
(much less the namespace and specific component string or
intermediate resource).  AFAICT, the WG decided that q-component
handling should be strictly a function of the URN scheme and
Peter reflected that in 2141bis in the only way that reflected
that WG discussion and made sense, i.e., by direct and
uncritical copying.   I am still not convinced that was the
right decision, but, as long as we allow some implemention
flexibility, don't see sufficient justification for reopening
the question.

If you do, please take it up with the co-chairs.

     john