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

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

--On Wednesday, October 30, 2013 21:26 -0600 Peter Saint-Andre
<[e-mail]> 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 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,

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