Visually confusable characters (3)

[Andrew Sullivan]

Hi,

[I trimmed the destination to just the list.]

On Sun, Aug 10, 2014 at 12:15:01PM -0700, Asmus Freytag wrote:

> The sense I employ is best understood as the combination of the concept
> of "idn table" plus certain validation / disposition evaluations that can be
> automated based on a suitable machine-readable expression of the relevant
> policy aspects.
> 
> The sense in which I use the term can be seen as, more or less, equivalent
> to something that can be expressed in the proposed XML format.
> That format is purposefully *not* restricted in the same way as the
> *Root Zone* LGR project, but instead designed to express all registered
> idn table formats (including those policy aspects that translate directly
> into a machine-readable format).

Despite my desire that we define LGRs in the way you're describing,
I've never been very sanguine about the overall utility in what are
often called "leaf zones".  The evidence suggests that that's where
most of the phishing happens, however, and it's not clear therefore
how this approach will actually help.

> evaluation of this, but it strikes me that the level of expertise
> collected there exceeds, what concerns the Arabic script, the
> collective expertise in that subject, that was brought to bear on
> IDNA itself.

Why is that important?  When IDNA2008 was being prepared, we quite
explicitly went out of our way _not_ to pay attention to the details
of a script, on two grounds: that zone administrators should create
these policies (which is what the LGR procedure ICANN is engaged in
now does), and that Unicode's normalization rules (and particularly,
the requirements about stability of the results) would allow us to act
that way.  Indeed, the current discussion suggests that the _second_
of those premises might have been flawed.

> IDNA2008 contains mechanisms to restrict the repertoire 

I wouldn't state it that way.  IDNA2008 starts from a repertoire of
_nothing_, and only permits things as they are shown to be safe.  This
is exactly the way in which it differs from IDNA2003.  If you start
with the assumption that there is this repertoire, and then IDNA2008
whittles it down, you have it backwards.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com