Re: [idn] new I-D: Safely Encoding of likeness information into ACE label version 0.2

[Eric Brunner-Williams in Portland Maine]

I agree with the co-chair's conclusion that the subject matter itself is
outside of the scope of the working group.

Fundamentally, the issue that is the subject of "look-alike" discussion is
elements of an abstract character repertoire within a coded character set,
which have a property of visual similarity. From a broad scripts frame of
reference, e.g., "Han Unification", to a macro-scale "things that look like
circles", to the micro-scale of individual characters, this is the work of
bodies which create abstract character repertoires and coded character sets.

It would hardly matter if such a draft was "in the pool" or not.

I don't agree with the suggestion made by the co-chair that perhaps there
is a security concern for "look-alike" characters.

In the requirements draft, section 3 (Security Considerations) there is the 
hopeful statement that "a solution" not be "less secure" than the current
DNS. Skipping over the minor problem that this may be an underspecification,
hostname-based authentication is historic (and inachievable, hence dnssec),
and invocation of identd is ... unusual in the normal course of app/resolver
/transport/nameserver/transport/app sequences.

The existance of "misleading identifiers" formed with an extended repetoire
(independent of whether elements of the extended repetoire are transported
in encapsulated, or native forms) appears to require that two or more "near"
(Hamming distence) identifiers exist.

A protocol that is capable of signaling the existence of name proximality
is something other than the DNS. That protocol, whatever it is, can have a
"Security Considerations" section that treats the subject of minimal Hamming
distance (or any other form of similarity metric), hence some property that
relates to authentication et al, and "misleading identifiers", hence of
"look-alike" characters.

So, after all this (which I'm sorry to say took me much longer to write than
for many to read), I think "safely encoding" is not "safe", and we should
not do "encoding".

Eric