Subject: [urn] The "needs" (was: Re: Tomorrow''s "URNs are not URIs" topic)

From: John C Klensin <[email-masked]>
Date: Fri, 25 Jul 2014 07:34:33 -0400

Hi.

I was asked in a non-list note what the "needs" are, why they
haven't been more explicit, and, at least implicitly, why I
didn't address them.  To save probably having to answer that
question multiple times, I'm going to protect the anonymity of
the question but answer on-list.

That slide deck already pushes pretty hard on my mandate to
discuss the "URNs are not..." draft (and Andy may beat me up and
get me to narrow it).  So I didn't try to summarize the
needs/requests for that reason and a more important one.  

The latter is that I'm just trying to bring things together on
this and prevent what I otherwise see as an inevitable fork,
probably in multiple directions.  I prefer that those with
requirements not met by 2141 would speak for themselves.  In
several cases, I think they have but one of our problems in this
WG is different communities speaking in different conceptual
languages and not being understood by others (even at the level
of whether and what requirements are being stated).  I may well
have a version of that problem that causes me to inadequately
understand what people are asking for.

I still really hope that those who have expressed those
requirements will explain them in clear form (in some cases,
"again") either on-list or in today's meeting.  What follows is
_not_ really adequate.

But, again in the hope of moving things forward and the further
hope that people will correct me if I've gotten things wrong,
things I think I've heard include the following in mo particular
order:

(1) RFC 3986 is quite clear that its comparison rules (for
determining whether two URIs are equivalent) are designed to
produce zero false positives with the expectation of lots of
false negatives.   It also suggests that the ultimate criterion
for URI equality involves retrieving the objects pointed to by
two URI strings and then comparing them, with comparison
criteria presumably depending on media type or other
content-specific features.   Precisely because a lot of URNs are
defined without content or used without the expectation of
retrieving content, somewhat deeper criteria --fewer false
negatives-- for URN comparison may be in order.  The query set
example I used in the slides is a rather trivial example of that
issue should the WG want to go in that direction, but I gather
that there are other concerns and cases people would like to
have covered.

(2) As a sort of extension to the above, I think I've heard
requests for even finer control of matching/comparison with,
e.g., some query terms (or fragment terms) participating in
matching and others not.  If that is real, we need syntax or
other mechanisms to denote which is which.  And, of course, we
need to define "terms", which immediately takes us beyond 3986.
I discussed that possibility further on-list some months ago
with comments about a possible four-tuple to be specified in
registration, part of a "query", or otherwise and summarized
that option in the temporary appendix B to urns-are-not-uri-01.
I hope then and hope now that we don't need to go that far, but
I think it represents the most general case (and a rather
different data model from 3986, regardless of what can be forced
into the latter).

(3) It has been pointed out that, if one has a name that is
associated with an object, one might be interested in lots of
aspects of that name, including the object, a whole lot of
properties of the object, the number and locations of instances
of the object (perhaps up to some ceiling), and so on for a
rather long list.  One of the philosophical issues I've been
trying to avoid under the "if we tell 'them' what to do, they
are likely to ignore us and fork the spec instead" umbrella is
that one can, in principle, express those things with
constructions like:

ObjectRetrieverFromName://resolver-retriever-domain/parametric-stuff?urn:foo:name-describing-stuff

One could use similar things for different types of data,
metadata, or inquiries.   Note that, if additional query
information is needed that would naturally go in queries, any
notion of hierarchy or association-bindings in the query is, as
Martin indirectly pointed out, a matter of very local
conventions.  If one believed those associations were needed in
syntax for all URNs or probably even on an NID basis, that would
constitute a requirement that 3986 does not meet and may, if
read narrowly, not allow a URI to meet.

If, by contrast one wants some of that information bound to or
as a conceptual part of a URN (one not embedded in some other
URI string), it appears that one at least needs queries in URNs
and may need an extended version of what 3986 specifies as query
syntax.  That, as discussed elsewhere, may require somewhat more
specificity about comparisons, relationships among information
or requests, and so on than are permitted by 3986's
effectively-atomic query string, whether the internal delimiters
are "%", "?", both, or something else.   See the response to
Martin, the slides, and the discussion of 4-tuples above for
cases that represent different degrees of extreme.

best,
   john