Jari, I think that your proposed text is ok. Some more detailed comments inline below, probably more for information than a suggestion for further changes but others may disagree... --On Wednesday, January 13, 2021 00:21 +0200 Jari Arkko <jari.arkko@xxxxxxxxx> wrote: > Hi John, nice to hear from you. Inline: > >> Sorry I, or someone in the URN registration review process, >> didn't catch this, but I think it is a little more complicated >> than a nit. When what became RFC 8141 was being developed, >> several people made very clear to the WG that there was no >> possible way for a URN specification to make an exception to >> the syntax rules for URIs, including the rules about >> percent-encoding in Sections 2.1 and 2.4 of RFC 3986. > > Thanks for bringing this point up. > > I'm not entirely sure that if we dug deeper, what the actual > precedence rules between requirements from different RFCs > would be*. Be that as it may, I'm not sure we need to have > that debate. In general, I would agree that precedence rules are often debatable. However, 3986 asserts that URNs are a type of URIs, something the URN WG did not seriously consider trying to change (and, I'm convinced, would not have been allowed to change had it wanted to). And draft-ietf-core-dev-urn asserted that these are, after all, URNs. Now suppose that, instead, the document had been titled "FiddleFrobs for Device Identifiers". Then I think the WG could have had (and probably would have been forced into) an absolutely fascinating discussion as to whether FiddleFrobs where really URIs in disguise and hence should be bound by 3986 and, if so and they were name-type URIs, whether they were URNs or some other name-type creature [1]. Personally, the only thing I've confident about in terms of such a discussion is that I would want to be as far away from it as possible. > How would people feel about the following text which I think > describes the correct situation with respect to the percent > encoding in DEV URNs, and does not claim to change any rules > on 8141: > > … Due to the SenML RFC 8428 > Section 4.5.1 rules, it is not desirable to use > percent-encoding in DEV URNs, and the subtypes defined in > this specification do not really benefit from > percent-encoding. However, this specification does not > deviate from the general syntax of URNs or their processing > and normalization rules as specified in [RFC8141]. As I said above, I think it works. However, since the rules that set this discussion off are actually in 3986, I'd be slightly more comfortable, and I think it would serve your readers better in the long run, if you referenced 3986 as well as 8141. I don't think there is any point in going further than that, e.g., by identifying the sections involved. > This text is in my soon-to-be-submitted version -10, available > here: > > https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.d > iff.html > > Jari > > *) One could for instance also argue that all URN subtype > specifications are narrowing down of the general syntax, > although one might equally well point out that there are some > real-life limitations of e.g. software processing that occurs > before handing a URN to a particular module, which might > dictate that some general URN processing rules are adhered to. > Or there's some other reason that prevents the particular > narrowing down that's in -09. But that is similar or identical to the arguments the URNBIS WG tried to make vis-a-vis 3986, i.e., that we could take what 3986 allowed and further restrict the syntax and/or provide more specific interpretations of semantics. As I suggested, and Martin Dürst affirmed, that didn't get us very far. I strongly suggest that you take your proposed paragraph above (preferably with the additional reference), run with it, and put this little blip behind you and behind the WG :-) best, john [1] See Section 1.1.3 of RFC 3986. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
