Subject: [urn] Clarification of p-component

From: John C Klensin <[email-masked]>
Date: Sun, 09 Nov 2014 21:32:10 -0500

Hi.

I've just read all of the postings since I tuned out and went on
travel around 24 October.  

I am trying to remain optimistic, but it seems to me that we are
cycling through the same arguments, with people taking what
amount to "either agree with my point of view or we will have no
agreement at all" positions.   If what is wanted is paralysis in
this WG, eventually shutting it down, and movement of the work
into one or more places that won't care about the Grand Unified
Theory of URIs (or even URNs), we seem to be right on track.

In particular, I hope I'm being consistent with Peter and the
draft here, but when I say "p-component", I'm not using a funny
term for 3966 "path".  Instead, I'm talking about a path
component, i.e., a piece of syntax that, for URNs, follows 
   urn:nid:nss/

Allowing a "/", followed by a string, there would allow DOIs to
work and be valid.  It would also allow qualification on the
basic URN string that would be treated "as part of" the URN for
multiple purposes, including comparisons.  It seems to me that
those are desirable things to have, whether a particular NID
allows them (or requires them) or not.  It also seems perfectly
rational to me (and, fwiw, consistent with 3986 syntax
restrictions) for some NIDs to allow the things and others to
not do so.

The reason for allowing p-components at all is, for me,
precisely to allow something that is separate from the NSS (or
the pre-"/" part of the NSS) that sufficiently strongly affects
the rest of the URN to be considered an essential part of that
URN for comparison purposes.  People have made strong arguments
that things that look like queries or fragments cannot provide
that function.   

As far as I can tell, that definition of a p-component works
perfectly well with 3986 URI syntax.  I don't think the question
of whether it matches someone's idea of URI semantics,
especially semantics that are closely tied to URLs, is helpful.

If the presence of that slash causes generic URI parsing systems
that incorporate enough semantics to try to resolve relative
references to try to do that, syntactically, to URN base
references, I think that would constitute a silly state, but not
a silly state that a URN spec needs to go out of its way to
prevent or prohibit.  On the other hand, it seems to me that the
URN spec need not have specific rules about how relative
references are interpreted: they are just invalid for URNs
because they are meaningless.

Finally, as to whether the p-component is part of the NSS
(something defined in 2141 that did not then permit a "/") or
follows it is a bit of definitional wizardry that, IMO, this WG
can work out in whatever way seems convenient.  Neither
definition violates 3989 syntax rules; either could be described
in 2141bis in a way that would be a compatible extension from
2141.  My intuition at the moment says "after the NSS, separated
by that "/" character), but I don't feel really strongly about
it.

We now return you to the usual repetitive, non-convergent,
arguments :-(
 
   john