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

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

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

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

Just my opinion: See Barry's note.  The difficulty with
"feedback is feedback" is that we can quibble endlessly about
small matters of phrasing, organization, etc., and that, if we
are ever going to finish this work, that needs to stop at some
point.   I'll leave determining the point up to the co-chairs
but, again in my opinion, we are past it.

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

See above.  Barry?

>> ...
>>>> ...
>>>>    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 don't know if we do or not.  Some things I know are that I've
spent too many weeks of my life reading and rereading 3986,
trying to understand how it bears and should bear on URNs and
that the WG has spent years circling around the issue.  Another
thing I know is that 3986 is quire clear that it updates and
replaces some URL documents and that, while it includes some
sentences about URNs, it does not identify itself as updating or
replacing RFC 2141 or, for that matter, 3406 or any other
URN-specific document.  Since the WG has no mandate or authority
to update or otherwise modify or clarify 3986, it is equally or
more reasonable that it start from prior URN materials as a
basis as it is that it treat 3986 as definitive.

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

I think that change is probably harmless, but would like to hear
from others before I make the change.  In particular, in either
version, whether the sentence(s) are meaningful at all depends
on the distinction between what are "general syntax" and
"[general ?] semantics" versus "specifics of syntax and
semantics".  The previous form tied that distinction to 3986,
even though it is not clear to me that it made the distinction
clear either.   Perhaps it is just late at night but, with the
3986 references removed, I just don't see a clear boundary.

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

So do I, which is why the fix has been applied.  I was just
trying to suggest that, had this fallen through the cracks, it
almost certainly would have been caught in final editing.

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

If that implies that you expect a complete rewrite as the result
of IETF LC, noted.

best,
    john