Hi, That is a reasonable thing to ask for, and I will supply edits below. They might sound like me rather than the authors, so I wouldn't mind if they write something substantially similar in their own voice.
I also understand the point of view that says "Really all this draft says is 'compare A labels.'" But this is incompatible with strenuous objections to changes to IDNA text in the document, so I don't understand this behavior. When I read the document, I thought "that's not how it really works, and I sure wish I didn't have to read the WHATWG document to get the truth, because it's really long". In fact, this very mailing list even runs on UTS-46. See https://mailarchive.ietf.org/arch/msg/uta/KbtvWrG5vdW6iq0scwWpBc1xeM8/ In Section 2, the current text is incorrect, because UTS-46 domains sometimes don't conform to these validity checks. So, the document is inconsistent in making this claim. Citing UTS-46 here would be correct, since that would also cover IDNA2008, but it doesn't seem like that will fly. Current: --- An "internationalized domain name", i.e., a DNS domain name that includes at least one label containing appropriately encoded Unicode code points outside the traditional US-ASCII range and conforming to the processing and validity checks specified for "IDNA2008" in [IDNA-DEFS] and the associated documents. In particular, it contains at least one U-label or A-label, but otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels. New: --- An "internationalized domain name", i.e., a DNS domain name that includes at least one label containing appropriately encoded Unicode code points outside the traditional US-ASCII range. In particular, it contains at least one U-label or A-label, but otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels. Refer to [[Section 7.3]] for further details. --- Then, in section 7.3: Current: --- As with URIs and URLs, there are in practice at least two primary approaches to internationalized domain names: "IDNA2008" (see [IDNA-DEFS] and the associated documents) and an alternative approach specified by the Unicode Consortium in [UTS-46]. (At this point the transition from the older "IDNA2003" technology is mostly complete.) Differences in specification, interpretation, and deployment of these technologies can be relevant to Internet services that are secured through certificates (e.g., some top-level domains might allow registration of names containing Unicode code points that typically are discouraged, either formally or otherwise). Although there is little that can be done by certificate matching software itself to mitigate these differences (aside from matching exclusively on A-labels), the reader needs to be aware that the handling of internationalized domain names is inherently complex and can lead to significant security vulnerabilities if not properly implemented. New: The IETF document covering internationalized domain names is "IDNA2008" [IDNA-DEFS]. The Unicode Consortium publishes a similar document known as "UTF-46". This document allows names that are valid in IDNA2003 but not IDNA2008, and additionally allows characters that are not valid in either IETF document, such as emoji characters. This more lenient approach carries additional risk of semantic ambiguity and additional security considerations. ICANN recommends IDNA2008 [ https://features.icann.org/ssac-advisory-use-emoji-domain-names] and against emoji characters in domain names. However, the internet contains old content published under IDNA2003, and people enjoy emoji characters, so consumer applications often end up using the more liberal approach in [UTS-46]. --- That's it, and I must say I'm a bit dismayed that argument has continually drifted to the /people/ rather than the content of the document. thanks, Rob On Mon, Jan 30, 2023 at 6:07 AM Valery Smyslov <smyslov.i...@gmail.com> wrote: > Hi, > > thanks to all for very interesting discussion (and thanks > to John and Patrik for the explanation of the history of the problem). > > Before issuing a consensus call, the first question is to Rob: > can you propose concrete text changes that you want to see in the draft? > > Regards, > Valery (for the chairs). > > > On 1/29/23 1:14 PM, Salz, Rich wrote: > > > > > >> It seems to me that It remains the case that this I-D is not the best > > >> forum to litigate which U-labels are valid candidates for turning into > > >> A-labels. Surely that belongs elsewhere. > > > > > > I agree that this kind of thing belongs in the DNS groups. > > > > > >> However it is that > > > applications (or their libraries) turn U-labels into A-labels, this I-D > > > describes how to match them against presented identifiers in > > > certificates. > > > > > > *EXACTLY* > > > > > > Really all this draft says is "compare A labels." > > > > > > What else do we need to say? In my view nothing. > > > > Completely agree. > > > > And that's what draft-ietf-uta-rfc6125bis (even RFC 6125 before it) has > > always done, with version -10 now including additional security > > considerations and pointers to relevant specifications. > > > > Chairs, can you please initiate a consensus call on whether or not we > > need to make changes to draft-ietf-uta-rfc6125bis on this topic? As far > > as I can see, we have one person loudly in the rough, but a consensus > > call would enable us to determine whether there is broader support for > > modifications to the draft (which, I would like to point out, has > > already completed two working group last calls). > > > > Peter > > > > _______________________________________________ > > Uta mailing list > > Uta@ietf.org > > https://www.ietf.org/mailman/listinfo/uta > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
