[UA-EAI] [Ext] RE: HTML 5.2 and Internationalized Eamil Addresses
Don Hollander
don.hollander at icann.org
Tue Jul 25 05:42:15 UTC 2017
I think Coremail and XgenPlus work around it by treating the field as text and then applying their own code – instead of using a defined characteristic of email and letting the browser take care of it.
For the UASG site, which is built on WordPress, we had to treat the field WE labelled as email as text. If we had treated as email within WordPress it would reject perfectly valid email addresses.
D
On 25/07/17, 12:22 PM, "Mark Svancarek" <marksv at microsoft.com> wrote:
Thanks for clarifying.
I am still puzzled, though. Coremail and Xgenplus clearly demonstrate an ability to work around the spec, which perhaps renders the "significant annoyance" argument moot. But I don't understand why one would resist changing a spec which is known to be "wrong" and non-RFC compliant. Is the argument that revising it to be RFC-compliant would risk destabilizing more sites than fixing it?
-----Original Message-----
From: John C Klensin [mailto:john-ietf at jck.com]
Sent: Sunday, July 23, 2017 3:59 PM
To: Mark Svancarek <marksv at microsoft.com>
Cc: Jiankang <healthyao2000 at qq.com>; Hollander Don <don.hollander at icann.org>; Nalini J Elkins <nalini.elkins at insidethestack.com>; HEALTH Yao <yaojk at cnnic.cn>; Marvin Cheng <mwu at coremail.cn>; uki Ho <ylhe at coremail.cn>; Harish Chowdhary <harish at nixi.in>; Dr. AJAY D A T A <ajay at data.in>; ua-eai at icann.org; Jan Nelson <Jan.Nelson at microsoft.com>; Shawn Steele <Shawn.Steele at microsoft.com>; Stuart Stuple <stuartst at microsoft.com>
Subject: RE: HTML 5.2 and Internationalized Eamil Addresses
Mark,
I may be excessively pessimistic, but my impression from what I've seen is that only three forms of input to the relevant spec writers are likely to have any effect... and I'm not sure about and don't want to encourage the third);
(1) Major implementers of either web browsers or HTML validation systems point out that their inability, or the inability of others, to treat non-ASCII email addresses as email addresses is a problem, or at least a significant annoyance.
(2) Strong indications from major supporters of W3C that this is unacceptable and won't be tolerated any more, even if it means voting with their support levels.
(3) Governments or other regulatory bodies explaining to W3C that actions that do not validate non-ASCII addresses as ordinary email addresses are sufficiently hostile to national policies encouraging such addresses that they will seek ways to ban use of W3C recommendations and products conforming to them within the relevant countries or other sanctions against W3C and its professional staff.
I hope I'm wrong.
john
--On Sunday, July 23, 2017 22:14 +0000 Mark Svancarek <marksv at microsoft.com> wrote:
> John, sorry for delay responding. Hopefully there is still time to
> influence the spec.
>
> I've taken a peek at the Coremail site and confirmed that they simply
> disregard the Email input type and use the generic Text input type
> instead. I presume that XGenPlus does the same.
>
> So, the wrongness of the HTML 5.x spec in regard to the Email input
> type (which is apparently very well known, and documented at W3C.org),
> doesn't prevent use of browsers to implement EAI services. It does
> make web designers work harder, though.
> [cid:image002.jpg at 01D303C5.DC014DF0]
>
> UASG must engage, since the spec violates both the RFC as well as a
> good practice of UA-readiness (i.e. don't invent your own validation
> rules). But it's not blocking people from using browsers to send or
> receive to/from EAI email addresses.
> It's blocking web designers from easily building UA-ready web pages
> that receive email address strings from users.
>
> I suppose that if Coremail or Xgenplus, as email service providers,
> were to reach out to the spec committee this might influence them. Is
> that a reasonable assumption?
>
> Also, UASG could reach out to some appropriate technical press people
> and have them request clarification from the spec committee.
>
> /marksv
>
> From: Jiankang [mailto:healthyao2000 at qq.com]
> Sent: Thursday, July 13, 2017 3:24 PM
> To: Hollander Don
> <don.hollander at icann.org<mailto:don.hollander at icann.org>>;
> Mark Svancarek
> <marksv at microsoft.com<mailto:marksv at microsoft.com>> Subject:
> Fwd: HTML 5.2 and Internationalized Eamil Addresses
>
> uasg may do something for it.
>
> it is very important for UA
>
> Jiankang Yao
>
> From my phone
>
> 以下是转发的邮件：
> 重发－发件人: yaojk at cnnic.cn<mailto:yaojk at cnnic.cn>
> 发件人: John C Klensin
> <john-ietf at jck.com<mailto:john-ietf at jck.com>> 日期:
> 2017年7月14日 GMT+8 04:03:53
> 重发－收件人:
> healthyao2000 at qq.com<mailto:healthyao2000 at qq.com> 收件人:
> Nalini J Elkins
> <nalini.elkins at insidethestack.com<mailto:nalini.elkins at insidet> hestack.com>>, Don Hollander
> <don.hollander at icann.org<mailto:don.hollander at icann.org>>, YAO
> Jiankang <yaojk at cnnic.cn<mailto:yaojk at cnnic.cn>>, Marvin Cheng
> <mwu at coremail.cn<mailto:mwu at coremail.cn>>, Yuki Ho
> <ylhe at coremail.cn<mailto:ylhe at coremail.cn>>, Harish Chowdhary
> <harish at nixi.in<mailto:harish at nixi.in>>, "Dr. AJAY D A T A"
> <ajay at data.in<mailto:ajay at data.in>> 主题: HTML 5.2 and Internationalized
> Eamil Addresses Hi.
>
> I learned today that W3C is about to take the HTML 5.2 specification
> into the final review and approval process within the next few days.
> For email addresses, that specification provides for IDNA
> interpretation of non-ASCII domain names, but specifies treating
> addresses with non-ASCII characters in
> local-parts as invalid. If non-ASCII email addresses are not
> accepted, no one who uses email via a web browser will be able to use
> those addressesbe SMTPUTF8 address and no one who uses such an address
> will be able to communicate with anyone dependent on a browser. In
> addition, because SMTP servers rarely have reliable information about
> the MUAs and mail access mechanisms preferred by individual users, an
> SMTP server operator who might have some users accessing email via a
> web browser has considerable incentive to not advertise SMTPUTF8 at
> all.
>
> I understand the key reason for this decision in HTML 5.2 is that no
> existing browser supports non-ASCII local parts in email addresses.
> It has been strongly suggested that no one
> is really asking for the functionality, That obviously
> creates a chicken-and-egg problem: SMTPUTF8 addresses are not
> supported in browsers because the HTML spec says to not do so and and
> because there is no perceived demand and there is no perceived demand
> (or browser implementations because the functionality is not broadly
> available. I find it hard to believe that there are no browsers
> around that can accept email addresses with non-ASCII local parts,
> especially in countries and with email products that claim to have
> millions of users with non-ASCII addresses, but W3C apparently has
> been unable to find them.
>
> I've done all I can to turn this situation around, with no actual
> success. The problem remains that, as far as @3C knows, there is no
> browser support than and no demand from any actor they feel an
> obligation to listen to (as distinct from demand from various
> individuals who think supporting these addresses would be a good
> idea). If there is browser support out there, even in browsers whose
> only user interface is in a language that does not use Latin script,
> W3C needs to hear about it.
> Equally important, if SMTPUTF8 support in browsers, with non-ASCII
> addresses treated as valid, is required, they need to hear that, and
> need to hear whether the requirement is important enough to hold HTML
> 5.2 up until the changes are made or whether they should just consider
> the issue more carefully for future versions.
>
> The best way to comment is by adding to the github thread at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fw3c-252Fhtml-252Fissues-252F845-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257Cdb9dcf092ce04a32526108d4d21e7b2f-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636364475752330058-26sdata-3DdjWC1CKX-252B5xJeSP6DdPhQMOzgfS7MU-252FlbforaitxjLk-253D-26reserved-3D0&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=kNs2jbG8WWeAh_mKxpoXFmHV8PZpdRTGsTMLsCorR3E&s=7GvegIfK2ebIdoUjNTLWaPUDiZMacvmJZxrf1T4UKg0&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fna01.safelinks-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257Cdb9dcf092ce04a32526108d4d21e7b2f-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636364475752330058-26sdata-3DkaJOm5-252FgIR9iiNk1kuYref3ryg-252FO7X1ZINd7cNGGKYE-253D-26reserved-3D0&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=kNs2jbG8WWeAh_mKxpoXFmHV8PZpdRTGsTMLsCorR3E&s=CH5NW4wkS5_BOsShYBo-raTV-w5iMo49B3-4B4V8_5Y&e= .> protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fh
> tml%2Fissues%2F845&data=02%7C01%7Cmarksv%40microsoft.com%7C3ba
> cbdc267a8494587e408d4ca3be289%7C72f988bf86f141af91ab2d7cd011db
> 47%7C1%7C0%7C636355805932629324&sdata=saE8T8RCcj1JUHsvFlZpkbzy
> 89aqXoisL14Gmtrk5c0%3D&reserved=0> . The overall issues list for the
> HTML 5.2 spec, including a link to the working draft, is at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fw3c-252Fhtml-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257Cdb9dcf092ce04a32526108d4d21e7b2f-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636364475752330058-26sdata-3DPt5qLY3EVjrZNz0BYjX6VkUdObvKRh5T2Kv8Oj485-252FI-253D-26reserved-3D0&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=kNs2jbG8WWeAh_mKxpoXFmHV8PZpdRTGsTMLsCorR3E&s=AZKfeoiI9iiuZFynAGB1J9-ZD0AtHxAhrAdzrUksRRE&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fna01.safelinks.protection-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257Cdb9dcf092ce04a32526108d4d21e7b2f-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636364475752330058-26sdata-3DME-252FuoKSYvCQtQQtbeTixmJz8hqVGwGArF-252BY-252FunTx6DM-253D-26reserved-3D0&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=kNs2jbG8WWeAh_mKxpoXFmHV8PZpdRTGsTMLsCorR3E&s=cv2CgKJmjtf1go8dfsINxVUmi7sbtMFz_bR26066BNE&e= .> outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fhtml&data=02
> %7C01%7Cmarksv%40microsoft.com%7C3bacbdc267a8494587e408d4ca3be
> 289%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363558059326
> 29324&sdata=sphZH5ybpNlVtuPp%2F0NX5ydqBeNbHBEBBZ0ngafbRBk%3D&r
> eserved=0> . If the various actors on this subject in W3C (almost all
> of whom appear to be primarily users of European
> languages) don't know who you are (or someone else commenting is), I
> strongly suggest providing comments to establish that context as part
> of any remarks you post, especially if those comments involve
> discussion of deployed implementations or large numbers of users.
>
> If one wants global/ universal acceptance of non-ASCII email
> addresses, it seems to me that, for the reasons described above, HTML
> 5.x is on the critical path and acceptance is not going very far
> without it treating those addresses as valid.
>
> best,
> john
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: not available
URL: <https://mm.icann.org/mailman/private/ua-eai/attachments/20170725/7a64530e/smime.p7s>
More information about the UA-EAI
mailing list