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
