Hi Rob, * "This document and the web platform at large use Unicode IDNA Compatibility Processing and not IDNA2008. For instance, ☕.example becomes xn--53h.example and not failure. [UTS46] [RFC5890]"
Thanks for the pointer to this text. It is a very interesting statement, mainly because the illustrative example does not align with the first sentence. The A-label “xn--53h” contains a single code point “Hot Beverage” U+2615. This code point was first assigned in Unicode 4.0, so it is not part of the IDNA 2003 character repertoire. Additionally, this code point is listed as DISALLOWED for IDNA 2008, so it is not appropriate for both transitional and non-transitional UTS-46 processing. Given this, I’m unsure what it is trying to convey. Thanks, Corey From: Rob Sayre <say...@gmail.com> Sent: Thursday, January 26, 2023 7:58 PM To: Corey Bonnell <corey.bonn...@digicert.com> Cc: Peter Saint-Andre <stpe...@stpeter.im>; uta@ietf.org Subject: Re: [Uta] Browser behavior in draft-ietf-uta-rfc6125bis Hi, I'll firstly treat this message as a signal of rough consensus, since I totally agree with what you phrased as "operational reality". But, I must note that the WHATWG document you linked* has a green callout that says: "This document and the web platform at large use Unicode IDNA Compatibility Processing and not IDNA2008. For instance, ☕.example becomes xn--53h.example and not failure. [UTS46] [RFC5890]" thanks, Rob * https://url.spec.whatwg.org/#idna On Thu, Jan 26, 2023 at 2:20 PM Corey Bonnell <corey.bonn...@digicert.com <mailto:corey.bonn...@digicert.com> > wrote: Hi Rob, I regret that I used “TR-46” as shorthand for “TR-46 with transitional processing enabled” instead of spelling that out explicitly. My understanding is that all of Chrome, Safari, and Firefox implement TR-46, but Chrome deviates from WHATWG guidance by enabling Transitional_Processing [1]. TR-46 with Transitional_Processing disabled is conformant with IDNA 2008 [2]. I agree with you that the draft text currently does not match this operational reality. Thanks, Corey [1] https://url.spec.whatwg.org/#idna [2] http://www.unicode.org/reports/tr46/#Mapping From: Rob Sayre <say...@gmail.com <mailto:say...@gmail.com> > Sent: Thursday, January 26, 2023 4:59 PM To: Peter Saint-Andre <stpe...@stpeter.im <mailto:stpe...@stpeter.im> > Cc: Corey Bonnell <corey.bonn...@digicert.com <mailto:corey.bonn...@digicert.com> >; uta@ietf.org <mailto:uta@ietf.org> Subject: Re: [Uta] Browser behavior in draft-ietf-uta-rfc6125bis On Thu, Jan 26, 2023 at 1:39 PM Peter Saint-Andre <stpe...@stpeter.im <mailto:stpe...@stpeter.im> > wrote: On 1/26/23 2:28 PM, Rob Sayre wrote: > Since you phrased your message as a question, I will answer. I don't know. > > But what the draft says also does not align with your last check. How so? The draft currently makes no claims about what is implemented in browsers, only notes that there can be differences between IDNA2008 and UTS-46. I don't think that is quite right. The draft says "it is not expected that differences between the URI and URL specifications would manifest themselves in certificate matching." but the WHATWG relies on UTS-46, not IDNA2008 [0]. If all browsers don't follow this now, they soon will. Besides, these networking stacks are used by tons of other applications. See [1]. The draft doesn't exactly say anything wrong, but you really have to do what Chrome does to interoperate, and it hand waves about that. thanks, Rob [0] https://github.com/whatwg/url/commit/50f0b090cd89c27327402b2c51b40b260caea70d [1] https://developer.android.com/codelabs/cronet#0
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
