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

[tom p. <[e-mail]>]

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" <[e-mail]>
Sent: Tuesday, February 21, 2017 3:12 PM


> -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
>