Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-15

From: John C Klensin <[email-masked]>
Date: Thu, 04 Feb 2016 08:31:04 -0500

Hi.

draft-ietf-urnbis-rfc2141bis-urn-15 is in the posting queue and
should be posted later today.

Significant changes, all except the first discussed on-list in
one form or another:

(1) Some rearrangements and editorial changes to make the
document more clear (not really significant).

(2) Explicit text about the situation we are in and avoidance of
topics that would require boiling oceans, etc.

(3) Changed syntax for r-component and q-component and a much
more restricted explanation of what the latter is about
(although the idea of a resolver-ID has been incorporated)

(4) A bit more discussion of character sets and coding.

See the change log and the document itself for more information.

Please review.  While reviewing, note that we have not done a
careful review of the contents of the registration template in
comparison to the more general text in some time and please do
that an check for consistency.

Personal opinion, but I hope this is the last version of 2141bis
with significant and substantive changes.  I expect we will need
one more pass/ revision before WG LC, but don't expect major
changes.  If I'm wrong about that, we should get on with it, but
please see Barry's recent note.

  best,
    john

---

From: Sean Leonard <[email-masked]>
Date: Sat, 20 Feb 2016 21:10:04 -0800

Editorial issues for urnbis-rfc2141bis-urn-15:

Several dots that do not function as periods are followed by two spaces, 
e.g., Section 1.1: "their uses outlined (Cf.  [RFC 1737]) issues of 
persistent identifiers". I suspect this is an artifact of the xml2rfc 
process, but it's not good and should be squelched.

Section 2.1:
NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent) as
a consequence of requirements imposed by RFC 3986.

That is not actually true. The entire NID : NSS production conforms to 
the path-rootless rule; paths are case-sensitive at the URI level of 
abstraction. (Specific schemes can make parts of the path 
case-insensitive.) You might be confusing this with the host rule, which 
is case-insensitive (RFC 3986 Section 3.2.2). I am calling this 
"editorial" simply because that new text about RFC 3986 is not accurate 
about RFC 3986.

Section 2.3:

Interpretation of r-components is discused in
Section 2.3.2 below.

Change to:
The interpretation of r-components is discussed in Section 2.3.2 below.

Section 6.1:

  2.  The syntax of URNs assigned within the namespace, including the
      internal syntax and anticipated effects of q-components or
      r-components (syntax and interpretation of f-components appears
      in RFC 3986).

"The" is needed in the parenthetical. I would prefer this to read:

  2.  The syntax of URNs assigned within the namespace, including the
      internal syntax and anticipated effects of q-components or
      r-components.  The syntax and interpretation of f-components
      appears in RFC 3986.

(Actually I take issue with this item on a technical basis, but I shall 
save that for my non-editorial e-mail.)

Sean

On 2/4/2016 5:31 AM, John C Klensin wrote:
> Please review.

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 Feb 2016 10:30:32 -0500

--On Saturday, February 20, 2016 9:10 PM -0800 Sean Leonard
<[email-masked]> wrote:

> Several dots that do not function as periods are followed by
> two spaces, e.g., Section 1.1: "their uses outlined (Cf.  [RFC
> 1737]) issues of persistent identifiers". I suspect this is an
> artifact of the xml2rfc process, but it's not good and should
> be squelched.

Thanks.  You can take this up on the rfc-interest or xml2rfc
list if you like.  Those sorts of issue are supposed to be XML
stylesheet matters and, even if we went to the trouble to patch
around it now (and I/we could figure out how), the risk would be
high that things would be fouled up again the next time I hand
off to Peter (we are using different tools) or we hand off to
the RFC Editor.  I have inserted a comment to the latter into
the XML to remind them to pay attention to this.
> That is not actually true. The entire NID : NSS production
> conforms to the path-rootless rule; paths are case-sensitive
> at the URI level of abstraction. (Specific schemes can make
> parts of the path case-insensitive.) You might be confusing
> this with the host rule, which is case-insensitive (RFC 3986
> Section 3.2.2). I am calling this "editorial" simply because
> that new text about RFC 3986 is not accurate about RFC 3986.

But the rule about case-insensitivity in NIDs goes back to 2141
and earlier.  What fix would you like to see?  I could insert a
sentence (probably starting "Nonetheless...") in the discussion
of the relationship to 3986, but I'm not at all confident that
would be satisfactory.  Suggested text would be appreciated.

> The interpretation of r-components is discussed in Section

I can argue this either way and materials above it are a tad
inconsistent, but I've changed the working copy to reflect the
above.  However, the change comes with the warning that it is
quite possible that the RFC Editor will undo the change or make
other changes and the odds of our (or at least my) fighting them
about it are about zero).

> Section 6.1:
> 
>   2.  The syntax of URNs assigned within the namespace,
> including the iinternal syntax and anticipated effects of
> q-components or r-components (syntax and interpretation of
> f-components appears in RFC 3986).

>   2.  The syntax of URNs assigned within the namespace,
> including the internal syntax and anticipated effects of
> q-components or r-components.  The syntax and interpretation
> of f-components appears in RFC 3986.

Changed as indicated.   Note to others: in future, comments like
this are likely to turn into "please see how you feel about
this" notes to the RFC Editor.

>...

    john

---

From: Sean Leonard <[email-masked]>
Date: Sun, 21 Feb 2016 07:43:28 -0800

> the XML to remind them to pay attention to this.

Okay. It may be that "Cf." is the problem, instead of "cf." (lowercase). 
I have reason to believe that some abbreviations such as "cf." and 
"i.e." have manual overrides in the source code.

> would be satisfactory.  Suggested text would be appreciated.

Suggested:
NIDs are case-insensitive.

No reference to RFC 3986. Also the example is not terribly illuminating. 
We know what case-sensitivity is.

Sean

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 Feb 2016 11:03:29 -0500

--On Sunday, February 21, 2016 7:43 AM -0800 Sean Leonard
<[email-masked]> wrote:

>>> two spaces, e.g., Section 1.1: "their uses outlined (Cf.
>>> [RFC 1737]) issues of persistent identifiers". I suspect
>>> this is an artifact of the xml2rfc process, but it's not
>>> good and should be squelched.
>> stylesheet matters and, even if we went to the trouble to
>> patch around it now (and I/we could figure out how), the risk
>> would be high that things would be fouled up again the next
>> time I hand off to Peter (we are using different tools) or we
>> hand off to the RFC Editor.  I have inserted a comment to the
>> latter into the XML to remind them to pay attention to this.
> 
> Okay. It may be that "Cf." is the problem, instead of "cf."
> (lowercase). I have reason to believe that some abbreviations
> such as "cf." and "i.e." have manual overrides in the source
> code.

But that is part of my point because "the source code" is not am
unambiguous reference because it could be "source code of the
version Peter is using, source code of the version I'm using,
source code of today's online version, source code for v3, etc.  

WG co-chairs: please either overrule me (in which case I'll try
to replace all of the relevant periods with an XML entity when I
find/ get a round tuit) or rule further discussion along these
lines out of order.

>> But the rule about case-insensitivity in NIDs goes back to
>> 2141 and earlier.  What fix would you like to see?  I could
>> insert a sentence (probably starting "Nonetheless...") in the
>> discussion of the relationship to 3986, but I'm not at all
>> confident that would be satisfactory.  Suggested text would
>> be appreciated.
> 
> Suggested:
> No reference to RFC 3986. Also the example is not terribly
> illuminating. We know what case-sensitivity is.

Reference to 3986 dropped unless someone else objects (my vague
recollection is that we were told, at one state, to put it in).
Same for the example so I'm disinclined to remove it unless
others think it is a problem.

    john

---

From: Barry Leiba <[email-masked]>
Date: Sun, 21 Feb 2016 09:18:57 -0800

> source code of today's online version, source code for v3, etc.

We've already spent more cycles in the several messages about this
than it's worth.  This is (1) a total nit and (2) an artifact of the
tools we're using.  Please, let's just stop getting wound up about
things like this.

I think it's great that the document is in such good shape that we
have to call out minor misspellings and question the number of spaces
after dots.  That attests to the great job done by the editor; thanks,
John.

That said, let's go easy on the nitpicking, and really try to focus on
the content.  If there are editorial issues that affect the meaning,
let's absolutely get those right.  For other editorial issues it's
fine to note them, and it's also fine to say, "Thanks for the
editorial notes," and not to respond to each one.

Barry