Re: [i18n-activity] input type=email change proposals

It seems [ICANN document](https://uasg.tech/wp-content/uploads/2017/04/Unleashing-the-Power-of-All-Domains-White-Paper.pdf) mainly states and discusses about importance of IDNA but not a full EAI, except for one reference of research on how much existing system (MTA domain) do support things or not (from IDNA only to full EAI), and I suppose this reference is somehow weak for us to push this change into proposal to WhatWG. 

>As i understand the WhatWG spec, the user can type anything into such a field and the browser should use punycode to convert non-ASCII characters, on both sides of the @ sign, to ascii for storage and transmission. 
I don't think this is correct, since WhatWG spec notes as 
> User agents may transform the value for display and editing; in particular, user agents should convert punycode in the domain labels of the value to IDN in the display and vice versa.
and punycode is specifically noted only for the domain labels. Of course yes, as in note 1 of original comment of this issue, RFC 6530 notes on downgrading of local part (in sec 8) as
> Mechanisms by which such addresses may be found or identified are outside the scope of these specifications as are decisions about the design of originating systems such as whether any required transformations are made by the user, the originating MUA, or the submission server.
so, no transformation on local part is allowed (as noted even in RFC 2821 sec 2.3.10):
> Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.

So, note 2 on left side (local-part) is not correct. There SHALL be no way to convert local-part by UA, except by the host specified in the domain part of the email address.

EAI (Email Address i18n) introduced SMTPUTF8 as a new ehlo-keyword to SMTP EHLO command to notice connected MTA that the target MTA supports extended unicode EAI (along with some extentions to email header part without using 8bitmime), but there is no backward compatibility to non-support MTAs which just shall return error but not to try dealing with EAI. Seeking current situation around SMTPUTF8, most of large online email service provides do support EAI like [Gmail/G-Suite](https://googleblog.blogspot.com/2014/08/a-first-step-toward-more-global-email.html) or [Office 365 (supported early this year)](https://blogs.technet.microsoft.com/exchange/2018/02/26/eai-support-announcement-update/), some MUA supports like Outlook (2016) but some are not like Thunderbird (need to be checked bmo, but AFAIK). But SMTPUTF8 is only supported by small number of MX zones, like [~4% supported in .ru (Russian)](https://statdom.ru/tld/ru/report/mxsmtputf8/#52) even in Oct/2018. Considering these situations, and thinking as web service developer point of view, an option noted in note 6 seems feasible for me, like 

- having both type=email and type=email-eai (keeping type=email as now not to break or cause issue on backward compatibility)
- type=email shall accept IDNA but not non-ascii local-part, display domain part in utf-8 but not in punycode for user experience point of view
- type=email-eai shall accept EAI email address and show in non converted format

For 3rd point, RFC 6530 sec 7.1 notes as:
>When the local part of the address includes characters outside the ASCII character repertoire, use of ASCII-compatible encoding (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to promote consistent processing of characters throughout the address.

-- 
GitHub Notification of comment by himorin
Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/607#issuecomment-439372992 using your GitHub account

Received on Friday, 16 November 2018 12:02:15 UTC