Re: [idn] IDNs in email message bodies

["Eric A. Hall" <ehall@ehsco.com>]

> >>  If the person doing the copy/paste was using an IDN-aware MUA with
> >>  support for Arabic, then the From: field was showing Arabic text,
> >>  and that is what got copied and pasted, not ACE, so there will be
> >>  no irritation.
> >
> >If the recipient system is not IDN aware, it would break, defeating
> >the purpose of IDNA.  And even if it is IDN aware, it might not
> >support the character set being used to represent the IDN email
> >address.
> 
> Not if the clipboard contain the ACE encoding regardless of whether
> the "sending" application can handle ACE or not.

The clipboard is not likely to be stuffed with ACE strings. The most
likely event is that the charset-specific encoding will be converted to a
system-specific form.

EG, a mail client that supports ISO-2022-JP text (and therefore which also
supports URLs and email addresses written in ISO-2022-JP as the users are
most likely to do) will just copy the text string to the clipboard as UTF8
or UCS-2 or some other system-specific encoding. It is highly unlikely
that an application is going to convert the data to ACE based on the
possibility that the selected text may contain an ACE encoded string.

> I.e. the application which put things in the clipboard buffer should
> do it in the ace encoding -- and this is why ace->local script is
> only a display issue.

I don't think that's a valid assumption, for several reasons.

What if the selected data contains blocks of text with an IDNs spread
across the text, is the application supposed to convert the IDNs to ACE
while leaving everything else alone?

Is an application supposed to convert IDNs in attachments? Maybe not
convert IDNs in Excel spreadsheet attachments but what about vCard?

It is well beyond any protocols scope to demand this conversion.

Applications will convert to system-specific formats and then convert to
ACE again when the IDNs need to be resolved

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/