Visually confusable characters

[J-F C. Morfin]

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!

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

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