Subject: Re: Last Call: <draft-ietf-urnbis-rfc2141bis-urn-20.txt> (Uniform Resource Names (URNs)) to Proposed Standard

From: tom p. <[email-masked]>
Date: Tue, 21 Feb 2017 12:25:51 +0000

I would like to see

Updates RFC3986

on this.

It says
"   discussions of URNs and URN namespaces should be interpreted
   according to this document and not by extrapolation from RFC 3986.
"
which to me says that RFC3986 may not be authoritative for URN and so is
de facto updated.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, February 13, 2017 3:08 PM
Subject: Last Call: <draft-ietf-urnbis-rfc2141bis-urn-20.txt> (Uniform
Resource Names (URNs)) to Proposed Standard

>
> The IESG has received a request from the Uniform Resource Names,
Revised
> WG (urnbis) to consider the following document:
> - 'Uniform Resource Names (URNs)'
>   <draft-ietf-urnbis-rfc2141bis-urn-20.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-02-27. Exceptionally, comments may
be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    A Uniform Resource Name (URN) is a Uniform Resource Identifier
(URI)
>    that is assigned under the "urn" URI scheme and a particular URN
>    namespace, with the intent that the URN will be a persistent,
>    location-independent resource identifier.  With regard to URN
syntax,
>    this document defines the canonical syntax for URNs (in a way that
is
>    consistent with URI syntax), specifies methods for determining URN-
>    equivalence, and discusses URI conformance.  With regard to URN
>    namespaces, this document specifies a method for defining a URN
>    namespace and associating it with a namespace identifier, and
>    describes procedures for registering namespace identifiers with the
>    Internet Assigned Numbers Authority (IANA).  This document
obsoletes
>    both RFC 2141 and RFC 3406.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ballot
/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Feb 2017 10:12:47 -0500

-On Tuesday, February 21, 2017 12:25 +0000 "tom p."
<[email-masked]> wrote:

> I would like to see
> 
> Updates RFC3986
> 
> on this.
> 
> It says
> "   discussions of URNs and URN namespaces should be
> interpreted    according to this document and not by
> extrapolation from RFC 3986. "
> which to me says that RFC3986 may not be authoritative for URN
> and so is de facto updated.

Tom,

Speaking as a WG participate, with no particular authority...

I'm afraid my response to this is going to be a lot longer than
"yeah, we forgot that".  We definitely didn't and I hope you and
any others with this concern will take the time to understand
the explanation below (and, if needed, the two expired I-Ds it
mentions) before pursuing it further.

The question of the exact relationship to 3986 has been
discussed extensively and repeatedly in the WG.  One way of
looking at the problem is that it is impossible to define URNs
the way the WG has concluded they need to be defined to meet the
needs of important user communities without pushing a bit on the
boundaries of 3986.  That is complicated by the observation that
3986 asserts that it covers UNRs, makes the distinction between
URNs (of both the "urn:" scheme covered by 2141 and some unnamed
other varieties) and URLs, but then proceeds to talk almost
exclusively about things that look like URLs to at least some of
use, and effectively modifying some things specified by 2141
without updating RFC 2141 (or even mentioning it in the context
of a statement about the "urn:" scheme.

The situation is further confused by disagreement in the
community about whether 3986 is basically a syntax document with
a lot of explanation and examples about what the syntax means,
whether all of it is normative and prescriptive (even though
there are many alternatives for some of the cases), or somewhere
in between.

The WG considered a series of options, including 

 (1) explicitly updating 3986 to point out some of the
	issues
	
 (2) Modifying the scope of 3986 to remove URNs from it.
	
 (3) Taking the position that, since 3986 claims to be
	about syntax and says almost nothing about name-type
	URIs (as distinct from locator-type ones), it was
	reasonable to have URNs conform to the syntax but ignore
	3986 semantics, especially when they appear to be
	specific to the needs of locators.

Of these the first was quickly rejected as out of scope and
possibly out of the core competence of the WG.  There are
definitely people who have participated in the WG (myself
included) who believe it would be desirable to open 3986, clean
up a lot of text, make it actually conform to the ABNF specs,
etc., but who see that as a very different project from the URN
update represented by this document.  The second was considered,
including a draft document (see
https://datatracker.ietf.org/doc/draft-ietf-urnbis-urns-are-not-uris/
) but rejected, I think because it was felt to be too radical
and likely to cause interoperability problems with generic URI
parsers (another issue but off topic for this note).  The WG
adopted a variation on the third.  That model is explained in
more detail in
https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/.

The latter document was allowed to expire after the WG concluded
that it had been useful in facilitating discussions within the
WG and developing the current document but that little or no
purpose would be served by publishing it in the RFC Series.
That I-D, fwiw, did propose to update 3986, but it is not clear
to me that there was ever consensus in the WG for that provision.

So...  While I understand your position, I don't think 2141
alters 3986.  It just uses some terminology and other aspects of
3986 slightly differently than some (but definitely not all)
readers of 3986 have interpreted it.  Some of the language in
2141bis is intended to simply avoid further arguments and lost
time about whether it is completely consistent with 3986 or not.
The sentence before the one from which you quote tries to be
quite explicit about that:

	"... may lead to some interpretations of RFC 3986 and
	this specification that appear (or perhaps actually are)
	not completely consistent,"

In other words, maybe there is a difference, maybe there isn't
(and different people have reached different conclusions) but,
if you think there is, use these definitions.

That would call for "some people think this updates 3968, some
think it is consistent with it" and "Updates: 3986 (maybe)".
There is no provision for the latter in RFCS and the former
seems more abrasive or critical of 3986 than is appropriate.

I hope we can avoid reopening this topic.  Discussions of it
tend to be very painful and to expose what appear to be a lot of
raw nerves.  If there does need to be an "updates" statement, I
think the reasonable way to do it would be to put
draft-ietf-urnbis-semantics-clarif back on the table because it
actually explains the relationship while simply adding an
"updates" line to 2141bis might actually add to the confusion
because it would not provide that clarity.   Speaking very
personally as an overextended editor, I hope that isn't
necessary either.

best,
    john

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Feb 2017 10:37:10 -0500

Adding to what John said, and also narrowing to a key point...

Narrowing:
This point was discussed in the working group, and I believe we do not
have consensus to use "updates" here with respect to 3986.

Adding:
That said, I think it's important for readers of 3986 who are
interested in URNs to come here.  The "updates" metadata would do
that.  Happily, we have even more targeted metadata that will do it
better.  3986 says this in Section 1.1.3:

   The term "Uniform Resource Name"
   (URN) has been used historically to refer to both URIs under the
   "urn" scheme [RFC2141], which are required to remain globally unique
   and persistent even when the resource ceases to exist or becomes
   unavailable, and to any other URI with the properties of a name.

Anyone interested in URN is already told that 2141 is the place to go
to read about those, and the metadata for 2141 will clearly say that
this document obsoletes that one.

So I think we're covered just fine here.

Barry, WG chair

---

From: tom p. <[email-masked]>
Date: Tue, 21 Feb 2017 16:04:31 +0000

OK on 'Updates'

Meanwhile,
s.2.2 'the basic Latin repertoire [RFC20] '
I don't know what you mean - RFC20 does not use the term 'Latin
repertoire' and, being European, I tend to think of the Latin repertoire
as being the 160 or so characters of the Belgian language.

I think you need to specify the code points here.

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Feb 2017 12:40:48 -0500

--On Tuesday, February 21, 2017 16:04 +0000 "tom p."
<[email-masked]> wrote:

> repertoire' and, being European, I tend to think of the Latin
> repertoire as being the 160 or so characters of the Belgian
> language.

Mea cupla.  I knew that unqualified reference was going to get
us into trouble and let it go.  Whether you (and future readers
of 2141bis) should have known this (European or not) is
debatable,  but "Basic Latin" is a term of art in
internationalization work and "repertoire" keeps us away from
debates about particular coded character sets, encodings, etc.,
and, in particular, avoids confusion with %-encoded arbitrary
Unicode characters (see the introduction to Section 2) which are
certainly still ASCII characters.  The definition of "basic
Latin repertoire"  is more or less equivalent to "undecorated
Latin characters", but that terminology raises other issues...
to the point that I'm tempted to say "can't win no matter what
one does".    

Personally, I've always objected to "Basic Latin" because
several characters we consider to be part of the repertoire
today (e.g., "w" and distinct "j" and "u") were late additions
and would not have been part of the writing system as distinct
characters for writers of Latin in the time or, e.g., Virgil.
But that argument was lost long ago and "basic Latin" is the
prevailing terminology today.

> I think you need to specify the code points here.

I think that would cause confusion with syntax rules that
specify what is possible.   The paragraph in which the phrase
you picked up simply imposes a "SHOULD NOT" restriction and
explains why it should be adhered to when possible and what the
exceptions should be. It really clarifies and is perhaps
partially redundant with the previous paragraph.  How would you
feel about making the phrase something closer to "the basic
Latin repertoire, i.e., the letters and digits of ASCII as
described above" and moving the RFC 20 citation to the first use
of "ASCII" in that previous paragraph?

Other textual suggestions welcome but, again, I think listing
code points would cause confusion with the formal syntax for
<namestring> and some of the carefully-constructed language
around it.

     john

p.s. personal note: 2141bis has either the advantage of, or
suffers from, the fact that Peter and I have been immersed in
internationalization (i18n) issues for the last several years
with various involvements in PEECIS, IDNA, SMTPUTF8 ("EAI"), and
other efforts.   That has probably resulted in our trying to be
a little more precise in this draft than many IETF documents
about URI schemes and naming and perhaps, as in this case,
having slightly higher expectations about community
understanding of those issues than might be the case.  I think
that precision is an advantage and hope that community knowledge
and understanding will gradually improve.   YMMD, but I hope
than anyone who is actually inclined to advocate for less
precision (you have not) be careful about any advocacy, even on
a diversity basis, for IETF consideration of writing systems
that cannot be expressed in ASCII and/or any language other than
English.

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Tue, 21 Feb 2017 12:04:26 -0700

On 2/21/17 10:40 AM, John C Klensin wrote:

> How would you

OLD

   In order to make URNs as stable and persistent as possible when
   protocols evolve and the environment around them changes, URN
   namespaces SHOULD NOT allow characters outside the basic Latin
   repertoire [RFC20] unless the nature of the particular URN namespace
   makes such characters necessary.

NEW

   In order to make URNs as stable and persistent as possible when
   protocols evolve and the environment around them changes, URN
   namespaces SHOULD NOT allow non-ASCII characters [RFC6365] unless
   the nature of the particular URN namespace makes such characters
   necessary.

The term "non-ASCII" is defined in RFC 6365 and seems perfectly
appropriate here.

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Feb 2017 14:20:21 -0500

--On Tuesday, February 21, 2017 12:04 -0700 Peter Saint-Andre -
Filament <[email-masked]> wrote:

>> described above" and moving the RFC 20 citation to the first
>> use of "ASCII" in that previous paragraph?
> 
> OLD
> 
>    In order to make URNs as stable and persistent as possible
> when    protocols evolve and the environment around them
> changes, URN    namespaces SHOULD NOT allow characters outside
> the basic Latin    repertoire [RFC20] unless the nature of the
> particular URN namespace    makes such characters necessary.
> 
> NEW
> 
>    In order to make URNs as stable and persistent as possible
> when    protocols evolve and the environment around them
> changes, URN    namespaces SHOULD NOT allow non-ASCII
> characters [RFC6365] unless    the nature of the particular
> URN namespace makes such characters    necessary.
> 

Wfm.  Tom?

    john

---

From: tom p. <[email-masked]>
Date: Thu, 23 Feb 2017 09:39:05 +0000

----- Original Message -----
From: "John C Klensin" <[email-masked]>
Sent: Tuesday, February 21, 2017 7:20 PM
> > The term "non-ASCII" is defined in RFC 6365 and seems perfectly

OK (after some thought).

As you surmise, I am not familiar with 'basic Latin' as a term of art
and did wonder if that was intended to exclude digits (since they came
to Europe later, with the Arabs).  The NEW text clarifies that.

Tom Petch

---

From: tom p. <[email-masked]>
Date: Fri, 24 Feb 2017 12:43:26 +0000

s.5.2
" ...and that it (3) not
   cause the NID to exceed the length limitations defined for the URN
   syntax (see Section 2). "

I struggle to see anything in Section 2 that relates to a length
limitation.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;

Revised
be
(URI)
syntax,
is
obsoletes

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Fri, 24 Feb 2017 07:21:33 -0700

> I struggle to see anything in Section 2 that relates to a length

The ABNF in Section 2 has:

      NID           = (alphanum) 0*30(ldh) (alphanum)

Peter