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 <john-ietf(_at_)jck(_dot_)com>
wrote:
-On Tuesday, February 21, 2017 12:25 +0000 "tom p."
<daedulus(_at_)btconnect(_dot_)com> 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