Proposed Charter for the IDNAbis Working Group

[John C Klensin]

--On Wednesday, 26 March, 2008 11:33 +0000 Gervase Markham
<gerv at mozilla.org> wrote:

>...
> However, my understanding and hope is that IDNAbis will
> disallow, in some way, a large number of characters which are
> not used in the languages of the world but are permitted by
> the current "include unless we thought of a reason to exclude"
> approach. What would be the rationale for doing so if not as
> one of the many actions to be taken to mitigate phishing?
>...

Gerv,

I agree with Vint's comments, but let me add an additional
remark.  One of the key elements of the current drafts is that
it takes the approach of "generalize from LDH" rather than the
approach that you describe as  "include unless we thought of a
reason to exclude".  The "recharter" provisions imply that, if
we reject that principle,  we are going to need to start over.

That "generalize from LDH" principle should be a big help with
regard to phishing because it reduces the number of characters
that are relevant.  If used in combination with "don't even look
up the disallowed stuff", you don't need to have discussions
about box-drawing characters -- they are disallowed and you just
tell the registries that you are following the protocol and not
look them up.  But, interestingly, the decisions that led to
those principles were made for reasons independent of phishing
considerations.  Both are driven by broader principles of
protocol design as well as operational experience with the
traditional DNS.   

While we clearly have work to do to get the recommendations
exactly right, you can probably make even more gains against
phishing by clever use of the "no mapping" principle.  But that
is another principle whose origins do not lie in anti-phishing
considerations (although the more general "minimization of
confusion" considerations do apply).

Where we cannot help at the protocol level (with or without a
ban on decisions driven by phishing considerations) is the
situation in which a non-compatibility, legitimate, language
character in one script looks a little too much like a
non-compatibility, legitimate, language character in another
script.    That has got to be a registry issue because there is
no way that we can make a protocol choice that favors one of
those characters over the other and, incidentally, because
"looks ... too much like" is ultimately fairly subjective.

best,
   john