--On Wednesday, 23 February, 2005 07:28 +0000 "Adam M. Costello" <idn.amc+0@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Erik van der Poel <erik@xxxxxxxxxxxxxx> wrote: > >> Another argument against banning the slash homograph is that >> any new banning would require a new ACE prefix, which is a >> lot of work, and, as John said, there should be a high >> threshold for any demonstration that tries to show that a new >> prefix is necessary. > > An alternative, rather than banning the character, is to > recommend that it not be shown; the ACE form could be shown > instead. This would effectively make the character useless in > domain names (for both phishers and honest folks) without > requiring a new ACE prefix. > > We could push ToUnicode down inside a wrapper function, > ToDisplay. Applications would never call ToUnicode directly > anymore. Whenever they wanted to display a domain name, > they'd call ToDisplay, which would call ToUnicode, check the > result, and if it didn't like it, call ToASCII. (Of course, > since ToUnicode typically calls ToASCII, there are > opportunities to optimize that logic.)
Adam, there are two problems with this. First, it effectively dictates UI behavior, which is generally a bad idea. It is a particularly bad idea in this case because you are proposing the sort of UI behavior that generates a lot of very confused questions and trouble reports, which is something no sane implementer wants. And "won't display" is not the right answer on the registration side of the process, even if it were right on the lookup side. The second problem is that it is a kludge, and that inserting kludges into critical protocols or procedures --and IDNs are certainly critical-- almost always turns out to be a seriously bad idea sooner or later.
If we find a need to start banning characters that we could not agree on banning the first time around, there is another approach, also unpleasant but IMO less problematic, that could be considered. Just as RFC 2822 moved past a lot of legacy nonsense by having two separate "create" and "accept" syntaxes, we could define an additional profile, say "NameRegisterPrep". It would look a lot like Nameprep but would ban the characters you are now suggesting banning, plus, based on what I think is growing experience in the registries, ban any character that mapped to anything else. The effect would be to permit only those code points as input to the registration process that could be output into punycode and the DNS. Several registries have adopted the latter part of that model already: basically what you register is ToASCII(string) and/or ToUnicode(ToASCII(string)), but never "string". The lookup process would remain the same, with no changes to Nameprep being made at all. And, by eliminating all of the mapping tables and replacing them with prohibitions, it would make the question "can this character appear in an IDN" a great deal less complicated, which would certainly be an advantage.
This type of registration restriction is rather different from our asking/expecting ICANN and the registries to adopt rules about, e.g., mixed-script registrations that would help people stay out of trouble. For better or worse, ICANN has a great deal less trouble asking (or demanding) that people conform to the protocols than it does with making up a somewhat fuzzy guideline and enforcing it. In the most extreme of cases, violating a protocol in a significant way is one of those "not acting in the best interests of the local users and the Internet community" that RFC 1591 warns against and indicates could be grounds for redelegating a registry.
It would leave the registries and ICANN stuck with the problem of what to do about anything that was now registered which violated the new rules, but that problem would exist for _any_ substantive change we made.
john