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

[Peter Saint-Andre <[e-mail]>]

On 10/31/13 7:00 AM, John C Klensin wrote:
> 
> 
> --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. 

Hi John,

In fact, your (4) is not, to me, unreasonable -- but I haven't seen a
clear story about why it's needed.

I do think that I understand the concerns of those who say that using
the existing URI query syntax for passing information to URN resolvers
might be problematic. If we accept that reasoning, then using some other
delimiter (such as '/') for the URN-query-component (whatever we call
such a beast) might make sense.

In your (4), do you think that we need to use the URI query syntax or do
you instead think that the folks you mention above might be open to
using some other syntax?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/