Hello everybody,
On 07/01/2021 10:00, John C Klensin wrote:
Russ, Barry,
Another small catch...
--On Wednesday, January 6, 2021 13:41 -0800 Russ Housley via
Datatracker <noreply@xxxxxxxx> wrote:
Nits:
Section 3.2 says:
However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV
URNs do not support percent-encoding.
This does not seem like a "however" statement to me. Perhaps,
it is a "Note that" statement. Or, just drop "However".
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. I can't
speak to what the URNBIS WG would have done had it been allowed
to consider the options that might have been opened by
developing different requirements for locators and names and, in
particular, whether any such changes would have affected
percent-encoding. However, it was painfully clear that no URN,
much less any particular URN namespace definition, can alter
those rules.
John is completely correct here, many thanks for spotting this. Please
also note the sentence
"The lexical equivalence of the DEV URNs is defined as an exact and
case sensitive string match.".
Apart from the fact that this would be better written as "an exact case
sensitive string match", lexical equivalence has to take into account
percent-escaping. That means that e.g.
urn:dev:mac:0024beffff804ff1 and
urn:dev:mac:0024beffff804ff%31
are equivalent. I'm sorry I don't have the time to read the whole spec;
it would be good if some of the authors went over it again with a fine
comb after rereading RFC 3986 and understanding how percent-escaping
works. If they have questions, the URN mailing list (urn@xxxxxxxx) or
the URI mailing list (uri@xxxxxx) would be the best places to ask for
advice.
Regards, Martin.
At this point, the most obvious option would be to change the
statement in draft-ietf-core-dev-urn to note that the RFC 3986
rules apply and explain (inline or by reference) how
percent-encoding works. Such a statement might explain that,
given the characters permitted in RFC 8428 Section 4.5.1,
percent-encoding should never be necessary within a DEV URN.
However, because the list in 8428 includes characters that are
defined as "Reserved Characters" in Section 2.2 of RFC 3986,
notably including ":" and "/", the possibility of their being
percent-encoded by some process allowed by 3986 cannot be
eliminated.
Other alternatives involve updating RFC 8141 and 3986, but I
wouldn't recommend going there, especially if the CORE WG would
like to see the current spec published in 2021. The narrowest
of those updates would be to change the rather relaxed-sounding
language of RFC 3986 Section 2.1:
"used to represent a data octet in a component when that
octet's corresponding character is outside the allowed
set or is being used as a delimiter of, or within, the
component."
To say that percent-encoding MUST NOT be used unless actually
required, but I'd guess that would not go over well with
existing implementations.
Or, I suppose, the IESG could decide either that 3986 does not
count or that an interpretation that disallowed URN namespaces
prohibiting things that it allows is incorrect. But someone
would probably take that as a commitment to allow a revision to
8141 that would codify the options that would imply.
john
p.s. This not being spotted earlier may be a contribution to the
discussion that is now occurring on the IETF list of early
cross-area review and how important it is to facilitate, rather
than discourage, such reviews. Or not.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
