Re: [idn] Moving forward

[Keith Moore <moore@cs.utk.edu>]

> 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.

probably so, since users don't see this most of the time.  

also there is the potential for utf-8 IDNs to leak out in delivery status
notifications (DSNs) which expect addresses in ASCII.

> The reason I included this option in the model was to allow for the
> reduction of ACE-leakage.  

sure.  but utf-8 leakage is also a concern.  one guy's improvement
is another guy's 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.

this would be fine.  but we usually don't specify the behavior of gateways.
there are too many details to track down for marginal cases.

Keith