-On Tuesday, February 21, 2017 12:25 +0000 "tom p." <daedulus@xxxxxxxxxxxxx> 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