Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16

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

Julian,

My belief is that these issues have already been dealt with in
-19 or earlier.   If you disagree and consider the issues
substantive enough to meet the criteria Barry laid out, please
explain.  Some comments below.

--On Saturday, January 7, 2017 18:42 +0100 Julian Reschke
<[e-mail]> wrote:

> Reviewing my own feedback from 7 months ago and reposting
> those parts that still seem to apply...:
> 
> On 2016-04-27 20:11, Julian Reschke wrote:
>> 
>>       rq-components =  ( "?="  q-component
>>                           [ "?+" r-component ] ) /
>>                        ( "?+" r-component
>>                           [ "?="  q-component ] )
>>       q-component   = pchar *( pchar / "/" / "?" )
>>       r-component   = pchar *( pchar / "/" / "?" )
>>       f-component   = fragment
>> 
>> These come as a surprise to anybody not already familiar to
>> what led to the spec.

>> Either introduce them later, or insert some prose explaining
>> where they come from.

The paragraph immediately above the syntax in Section 2 ("The
basic syntax for a URN is defined...") now contains explicit
forward pointers to the relevant defining sections.  If you
think more is needed, please explain and propose text.  Whether
one soul supply syntax before or after the explanation of what
the elements are about is a matter of taste; when I've done it
one way in a proposed RFC, I'm been attached and when I've done
it the other way, I've been attacked too, so, speaking
personally and as co-editor, I'm no longer interested in the
discussion.

>> Also, it would be good if there was a discussion about
>> compatibility with existing use of queries, as these
>> essentially reserve certain variants of queries for generic
>> use.

I believe there is now fairly extensive discussion on that
topic.  Again, if you think more is needed, please explain and,
ideally, supply text.  Note, however, that there is no "existing
use of queries" within the URN scheme as defined in RFC 2141.
Going very much further than 2141bis goes now (which is, IIR,
further than -16 did) is ultimately not about the "urn:" scheme
but interpretation of 3986 including both what it says and what
it omits.  

Some of those issues have been discussed fairly extensively on
the mailing list but, at least IMO, if the WG has neither
mandate nor authorization to update or otherwise modify 3986,
then the inevitable corollary is that 3986 needs to stand on its
own.  The new comments about potentially-conflicting terminology
or language was motivated precisely by WG discussions of related
issues.

>> ...
>>    For the sake of consistency with RFC 3986, neither the
>>    general syntax nor the semantics of q-components are
>>    defined by, or dependent on, the namespace of the URN.  In
>>    parallel with RFC 3896, specifics of syntax and semantics,
>>    e.g., which keywords or terms are meaningful, of course
>>    may depend on a particular namespace or even a particular
>>    resource.
>> 
>> I agree that this is the right thing to do, but I'm not sure
>> what this has to do with 3986.  3986 allows a scheme to
>> mandate a specific syntax, no?

Yes, at least as I read it.   But, IIR, there have been some
claims that 3986 does not obviously allow a scheme to delegate
the syntax to other (non-scheme) parts of the URI (specifically
a namespace in the urn scheme case).   At this point, I would
personally prefer sentences to the effect of "no matter what you
think 3986 says, URNs works this way...", but I don't think that
a proposal like that would be constructive or helpful.   If you
think this is important and want to propose alternate text,
please do so.

>> ...
>>    For the sake of consistency with RFC 3986, neither the
>>    general syntax nor the semantics of f-components are
>>    defined by, or dependent on, the namespace of the URN.  In
>>    parallel with RFC 3896, specifics of syntax and semantics,
>>    e.g., which keywords or terms are meaningful, of course
>>    may depend on a particular namespace or even a particular
>>    resource.
>> 
>> s/3896/3986/

I thought we had caught all of those.  Both remaining cases, now
corrected in the working draft of -20 (which, unless major
issues show up or Barry directs otherwise, will appear only
after the informal WG Last Call ends at the end of the month).
FWIW, even though it is clearly better to fix it now, this is
the sort of thing the RFC Editor is really good at catching and
fixing.

>...

best,
   john