Re: [idn] Moving forward

["Adam M. Costello" <amc@cs.berkeley.edu>]

Keith Moore <moore@cs.utk.edu> wrote:

> > Programs that send domain names to receivers known to handle UTF-8
> > names may perform ACE decoding on ACEs before sending, but are not
> > required or even encouraged to do so.
>
> I'm not sure this is a good idea for all applications - in particular,
> I think it would be a bad idea for email.  Partially because email
> is more reliable if MTAs don't do unnecessary transformations on
> messages, and partially because in email there's really no way to know
> the capabilities of the "ultimate" receiver (there may in fact be
> multiple receivers).

Yes, MTAs are already recommended not to alter messages, and that would
still apply.

> It might be that more precise wording of your statement would address
> this concern, though offhand I cannot suggest text that would do so.

I guess I should say that ACE decoding is permissible only when the
sender of a protocol message knows that all recipients of that message
(both direct and indirect) can handle it.  In the case of email headers,
I don't see how the sender could know that.  But in the case of SMTP
MAIL and RCPT commands, only the next-hop MTA receives those commands,
so ACE decoding would be safe there.  Probably pointless though.

The reason I included this option in the model was to allow for the
reduction of ACE-leakage.  Example scenario:  After IDN is standardized,
a new application protocol is defined that uses nameprep'd UTF-8.  Since
this application talks only to itself, it doesn't bother implementing
ACE decoding when displaying names to the user (it is recommended, but
not required, to decode ACE); it just handles conversion of UTF-8 to the
local charset.  That works fairly well until someone writes a gateway
between this application and some other protocol.  Now it might be nice
to put ACE decoding in the gateway, since the application doesn't do it
itself.  This is safe because the gateway knows that this application
handles UTF-8.

AMC