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

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

-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