That looks good to me. Russ > On Jan 12, 2021, at 5:21 PM, 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. > > 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]. > > 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.diff.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. > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
