I was pointed at this document. First a few observations: 1. There are functional domains that include names that this would not allow, but that exist nonetheless. https://xn--ls8h.la/ works pretty well in most browsers. Some even show something other than punycode. Is the intent to break those sites? Have the authors performed any analysis showing the extent to which this is a problem? 2. Levying restrictions on registrars falls for the "low hanging fruit" fallacy. Even if it were possible for a registrar to block registration of dodgy names, once I have control of the authoritative for a zone, you aren't stopping me from mounting all sorts of homoglyph attack. 3. I found this document incredibly hard to process. Critically, there are a bunch of things that it appears to be setting out as constraints, but I have no idea how they might be implemented. Others noted the invocation of magic implied by some of the requirements, so I won't detail much more, other than to point out this text: Many registries have decided to restrict each label to a single script, even if the registry permits different labels to use different scripts. The Unicode script property is defined in UAX24 [UAX24], and the relevant data tables are published in a supplemental document [UAX24-scripts-text]. However, while suitable for many purposes, experts on particular languages or usages sometimes define scripts and their contents differently and there are no requirements that registries use the Unicode definitions. That sounds like a great big ¯\_(ツ)_/¯ to me. It is almost like a transport protocol were to say "you might consider retransmitting some of the packets you send; consult experts, who might disagree". The rest of Section 3 is at a similar level. Hardly the stuff of a Proposed Standard. 4. I agree with Stephane about Section 4 casting shade unnecessarily. Mostly, though, I just don't see the relevance of this text. In a Proposed Standard. 5. The document is not at all clear about its purpose or how it attempts to achieve that outcome. I feel OK saying that the introduction is quite obtuse. The clearest part of the document is the part where it says that the problem it seeks to address IS NOT SOMETHING THAT CAN BE CODIFIED (that's me paraphrasing). But nonetheless, the header says "Standards Track". 6. My understanding is that most software that deals with domain names -- and their presentation to people -- has long ago decided that cutting the problem off at the stem is pointless (see also point 2 above) That still means showing punycode where we might otherwise prefer not to, but it definitely does not involve relying on registrars to perform heroics (see also point 3 above). 7. This document is not available in HTML, which means that no XML was supplied. Given all of that, I would ask that we, as a community, ask whether it is the best use of registrars resources, in discharging their "duty to serve the community" [RFC1591], to deal with this problem. Yes, that calls into question established IETF consensus around RFCs 5890 and 5891... I'm aware of the long-running effort to update the Unicode version in IDNA. It's taken a while. Why that effort has been hard all stems from the assumption that these rules around name construction were essential or they served a purpose. I can only conclude that they are not, do not, and -- if this document does anything -- it is to make a strong case that they will never. Maybe the right answer here is to drop them entirely, because the current approach sure ain't workin' and this document only sharpens the focus on that point. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
