Re: [urn] harm of adding query parameters in general

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

--On Sunday, July 20, 2014 01:04 +0000 Larry Masinter
<[e-mail]> wrote:

> I wrote:
>> c) what is being suggested (and motivating) -- adding query
>>      parameters -- is actively harmful for non-document
>>     applications of URNs
> 
> And Andy asked:
>> Can you elaborate on this? Can you provide a specific example?
> 
> The arguments are similar to those made in BCP 190, RFC 7320,
> URI Design and Ownership. Here are two examples:
>...
> But when you add query parameters, the URN with query
> parameters is no longer managed, but is a reference to some
> initial state in a resolution method that is defined outside
> of the URN space itself.  (One might argue that this benefits
> of URNs isn't as strong as claimed, but it's at the core of
> what distinguishes URNs from 'Cool URLs')

Larry,

Most of the discussions about this would add provision for some
parameters or parameter-like things (you can read "query
parameters" into that, but I'm trying to be very general right
now) to the syntax.   2141 didn't ban that, it just reserved
them for future extensions.  At least according to WG
discussions that have been going on more years than I care to
think about, the actual use of the things would then be a
per-NID matter.  If one used them with an existing, unmodified,
and otherwise conforming NID, what would happen to them would be
whatever happens today -- presumably they would be rejected by
careful implementations and ignored by others.  

For NIDs whose registrations explicitly allowed them, they would
be allowed.

If someone proposed to change a given existing NID to allow
them, that decision would need to be made one NID at a time and
would presumably have to analyze and deal with any compatibility
tradeoffs.   When, for example, ISO TC 46 members and the ISBN
Registration Agency tell us they don't see a problem with
allowing queries to be associated with ISBNs and you tell us it
would cause grave harm to that particular URN NID because of
some generic issues, my personal opinion is that they carry
slightly more weight.  You presumably disagree.

It seems to me that what you are arguing is that, if they are
allowed anywhere, then they would be allowed, with the same
semantics, for all URNs.  Not only do I not see anything in 2141
that requires that, I don't think it is a requirement even for
http-URLs.  If it were a requirement for all URIs in 3986, then
existing SIP and other heavily-used URIs would be
non-conforming.  For URNs, if that were true, it would just
strengthen the argument for separation of URNs from all or part
of the 3986 URI definition.

If that is not your position, I still don't understand it.

URNs don't all have the same semantics today.  If they did, we
couldn't have some that act purely as indicators (e.g., the XMPP
case) and others that rely on a variety of resolution methods,
some defined in an IETF context such as DDDS and some not.
 
> 2. In the mail thread containing
> http://www.ietf.org/mail-archive/web/urn/current/msg02282.html
> Peter Saint-Andre noted the use of urn:ietf:rfc:3264 to
> identify the feature defined in RFC 3264 rather than the
> document itself.  However,
> http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn
> claims:
> 
>>  If a query component, fragment identifier component, or both
>>  have been appended to the assigned URN, they MUST be ignored
>>   for purposes
>  >  of determining equivalence.
 
> For the application Peter described, rfc2141bis demands that
> the query component be ignored for the purpose of determining
> equivalence.  If taken literally, this would break all
> implementations that merely do a string comparison.

If 2141bis, which, IMO, has somewhat lagged some of the thinking
in the WG, says the wrong things, it should (and presumably
will) be updated.

This is an area where I, and I presume other WG participants,
would welcome your constructive suggestions.

> Both of these problems arise because URNBIS Is attempting to
> redefine something that was previously defined to have a
> syntax and semantics, and there are deployed applications that
> rely on those semantics, while the new applications imagined
> that might use the changed syntax and semantics are not
> deployed and have little or no implementation experience.  If
> URNBIS defined a new URI scheme "urnq" whose definition was
> "Exactly like urn: except that query and fragment components
> are allowed" then at least existing applications which make
> assumptions about URIs that start with "urn:" wouldn't have
> those assumptions broken.

Like Andy (at least prior to this note of yours), I'm confused
about why you see an issue with some NIDs being registered as
allowing the use of some syntax that other NIDs don't allow.  I
don't see that as being any different from some http-URLs
utilizing queries where others don't (and, in practice, either
ignore them or emit unpleasant messages).  I believe that
http-URL case should be a much more restrictive one than for
URNs.  Your case that it creates an incompatibility would be
stronger if 2141 prohibited the use of queries, fragments, etc.,
forever, but it doesn't.  As I read it, it explicitly reserves
them for future extension.  And not only can 3986 not somehow
implicitly change that to make a permanent restriction (it
certainly doesn't say "updates 2141" anywhere), but arguments
that it, or for that matter 7320, constrain what the WG can do
merely strengthen the argument for the separation of URNs from
generic URIs.

That is part of the problem the WG faces.  If there is really a
requirement and 3986 is interpreted as "you can't do that", then
there is an incentive to either find ways to get around 3986
while meeting the requirement (while I don't particularly like
the results, Dale Worley has been, IMO, quite creative about
that) or to separate the two (which some members of the
community believe should have been done as a condition of
approval of 3986).  More on this below, but my own position at
this stage is "whatever is needed to make progress on something
that will serve the URN communities (not plural) well for the
long term".  Just my opinion, even though, for reasons discussed
below, I don't see "just say 'no'" as an option.

I also suggest that, carried to their logical extreme, the
position I understand you to be taking would make both HTTPbis
and the WHATWG-W3C effort to redefine URLs impossible.
Certainly any effort to fold non-ASCII characters into URLs
violates the syntax and semantic constraints of 3986 to a degree
that not even "httpi" would fix and, at least to my knowledge,
no one has proposed than the method name be changed.

As far as "urnq" is concerned, I think there are two important
reasons why that isn't a good solution, with the second much
more important than the first.

(1) As discussed above, I don't think that it is necessary.  It
would certainly be disruptive to a lot of existing uses and
users.  At least so far, I don't believe the WG is convinced
that there is a problem serious enough to justify a new method
identifier.

(2) The community out there that believes (in good faith and on
the basis of what they believe is many centuries of experience
with the kinds of identifiers and identifier-qualifiers that
they are asking for) that they need some additional qualifying
syntax associated with URNs to identify or request specific
metadata or portions of named information is (contrary to what
might be read into your "no experience" assertion) large and
organized.  They have URNs of various sorts widely deployed,
with millions of assigned identifiers (NID+NSS) in use.  They
have been developing and using extensions that go beyond 2141
out of what they see as necessity and on the their own but have
been waiting patiently for the IETF to draw things back together
and standardize a set of clarifications and extensions to the
standard that meets their needs.    Now, the IETF could
certainly say "sorry, but you don't get to call those URNs, call
them URNQs or something else".  I believe, based on informal
discussions within their well-established standard bodies, that
their reaction would be a more polite version of "you can't tell
us what we can't do", followed by standards development in those
bodies that would use the term and method "urn" and would build
compatibly (by their definition) on the principles of 2141 but
would ignore 3986 and anything else that got in the way of their
meeting their needs.  Because it is not their area of expertise,
some of the changes they might make might be accidentally
hostile to some non-document or non-resolvable uses of URNs.  

If that community were a hastily-organized ad hoc Consortium for
a New URN, it would probably be safe to ignore them.  It isn't
-- again, some of their institutions are many hundreds of years
old and some of them even have the ability to turn Voluntary
Standards into Regulations or legal Requirements.    Encouraging
(or forcing) them to go off in their own direction would
essentially lead us to a forked standard -- two different, and
inconsistent, URN specifications.   If they do develop their
own, forked, standard, very few of us will have a seat at the
table (although the larger customers of some of the companies
who pay people to do this work in the IETF might).   I think
that is pretty close to worst case.  I therefore think we should
be working on finding creative ways to keep the various
communities together and focused on a single standard rather
than explaining why that cannot be done.  I'm willing to do
things I actually find quite uncomfortable --such as proposing a
URN-URI separation mechanism-- in order to meet the goal of
retaining a single URN standard with a single SDO responsible
for change control.   YMMD, of course.

      john

p.s. In case it isn't clear from the above or other things, I'm
not a fan of draft-ietf-urnbis-urns-are-not-uris.  I wrote it
for the convenience of the WG because several of us concluded it
is was necessary expedient.   I'd be the first to welcome a
better solution, again with the understanding that I don't
believe "just say 'no'" is a plausible part of the solution
space.  I guess I get to say that again next Friday.