Re: [urn] Preferences and Choice matrix

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

--On Monday, 28 July, 2014 06:13 -0400 Keith Moore
<[e-mail]> wrote:

> On 07/27/2014 03:35 AM, "Martin J. Dürst" wrote:
>> I actually think it's utterly consistent with RFC 3986. RFC
>> 3986 only  says that it's "scheme definable". This means that
>> a scheme can define  what it wants.
>> 
> Yes, 3986 allows a scheme to define what it wants.   The
> reason that "?" should not have a namespace-specific meaning
> is not because 3986 prohibits it.
> 
> Some reasons that "?" should not have a namespace-specific
> meaning are:
>...

Can I encourage you to be a little bit more specific about what
you are talking about and specifically what you mean by
"meaning"?  For example, I don't have much problem with saying
"ok, there are things that, for lack of a better term, we will
call 'queries'.  From the standpoint of syntax the query
collection starts with "?" and continues to the end of the URI
string or the first occurrence of '#'.  After that, their
interpretation is pretty much an NID problem".  Up to the last
sentence that is, I think, pretty much what 3986 says.  The last
sentence is problematic is one believes that 3986 makes query
interpretation a per-scheme problem that can't be delegated to
NID registrations.  

That interpretation is more than sufficient to make generic URI
parsers, and even more specific generic URN parsers feasible.

Where things get complicated is when wants to specify syntax or
interpretation/semantics _within_ the query string.  I can see
doing that for at least one more layer on an "all-URNs" basis,
but believe we would have to be very careful about
extensibility.  Proposals to create a closed list of keywords
with "all-URN" interpretations scare me because I don't think we
can get that right in a single attempt.    But, if one can
specify that on a per-NID basis, I don't see any problem even
though I personally think it would be desirable to push a level
further down (see below).

Similarly, in a world of generalized URNs, I think one needs to
be very careful about rules about what is included in URN
equality or about the context in which something is evaluated.
If those things are specified for all URNs (or all URIs), then I
think we are likely to get into trouble given some of the
examples Juha, Lars, and others have given.   On the other hand,
if they are pushed down to the NID level, then the registry (or
some information without the query string itself) has to be
consulted before performing those interpretations.  That isn't
impossible, but it would certainly be inconvenient for many
purposes (that statement is intended to be consistent with
Leslie's "not only tricky, it's likely to lead to heartbreak",
which which I agree.

One could pretty much substitute "fragment/ #" or "/" with some
appropriate words for "query / ?" above without changing much,
if anything.



--On Wednesday, 30 July, 2014 11:11 -0400 "Leslie Daigle (TCE)"
<[e-mail]> wrote:

(paragraphs rearranged for my convenience)

> Thumbwrestling about interpretations of RFC3986 is distracting
> from the hard problem, IMO.

Agreed.  See my prior note about the new version of the
separation draft.   In retrospect, the Toronto meeting was
disappointing because we ended up spending almost all of our
time on that issue and hence couldn't get to the ones that you
and Keith are now raising.

> Getting beyond the meta, I'd like to see actual proposals for
> how to handle facets (whether using the "?" and "#" or not) in
> a way that works consistently across all persistent
> identifiers.

> I don't have a proposal to kick off the discussion, as I am a
> self-admitted skeptic :-)

Various of us have tried to identify types of URNs and, in some
cases, the differences among their requirements.   At other
times, we have tried to predict the future, both in terms of
requirements and in terms of whether new types will be
discovered.  Against that background, the only thing I know how
to propose is fully general, e.g., the four-tuple Service
Request described in Appendix B of
draft-ietf-urnbis-urns-are-not-uris-01 and some earlier notes.
I hope we can be less general than that, but I'm not convinced
yet, especially if strong equality comparisons for URNs (high on
the "fewer false negatives" ladder but without relying on
comparison of retrieved content are desired.

It would, FWIW, be completely rational to use "?" to introduce
service requests that are interpreted "outside" the URN and URN
comparisons and "/" for ones that are interpreted "inside" the
URN and that count in comparisons if that distinction were
sufficient.  If it were and we went down that path, the
four-tuple would drop to a three-tuple.

However, to remove some of the noise from that discussion, I
suggest it would be useful to concentrate on what we want those
Service Requests to be able to do, specify, and how and where
they are interpreted, rather than on their syntax.


> To further remove noise from that discussion, I think having
> the discussion in the abstract -- e.g., for a new
> [UR]identifier, as Joe Hildebrand suggested at the meeting
> last week -- might be helpful.

Works for me with one qualification, which is almost the same
qualification I would apply to "use '/' and not '?'".  I believe
we are stretching the patience of those who have been waiting
for us to bring this work to a useful and usable conclusion but
who have been assigning and using millions of URNs in the
meantime.  The result of pushing them too far is fairly clear --
we end up with a forked standard published by a group that has
far more credibility in parts of the URN-using community than
the IETF does.  Except that most of that community it far too
polite, I think the effect of any "don't use URNs, use URXs or
XXNs instead and you can start converting your millions of URNs
now" would be a lot of rude language and precisely that form.
Put differently, if thinking about this as a new URI type helps
us move things forward, that is fine, but an actual proposal
that URNs, or URNs beyond what 2141 allows, be actually replaced
by such a type, would be likely to be ignored in the marketplace
(or worse).

    john