[UA-EAI] HTML 5.2 and Internationalized Eamil Addresses

[Dr. Ajay Data]

We live in a world where gmail do not worry about dot and some allow multiple. For gmail cytcore@ or cyt.core@ is same and in some email services supports cyt..core@ 

I think we must adhere to ,  force validation and follow RFCs and allow these non compliant email ids to have END of LIFE soon.

Thanks. 

On July 26, 2017 10:07:34 AM GMT+05:30, cyt at coremail.cn wrote:
>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 at jck.com>
>> 发送时间: 2017-07-26 11:00:22 (星期三)
>> 收件人: cyt at coremail.cn, jiankang <yaojk at cnnic.cn>
>> 抄送: ua-eai at icann.org
>> 主题: Re: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses
>> 
>> 
>> 
>> --On Tuesday, July 25, 2017 18:37 +0800 cyt at 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 at icann.org
>https://mm.icann.org/mailman/listinfo/ua-eai

-- 
Sent from my Android device with BharatSync Communicator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/mailman/private/ua-eai/attachments/20170726/adc8ac5a/attachment.html>