Visually confusable characters

J-F C. Morfin jfc at
Sat Aug 9 17:44:48 CEST 2014

At 15:52 09/08/2014, Andrew Sullivan wrote:
>On Fri, Aug 08, 2014 at 07:20:49PM -0700, Asmus Freytag wrote:
> > If there was an "additional protocol" where problematic cases could
> > be identified and translated into a binding requirement on LGRs (and
> > therefore registration policies) to either disallow all but one of
> > the alternatives, or to have a robust way of mutually excluding
> > labels from registration (using the blocked variant mechanism) then
> > it would seem that you get the effect of robust lookup, without
> > having to arbitrarily play linguistic favorites.
>That isn't an additional protocol at all.  That's a modification to
>IDNA2008.  IDNA2008 already has rules both about registration and
>about lookup.  If you're going to add another level of registration
>rules, then obviously that'd have to update IDNA2008 and thereby
>create IDNA201n.  Or, much worse, IDNA202n!

This is why I suggest an "IETF Unicode" protocol, i.e. an Unicode 
protocol for or by the IETF to be used by an unchanged IDNA2008. I 
clarify with a rough example:

- in an IDNA/Unicode "^" becomes the only way to transcode 
"" with no ambiguity, since "" will be regularly 
handled by IDNA as "".
- then there is no problem in advertizing and using the domain name 
as "^".
- People may subscribe "" and be allocated "^" as 
well during an initial period.
- people supporting "IETF/Unicode" may just enter "".

This can be made transparent to the user at the RFC 5895 level: it is 
a Layer 6 formating matter.

More information about the Idna-update mailing list