Re: some comments about draft-ietf-idn-idna-08.txt

"Codogno Maurizio (Rozzano)" <[email protected]> wrote:

> Sect. 4.1., para 4.  I think that an explicit failure condition should
> be added at the various steps of the algorithm (3, 5, 8)

Oh dear, we lost some crucial text between drafts 7 and 8.  Draft 7
said:

    ToASCII fails if any step of it fails.  If any step fails, the
    original sequence MUST NOT be used as a label in an IDN.

In draft 8, this was changed to:

    It is important to note that the ToASCII operation can fail. If the
    ToASCII operation fails on any label in a domain name, that domain
    name MUST NOT be used as an internationalized domain name. The
    application needs to have some method of dealing with this failure.

Paul, we need to restore the original statement.  We can also retain the
new advice (the last sentence of the draft-8 version).  The result would
be:

    ToASCII fails if any step of it fails.  If any step fails, the
    original sequence MUST NOT be used as a label in an IDN.  The
    application needs to have some method of dealing with this failure.

(Another instance of the draft-8 version still appears in section 1.1,
so we don't lose anything by doing this.)

> Sect 3, req. 2). "An equivalent domain name".  It is a *unique*
> equivalent domain name, right?

Not necessarily.  Punycode and ToASCII don't say whether uppercase
or lowercase ASCII letters will be used in ACE labels.  For example,
xx--4m4a and XX--5M4A are both possible outputs of ToASCII, and both are
equally valid.  Among a number of equivalent labels, it doesn't matter
which one you use, so we don't require any particular one of them.  It's
the implementor's choice.

By the way, an editing error in this paragraph was fixed between idna-08
and idna-09.

> Sect. 6.1, para 2. I am wondering if we SHOULD present both forms, if
> the ACE label is presented.

That sounds like a good option for an application to provide, but
I don't think the IDNA spec ought to get into the details of user
interface design; I'd rather leave it up to the application developers.
We make one general recommendation regarding user interfaces: try not to
show ACE to users unless they ask for it.  I don't think it's our place
to get into the specifics of how the user asks or how the ACE is shown.

> Sect. 8. Why EDNS has not been included in the specifications?

The whole point of IDNA is that it doesn't depend on any changes to
the infrastructure, neither the DNS infrastructure nor any other
infrastructure (like mail relays and web caches).  The STD-13 DNS
service is entirely sufficient for IDNA; EDNS is not needed.

> As a side issue, I'd like to be pointed at some heuristic data about 
> Punycode.

I compared Punycode (back when it was called AMC-ACE-Z) against some
other algorithms:

http://www.cs.berkeley.edu/~amc/idn/ace-eval.gz

I didn't have a large set of test data to work with, but Punycode
appears to do well for a wide variety of inputs, including ideographic,
non-Latin alphabetic, Latin-based, and mixtures of those.  It's very
adaptive to the distribution of the input code points.

I think Soobok Lee <[email protected]> has more data (or at least, he did
at one time).

> Ok, you may say that I am dumb

Not at all!  Thank you for reviewing the drafts.

AMC