<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">When I read the Quick Guide to EAI a few days ago I was somewhat surprised to see punycode/A-Label used with respect to the local-part/mailbox name. Joseph's email has prompted me to respond.</div>
<div class=""><br class="">
</div>
<div class="">There are many issues to having the local-part as punycode but in this email I will focus on a practical working practice that encompasses both the (huge) transition problem and the long term. I think a Best (Compromise) Practice could be:-</div>
<div class=""><br class="">
</div>
<div class="">Registration of an internationalised email address would involve registration of both a primary unicode local-part and a secondary ASCII local-part. The ASCII local-part does not need to be a conversion from Unicode to ASCII. Choice of both the
Unicode and the ASCII being the choice of the registrant. Both the Unicode and the ASCII would name the same mailbox.</div>
<div class=""><br class="">
</div>
<div class="">So, for example, I could register</div>
<div class=""><br class="">
</div>
<div class="">小山@秋月茶.在线</div>
<div class="">andre@秋月茶.在线</div>
<div class=""><br class="">
</div>
<div class="">where 小山 is my primary local-part and andre is my secondary local-part.</div>
<div class=""><br class="">
</div>
<div class="">Local-part aliasing already exists on some mail servers. Using the above working practice would enforce an EAI aliasing at the registration stage.</div>
<div class=""><br class="">
</div>
<div class="">Using such a methodology would not restrict the Unicode (mostly) that could be used for the local-part. So, for example, 🐓@秋月茶.在线 would be a valid email address</div>
<div class=""><br class="">
</div>
<div class="">I think this working practice could be applied retrospectively. All the mail servers with ASCII only local-parts could allow users to create Unicode local-part aliases thus resulting in both a Unicode local-part and an ASCII local-part. This would
be offered to users after the mail server software has been updated to support EAI</div>
<div class=""><br class="">
</div>
<div class="">André Schappo</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 13 Feb 2017, at 21:41, Joseph Yee <<a href="mailto:jyee@afilias.info" class="">jyee@afilias.info</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">Forwarded this to UA-discuss list for broader feedback on the EAI Quick Guide.<br class="">
<br class="">
</div>
Best,<br class="">
</div>
Joseph<br class="">
<br class="">
<div class="">
<div class="">
<div class="">
<div class=""><br class="">
<div class="gmail_quote">---------- Forwarded message ----------<br class="">
From: <b class="gmail_sendername">Joseph Yee</b> <span dir="ltr" class=""><<a href="mailto:jyee@afilias.info" class="">jyee@afilias.info</a>></span><br class="">
Date: Thu, Jan 26, 2017 at 5:14 PM<br class="">
Subject: Re: [UA-EAI] Revised UASG013 - Quick Guide to EAI<br class="">
To: Don Hollander <<a href="mailto:don.hollander@icann.org" class="">don.hollander@icann.org</a>><br class="">
Cc: "<a href="mailto:ua-eai@icann.org" class="">ua-eai@icann.org</a>" <<a href="mailto:ua-eai@icann.org" class="">ua-eai@icann.org</a>>, Mark Svancarek via UA-Coordination <<a href="mailto:ua-coordination@icann.org" class="">ua-coordination@icann.org</a>><br class="">
<br class="">
<br class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">Hi UA-EAI team,<br class="">
<br class="">
</div>
Few comments and questions regarding the quick guide for discussion:<br class="">
<br class="">
(1)<br class="">
Client Software (MUA – Mail User Agent)<br class="">
- Should pass the domain name to the MTA (Mail Transport Agent) in A-Label format (RFC5890)<br class="">
<br class="">
</div>
The idea of EAI is to allow native Unicode in UTF8 in all mail exchange, is there any rationale for this recommendation?<br class="">
</div>
This also makes mailbox management more unnecessary complicated when the next recommendation is 'Should store and display the Mailbox in Unicode'.
<br class="">
<div class=""><br class="">
(2)<br class="">
Consider offering mailbox names which conform to the domain name label generation rules for the selected script.<br class="">
- Such names are guaranteed to be compatible with the Punycode algorithm.<br class="">
<br class="">
</div>
<div class="">Punycode is one of many encoding solution, and it (assuming we are talking about punycode under IDNA2008) has drawback. This limits the characters allowed in mailbox name. While some may found it okay, it should be pointed out.<br class="">
</div>
<div class=""><br class="">
<br class="">
(3)<br class="">
Consider offering mailbox names which conform to the domain name label generation rules for the selected script.<br class="">
- These email addresses can easily be shared by users with their friends and colleagues who do not use their same writing method; the colleague or friend can address email to such an address, or create an address book entry, using the A-label format.<br class="">
<br class="">
</div>
<div class="">Since there's a recommendation earlier to offer an all-ASCII email address, I think this recommendation is not necessary. If one isn't using the same writing method (or the same language/character), it might be better storing the all-ASCII name
than than the 'A-label' name. It's easier to manage 'josephyee' than 'xn--qoqx77cy1a' which rely on mail client or backend to render it back properly.<br class="">
<br class="">
(4)<br class="">
Upon use, the client MUA software should convert the A-Label to the appropriate U-Label, at which point the friend or colleague will possess the EAI formatted email address despite not having a keyboard or IME which supports the target script.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">First, this one is more of a recommendation for mail client section than mail service provider section.<br class="">
</div>
<div class="">Second, please see below for a more in depth discussion on the whole encoding mailbox name.<br class="">
<br class="">
(5)<br class="">
How to ensure delivery to non-EAI ready mail systems<br class="">
- Normalising mailbox names in non-ASCII scripts <br class="">
</div>
<div class=""><br class="">
</div>
<div class="">If the recipient is non-EAI ready mail systems, normalising mailbox names would not help. Non-ASCII characters still exist in the mailbox name after normalization.<br class="">
<br class="">
*****<br class="">
</div>
<div class="">(Note: I'm co-chair of EAI working group at IETF, but I speak as individual only)<br class="">
<br class="">
</div>
<div class="">On Encoding (A-label, punycode, etc) mailbox name<br class="">
<br class="">
</div>
<div class="">At EAI working group, the notion of encoding the UTF8 mailbox name into pure-ASCII mailbox had been discussed, and there is no recommendation made on it. Mailbox management is different from domain management, applying the same encoding algorithm
may sound intuitive as domain name already used it and seeming of consistent because the same encoding was provided on both sides of the @ sign. The first drawback, as mentioned above, is the limitation of characters allowed in local part. There are legit
ASCII characters/symbols (!#$_) for email that won't make it with A-label. The second drawback is that some characters being used in human name may be prohibited under IDNA2008. There are another category of concerns with pure punycode algorithm on mailbox
name. Also, there are not enough coverage on ensuring various presentations of mail address to map to the same mailbox.
<br class="">
<br class="">
</div>
<div class="">I have serious concern on recommending this practice. This practice is neither mandatory standard nor best common practice, it probably would not be consistently implemented across mail clients, and I would not be surprise if some implementer
were against this. While we can recommend to think-about/adopt encoding practice, I'm concern that we need to expand more writing to the quick guide.<br class="">
<br class="">
</div>
<div class="">If there's a strong desire to push for an encoding practice, there's a need for another in depth writing on pros & cons, deployment and operation needs, what works & what doesn't.<br class="">
<br class="">
</div>
<div class="">Best,<br class="">
</div>
<div class="">Joseph<br class="">
</div>
<div class=""><br class="">
<br class="">
<br class="">
</div>
<div class=""><br class="">
<br class="">
</div>
<div class=""><br class="">
<br class="">
</div>
<div class=""><br class="">
<br class="">
</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">
<div class="">
<div class="h5">On Sun, Jan 22, 2017 at 4:33 AM, Don Hollander <span dir="ltr" class="">
<<a href="mailto:don.hollander@icann.org" target="_blank" class="">don.hollander@icann.org</a>></span> wrote:<br class="">
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<div class="h5">Last month I sent out a formatted Quick Guide to EAI.<br class="">
<br class="">
This resulted in a number of comments from Ajay, Stuart, Mark, Lars & Dennis.<br class="">
<br class="">
These enhancements were mostly focused on the Email Service Provider.<br class="">
<br class="">
I have revised the source document which is attached.<br class="">
<br class="">
And for reference, I’m also including the formatted earlier draft.<br class="">
<br class="">
Could I please get any final comments by the end of this week (25th)?<br class="">
<br class="">
Thanks.<br class="">
<span class="m_-747807835945705418HOEnZb"><font color="#888888" class=""><br class="">
Don<br class="">
<br class="">
</font></span><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
</div>
</div>
<span class="">Don Hollander<br class="">
Universal Acceptance Steering Group<br class="">
Skype: don_hollander<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
</span>______________________________<wbr class="">_________________<br class="">
UA-EAI mailing list<br class="">
<a href="mailto:UA-EAI@icann.org" target="_blank" class="">UA-EAI@icann.org</a><br class="">
<a href="https://mm.icann.org/mailman/listinfo/ua-eai" rel="noreferrer" target="_blank" class="">https://mm.icann.org/mailman/l<wbr class="">istinfo/ua-eai</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>