Re: Comments on draft-hoffman-imaa-03

Marcos Sanz/Denic <[email protected]> wrote:

> Section 2: "To allow [...], IDNA uses an 'ACE local part'".  You mean
> "IMAA uses", don't you?

Yes, thanks.

> Section 2: "ACE infix". Maybe adding a few words there on its role in
> IMAA?

Hmmm, it has a three roles:  (1) To reduce the probability of collisions
between ACE local parts and existing ASCII local parts; (2) to make it
easy for humans to verify that a local part cannot be an ACE because
it lacks the infix; (3) to mark the boundary between the literal and
non-literal portion of a Punycode encoding.  Would people like to have
this explanation added to the terminology section?  Or somewhere else?
If so, we should consider a similar change in the IDNA RFC (where the
first two roles would apply, but not the third).

> Section 4: "If a local part is represented using a character set
> other than Unicode or US-ASCII, it will first need to be transcoded
> to Unicode.".  I don't understand this requirement on the character
> set used to the input and I think it is not relevant here.  Nevermind
> if I use UTF-8, or UTF-16 or Latin-1.  If my local encoding is, for
> instance, Latin-9 and I have an implementation of ToASCII running
> in my system that deals with my local encoding, the operation will
> succeed.

You speak of an implementation of ToASCII that deals with the local
encoding.  The only way to deal with the local encoding is to transcode
it to Unicode before starting the actual ToASCII steps specified in
section 4.1.  That is the point of the sentence you quoted above.  An
implementation might bundle the transcoding and ToASCII into a single
localToASCII operation, and it might even slightly abuse the terminology
by calling the bundled operation "ToASCII", but formally ToASCII is
defined as an operation that takes Unicode code points as input.  (It
has to; look at Nameprep.)

> Section 4.1, step 5.d: Could we add some wording on the magic of 59?

Sounds good to me.

AMC