Comments on draft-hoffman-imaa-03

[Marcos Sanz/Denic]

Paul,
all,

a few comments on the document follow:

Section 2: "To allow [...], IDNA uses an 'ACE local part'". You mean "IMAA
uses", don't you?
Section 2: "ACE infix". Maybe adding a few words there on its role in
IMAA?
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. Relevant is that
my system correctly interprets the character encoding when reading from an
input stream (socket, file).
Section 4.1, step 5.d: Could we add some wording on the magic of 59? At
the first reading, I didn't know what was the point of this test.

Best regards,
Marcos Sanz

[Adam M. Costello]

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