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

[Julian Reschke <[e-mail]>]

On 2017-01-07 22:44, John C Klensin wrote:
> 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.

Well, I checked -19 before sending the mail. Feedback is feedback.

> --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.

It probably would be sufficient to move the overview in front of the ABNF.

> ...
>>> ...
>>>    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.
> ...

So we agree on what RFC 3986 says :-). I think the right conclusion is 
to strip the prose wrt RFC 3986. Just say:

"Neither the general syntax nor the semantics of q-components are
defined by, or dependent on, the namespace of the URN.  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."

>>> ...
>>>    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.

...I prefer to process documents with known problems fixed. That said, 
there's an IETF LC before that anyway, so whatever the WG submits after 
WG LC is very unlikely what gets to the RFC Editor anyway.

Best regards, Julian