[UA-EAI] HTML 5.2 and Internationalized Eamil Addresses

Sun Jul 23 22:14:43 UTC 2017

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 insidethestack.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://github.com/w3c/html/issues/845<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fhtml%2Fissues%2F845&data=02%7C01%7Cmarksv%40microsoft.com%7C3bacbdc267a8494587e408d4ca3be289%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636355805932629324&sdata=saE8T8RCcj1JUHsvFlZpkbzy89aqXoisL14Gmtrk5c0%3D&reserved=0> .  The overall issues
list for the HTML 5.2 spec, including a link to the working
draft, is at https://github.com/w3c/html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fhtml&data=02%7C01%7Cmarksv%40microsoft.com%7C3bacbdc267a8494587e408d4ca3be289%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636355805932629324&sdata=sphZH5ybpNlVtuPp%2F0NX5ydqBeNbHBEBBZ0ngafbRBk%3D&reserved=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 --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/mailman/private/ua-eai/attachments/20170723/1610fb69/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 94815 bytes
Desc: image002.jpg
URL: <https://mm.icann.org/mailman/private/ua-eai/attachments/20170723/1610fb69/image002-0001.jpg>