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 ----- Original Message ----- From: "John C Klensin" <john-ietf@xxxxxxx> Sent: Tuesday, February 21, 2017 3:12 PM > -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 >