[UA-EAI] UASG014 - Quick Guide to EAI

[Mark Svancarek]

I think we need a section regarding how to display names on From/To/CC/BCC lines when they are received in unexpected formats.



  *   Example 1:
     *   Suppose a system replaces an address with a punycode equivalent or MIME equivalent.
        *   (They shouldn't do that, but we are robust and can accept it.... it's just ascii, after all.)
        *   If the message includes a friendly-from string, we can display as
           *   Friendly Name <randomasciicrap at moreasciicrap>
        *   … or, as just
           *   Friendly Name
        *   … or something else.
        *   The former seems better to me.  What is the UASG preferred practice?
  *   Example 2:
     *   When UTF8 is received on a non-EAI-compatible client or via a non-EAI-compatible service on the CC line, it will usually show the right characters (fonts are often managed by the OS, not the app), but Reply and Reply All will fail.
        *   I think John mentioned that ":;" is used in this case, sorry if I captured that wrong.
        *   Is this the best way to convey to the user that Reply is unavailable?



-----Original Message-----
From: UA-EAI [mailto:ua-eai-bounces at icann.org] On Behalf Of John R. Levine
Sent: Sunday, January 14, 2018 9:39 PM
To: Don Hollander <don.hollander at icann.org>
Cc: ua-eai at icann.org
Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI



On Sat, 13 Jan 2018, Don Hollander wrote:



> 2) I’ve added a section identifying which fields need to be considered

>    when doing EAI retrofitting.  Can someone provide such a list?  Are

>    there also tasks/functions that we need to apply?



For sending, all you have to do is to handle UTF-8 text in addresses in From:, To:, Cc:, Sender:, Reply-To:, and Resent-*:.  But RFC 6532 also says that you can use UTF-8 nearly everywhere that used to require ASCII, so the display names, Subject: line, and message body can also be UTF-8, so you better be prepared to handle that on incoming mail even if you don't send it.  Also, when doing attachments, if your mail program can attach one message to another, e.g., forward as an attachment, it needs to check if the message being forwarded is EAI and if so attach is as message/global rather than message/rfc822.



It's probably also worth mentioning a few things not to change.  Don't change the Date: header, since it's in a rigid format intended to be parsed and redisplayed by MUAs.  (Mine displays dates in the local timezone, adjusting appropriately.)  Don't change Message-IDs, they're for computers, not people.



> 3) Should we identify UASG Good Practices where they are not addressed

>    one way or another within the RFCs?  Eg Aliasing vs ‘downgrading’ on

>    the fly.



Aliasing is the only thing that comes to mind.



Regards,

John Levine, johnl at iecc.com<mailto:johnl at iecc.com>, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=02%7C01%7Cmarksv%40microsoft.com%7C936e38e36e874481fadd08d55bda61bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636515915867149370&sdata=scv26qwi2VaZBitByBFyU%2FrOTaIGvdWosG5uo0%2BzbyI%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/mailman/private/ua-eai/attachments/20180116/ccbc1376/attachment.html>