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

[Barry Leiba <[e-mail]>]

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

On Tue, Feb 21, 2017 at 10:12 AM, John C Klensin <[e-mail]> wrote:
> -On Tuesday, February 21, 2017 12:25 +0000 "tom p."
> <[e-mail]> 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
>