Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Oct 2013 21:26:13 -0600

On 09/04/2013 10:58 AM, [email-masked] wrote:
> Hello,
> 
> Quoting Keith Moore <[email-masked]>:
> 
>> On 09/03/2013 11:16 PM, Peter Saint-Andre wrote:
>>>>> In comparison, the planned use of query in the URN context
>>>>> should be
>>>>>>> relatively simple. But the URN resolvers may need to
>>>>>>> get
>>>>> smarter. For
>>>>>>> instance, if I want a resource description instead of
>>>>>>> the resource itself, the URN resolver may need to
>>>>>>> extract the required data elements from the URN query
>>>>>>> into an SRU searchRetrieve URL (if the target system
>>>>>>> prefers SRU to URN queries).
>>>>> 
>>>>> I don't think that makes any sense at all, as it either (a)
>>>>> prevents users from passing queries to end resources,
> 
> Passing query to the URN resolver is relatively easy since the 
> functionality provided by the relevant resolvers (specified in RDS
> or indicated more directly with HTTP URI) will be known. Assuming
> that the users will be provided a GUI where they indicate the
> services they want (which are then encoded in queries) people will
> seldom require something that cannot be supplied. For instance,
> when I see a link to the resource, I may indicate with the tick box
> that I want rights metadata about the resource, or technical
> metadata which will tell me which applications will be able to open
> the file.
> 
> It will be an interesting task to manage the situation in which
> the query is somehow passed to the end resource. Do you mean the 
> browser/viewer/whatever in the client end of the process should be
> able to fulfill the service request? I would not like to be the
> person with the task to specify anything like full set of such
> resolution services. Also, given the diversity of the applications
> used, it will not be easy to guarantee that the client process does
> not query services that cannot be supplied.
> 
> As I see it, queries will primarily be used for passing service
> requests to the URN resolvers. Such functionality makes a lot of
> sense, at least from implementer point of view. But in order to
> future proof the syntax it should also be able to specify queries
> which should be processed in the client end.

I understand why we might want to pass queries to resolvers.

I don't understand why we need to pass those queries as part of URNs
themselves.

It appears that the designers of some systems currently deployed have
decided that passing queries in URNs is a good idea. As far as I can
see, even though we don't know why they did so, this WG is essentially
being asked to validate that decision.

Peter

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Oct 2013 10:00:27 -0400

--On Wednesday, October 30, 2013 21:26 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>> As I see it, queries will primarily be used for passing
>> service requests to the URN resolvers. Such functionality
>> makes a lot of sense, at least from implementer point of
>> view. But in order to future proof the syntax it should also
>> be able to specify queries which should be processed in the
>> client end.
> 
> I don't understand why we need to pass those queries as part
> of URNs themselves.
> 
> It appears that the designers of some systems currently
> deployed have decided that passing queries in URNs is a good
> idea. As far as I can see, even though we don't know why they
> did so, this WG is essentially being asked to validate that
> decision.

Peter,

Perhaps stupidly, I put off trying to respond to some of the
threads until after some documents and a WG Last Call analysis
appeared and have now completely lost whatever my train of
thought was at the time.  As a result, I may be missing
something that would change the comments below.  But...

First of all, I think Juha and others have given several reasons
why queries "as part of" URNs are necessary, with references
into named objects being key among them.  One might be able to
meet most of those needs with fragments instead, but doing so
would essentially turn fragment identifiers into queries.
Probably that is not a good idea although I'm not sure I
understand all of the implications either way.

More important, IMO, is a problem I would describe in terms
other than "validate that decision".  There are folks who are
using URNs (or at least things they consider URNs).  They have
discovered that they need queries and need queries with certain
properties.  They have made it clear that they are deploying
those URNs, in several cases at very large (and growing) scale
and using them as named identifiers that are very stable with
objects that have very long expected lifetimes. 

I think that leaves the IETF with several choices:

(1) We can say "not in _our_ URNs", which is what I read your
response above and the one to Martin as saying.  Perhaps I
misunderstand your intent, but the option still exists.

(2) We can say "the URI spec makes that idea bad news, so not in
our URNs".

(3) We can pretend the problem doesn't exist and just approve
2141bis and the mythical
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07 more or less as they
exist today, without addressing queries at all.  There is a
difference between this and (1), but it isn't huge.

(4) We can work with those groups to get some appropriate query
syntax into URNs and define their syntax and semantics
appropriately.  

(5) We can explain to those groups the reasons why, if queries
are needed, they don't belong in URNs and they should be using
something else or something supplemental.  If part of that
explanation requires a new URI type or a new near-URI type
(i.e., something that is conceptually URI-like but that would
not conform to RFC 3986) we'd better sketch it out and be ready
to explain why it is better than URNs-with-queries and/or why it
should or should not gradually supercede URNs.  Whatever that
explanation is, the other groups need to find it persuasive,
i.e., the decision about whether it is persuasive or not is not
up to the IETF.  If we take this approach and are not
persuasive, there is no difference between this choice as (1)
above.

Now, if those other groups were some collection of loonies who
want to complement the FUSSP [1] with the Final Ultimate
Solution to the Identifier Problem (FUSIP ?), it would probably
be entirely reasonable to ignore them or, better yet, refer them
to either ICANN or groups who are thinking grand thoughts about
universal semantics.  At least some of them aren't.  They
include, instead, national archive and repository libraries.  It
isn't hard to make a case that they know far more about
identifiers, identifier and object stability, and similar things
than the IETF does, nor to extrapolate from history that they
will be around long after the IETF has been forgotten. 

Because of that situation, I believe that choices (1), (2), or
(3) (or an unpersuasive (5)) will result in a fork in the URN
definition.  Whether the non-IETF branch is formalized or not is
a separate question but, if it is not formalized by someone and
conformed to, we will likely have multiple solutions that don't
completely interoperate with each other, much less with
2141bis-style URNs. 

That leads me to believe that we had better suck it up and
either define URN queries in some reasonable way or propose a
plausible alternative.  Or we should find some body that wants
to do the work, close the WG, and turn the URN definition over
to them. 

best,
   john

[1] http://www.rhyolite.com/anti-spam/you-might-be.html