Shawn Steele | 24 Apr 21:21 2015

IDN in Unicode

> The basic propose is to find solution for IDN domains and email addresses be present in original scripts.  

That seems like a completely different discussion than "let's use UTF-32".  

Many applications handle domain names natively in either UTF-8 or UTF-16, either of which are sufficient
to describe the domains in their original scripts.  

Punycode is kind of a hack to provide a mechanism to resolve domain names using the preexisting
infrastructure that is limited to the ASCII space.  However many applications, like EAI, prefer UTF-8.

Our recommendations provide for IDN to be looked up with Punycode only in the resolution phase.  For many
apps that is transparent to the app and they can just use Unicode with the system API set.  Some apps, however
may need to recognize Punycode domains for whatever reason or additional protocol limitations.  However
in those cases it is still recommended that they prefer Unicode and only use the Punycode when absolutely necessary.

Jiankang Yao | 23 Apr 00:53 2015

Fwd: [UA-discuss] UA Internationalization Project Group kicks off!

For those who might be interested in it, the following list may be helpful.

发件人: "Tan Tanaka, Dennis" <dtantanaka <at>>
日期: 2015年4月23日 GMT+85:50:39
收件人: "ua-international <at>" <ua-international <at>>
抄送: "UA-discuss <at>" <UA-discuss <at>>
主题: [UA-discuss] UA Internationalization Project Group kicks off!

<!-- /* Font Definitions */ <at> font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} <at> font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} <at> font-face {font-family:"\ <at> SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif"; color:black;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:166332374; mso-list-type:hybrid; mso-list-template-ids:112494492 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1 {mso-list-id:291057015; mso-list-type:hybrid; mso-list-template-ids:1502929956 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->

Dear Project Group members,


The Internationalization (i18n for short) Project Group is open for business!


Here are a few items to get us started.



The i18n Project Group will be focused on the IDN ecosystem as it pertains to these four major categories:

1.       Standards (i.e., IETF, Unicode, W3C)

2.       Practices (i.e. guidelines established by others)

3.       Tools (i.e., apis, programming languages)

4.       Applications (e.g. browsers, email clients, other apps)

By IDN ecosystem we mean IDNA, EAI and IRI





Next Steps and action items

1.       Increase membership – We don’t pretend to know it all. We need help! Please share the mailing list address to anyone who you think is interested in the subject of IDNs, EAI and IRIs.

2.       Meetings – Our first group meeting will be in the week of May 11. This will allow Dusan and I time to prepare so that we have a meaningful and productive discussion. I will circulate a doodle poll to agree on a time.






IMA mailing list
IMA <at>
Franck Martin | 15 Apr 11:24 2015


it seems that a few MTA can be thrown at an email with a EAI RFC5321.mailfrom and pass the message fine to other
MTA or local delivery, as long as the MTA supports 8BITMIME and the RFC5321.rcptto is a standard email

replying to such email is a challenge, but it does not seem any MTA or MUA (with 8BITMIME) will complain
because the RFC5321.from is an EAI...

What’s your experience?
IMA mailing list
IMA <at>
Arnt Gulbrandsen | 15 Apr 11:13 2015

FWIW, draft-ietf-dane-openpgpkey-03

Some of you might want to take an interest in that. Might.

My wife pointed me to it, I've glanced at it and a) it seems to copy 4255, 
which AFAICT hasn't been much of a success and b) it adds to PGP, ditto. I 
can't find any motivation to care. But perhaps one of you should, so it'll 
avoid gratuitous incompatibility with 6530.

John Bucy | 25 Mar 01:16 2015

SMTPUTF8 for non EAI messages

This is a spillover from a discussion on dmarc <at>

Has the wg considered the case of using SMTPUTF8 as a means to avoid 2047/2231 encoding for messages that don't contain any eai addresses? I understand eai avoids downgrading since it doesn't really work for addr-spec but it seems like it should be harmless for places where encoded-word is allowed along the lines of the "gateway transformation" described in 6152.

IMA mailing list
IMA <at>
Jiankang Yao | 19 Dec 16:27 2014

Chinese email address

Dear all, 

    For those who can recognize the Chinese character, you can log on the    Following link to register a Chinese email address. You can also have an opportunity to get iPhone 6 as a prize.

IMA mailing list
IMA <at>
Jiankang Yao | 8 Dec 07:27 2014

***SPAM*** 6.681 (5) Fw: apec-eai-ppt

Dear all,

   If any one is interested in the Beijing APEC EAI workshop, below are some ppt files for the agenda of 


Particularly, John's speech is also online  


Best Regards,

Jiankang Yao
IMA mailing list
IMA <at>
John C Klensin | 4 Dec 18:30 2014

Conversations in other forums, wiki changes, question about local-parts


As many of you know but some may not, not only was there a very
successful (at least IMO) meeting about the SMTPUTF8 extensions
and internationalized mail in Beijing at the end of October
(thanks to Jiankang Yao), but there has been a recent discussion
about address syntax in W3C forms and the W3C
internationalization group.  

A few issues have come up in the various discussions that
inspired me to make some changes to the WG Wiki.  You might want
to take a look at them and either edit or raise issues here if
you disagree.   If anything I've said seems controversial,
please do identify the issues here.

As a reminder, the wiki is at

In addition, the folks working on Forms, notably Steven
Pemberton (copied) have noticed that the mailbox local-part
syntax of RFC 6532 allows some truly nasty Unicode strings,
including strings that start with combining marks and that
therefore may be very hard to have as input.  My recollection is
that was an intentional decision and not a mistake -- as with
passwords, hard-to-type strings can sometimes be an advantage in
email addresses.   However, it seems to me that they are very
much like case-sensitive strings in RFC 5321: we insist that
those be treated as separate up to the point of final delivery,
we forbid any message originating systems from assuming case
equivalence, and forbid intermediate systems from performing
case folding.  Then we advise those creating mailboxes or
operating delivery servers that they probably should not take
advantage of case-independence except in special circumstances
because case sensitive addresses are almost certain to create
confusion and to be mishandled by badly-written implementations.

It seems to me that we should say much the same thing about
badly-formed Unicode strings: support for them is required but
delivery servers that allow creation of mailbox names containing
such strings had really better know what they are getting into
and, otherwise, probably shouldn't.

If there is general agreement about that principle (or no strong
objections) I'll patch a note into the Wiki so we can come back
to it and formally see if there is consensus when we review the
documents for Full Standard.

Of course, if my memory is wrong and allowing such strings was
just a mistake, someone should start a discussion on that
subject and we should figure out what to do about it.

Shawn Steele | 7 Oct 21:06 2014


> (1) A conforming i19n SMTP ("EAI") implementation MUST be a
> conforming IDNA2008 implementation.  Can't have EAI without IDNA
> conformance.

I think that depends on the implementation.  EAI allows UTF-8 for most everything.  As pointed out it's
difficult to complete the SMTP handshake without having the punicode, however there are many other mail
related tasks that can be done without needing to know about IDNA?

For example, an application needn't send mail itself, it could gather the information it needed and then
use a compliant STMP library to actually send the message.  In that case the application itself may not need
to know anything about IDNA itself.

Indeed, I'd prefer that applications use IDN/DNS/Mail APIs that abstract away some of these details.

Ronald F. Guilmette | 6 Oct 06:25 2014

A simple question

Having just today skimmed... for the first time... RFC 6531, I have
a rather basic question.

It appears from my skimming that the first opportunity that either
an SMTP client or an SMTP server gets, under these protocol revisions,
to tell the other that it can support the new internationalized domain
names, is when the server responds to a client-initiated HELO or EHLO
command.  Is that correct?

If so, then I am wondering what sorts of encoding(s), if any, a client
will be allowed to use with respect to the domain name that it may
include within the HELO/EHLO command that it issues, i.e. before
either side of the conversation has said anything definitive about
what it can or can't support.  Must such domain names be represented
as Punycode?
Jiankang Yao | 25 Sep 08:19 2014

APEC EAI deployment meeting in Beijing

Dear all,
     CNNIC will host the APEC EAI deployment meeting in Beijing on 30 and 31 Oct. 2014.
      The meeting venue is  in Legendale Hotel Beijing ( ).
      The topic related to EAI deployment such as email history, IETF EAI protocol, current implementations, current deployment will be presented by speakers from all over the world in the first day.
      The panel discussion about how to push the EAI deployment will be arranged in the morning of the second day. After the meeting, we will arrange to visit CNNIC.
      Any interested persons are welcomed to join this meeting. If anyone has something to share in this meeting, pls kindly let me know it.
     BTW,  There is still an APEC sponsored speaker available. If It is approved by APEC, the APEC funding will provide economic air tickets and accomodation and Speaker’s honorarium to the APEC sponsored speaker.    
       If anyone is interested in becoming the APEC sponsored speaker , pls kindly let me know it.
Jiankang Yao
IMA mailing list
IMA <at>