Hi,John:

For example, some email address contains two consecutive dots that represent some of the other things inside. And some custumers have used Big5/GBK encoding local part in their old system internal before EAI.   
zh.icormail.net has none of these problems. But we need to consider a unified compatibility issues.
And the browser support is another problem. Too many peaple use IE8 still.
The chrome only support HTML5.0, and HTML5.0 email input type does not seem to support EAI now. We need to detect the browser version before we generate the INPUT tag even after chrome support EAI. It's not look like friendly to the programers.
I think it is a good idea to use the email input type when registering a new email user in a new system.

cyt
2017.07.26

 -----原始邮件-----
 发件人: "John C Klensin" <john-ietf@jck.com>
 发送时间: 2017-07-26 11:00:22 (星期三)
 收件人: cyt@coremail.cn, jiankang <yaojk@cnnic.cn>
 抄送: ua-eai@icann.org
 主题: Re: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses

 --On Tuesday, July 25, 2017 18:37 +0800 cyt@coremail.cn wrote:

...
 On the other hand, some customers require to use some special
 characters( may be forbidden by standard RFC) to compose the
 email address. So we decide to use Text input type and
 validate the email address by regular expression.

 I don't understand this and would appreciate some education.  In
 the domain part of the address, the only restrictions are those
 imposed by IDNA2008 (for your purposes since Chinese is not
 written right to left, RFC 5891 and 5892) and there are almost
 no restrictions on the local part in RFCs 6531 and 6532.   In
 particular, neither set of RFCs prohibits code points that have
 compatibility equivalents even though using them may not be an
 especially good idea.  So what special characters have you seen
 customers demanding or using that are forbidden by the RFCs?

 thanks,
     john

UA-EAI mailing list
UA-EAI@icann.org
https://mm.icann.org/mailman/listinfo/ua-eai