Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09

["Martin J. Dürst" <[e-mail]>]

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 <[e-mail]> 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 ([e-mail]) or 
the URI mailing list ([e-mail]) 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.
>