Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses
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@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@qq.com] Sent: Thursday, July 13, 2017 3:24 PM To: Hollander Don <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@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@cnnic.cn<mailto:yaojk@cnnic.cn> 发件人: John C Klensin <john-ietf@jck.com<mailto:john-ietf@jck.com>> 日期: 2017年7月14日 GMT+8 04:03:53 重发－收件人: healthyao2000@qq.com<mailto:healthyao2000@qq.com> 收件人: Nalini J Elkins <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidethestack.com>>, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>, YAO Jiankang <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>, Marvin Cheng <mwu@coremail.cn<mailto:mwu@coremail.cn>>, Yuki Ho <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, Harish Chowdhary <harish@nixi.in<mailto:harish@nixi.in>>, "Dr. AJAY D A T A" <ajay@data.in<mailto:ajay@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
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@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@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@qq.com] Sent: Thursday, July 13, 2017 3:24 PM To: Hollander Don <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@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@cnnic.cn<mailto:yaojk@cnnic.cn> 发件人: John C Klensin <john-ietf@jck.com<mailto:john-ietf@jck.com>> 日期: 2017年7月14日 GMT+8 04:03:53 重发－收件人: healthyao2000@qq.com<mailto:healthyao2000@qq.com> 收件人: Nalini J Elkins <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidet hestack.com>>, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>, YAO Jiankang <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>, Marvin Cheng <mwu@coremail.cn<mailto:mwu@coremail.cn>>, Yuki Ho <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, Harish Chowdhary <harish@nixi.in<mailto:harish@nixi.in>>, "Dr. AJAY D A T A" <ajay@data.in<mailto:ajay@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%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://github.com/w3c/html<https://na01.safelinks.protection. 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
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@jck.com] Sent: Sunday, July 23, 2017 3:59 PM To: Mark Svancarek <marksv@microsoft.com> Cc: Jiankang <healthyao2000@qq.com>; Hollander Don <don.hollander@icann.org>; Nalini J Elkins <nalini.elkins@insidethestack.com>; HEALTH Yao <yaojk@cnnic.cn>; Marvin Cheng <mwu@coremail.cn>; uki Ho <ylhe@coremail.cn>; Harish Chowdhary <harish@nixi.in>; Dr. AJAY D A T A <ajay@data.in>; ua-eai@icann.org; Jan Nelson <Jan.Nelson@microsoft.com>; Shawn Steele <Shawn.Steele@microsoft.com>; Stuart Stuple <stuartst@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@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@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@qq.com] Sent: Thursday, July 13, 2017 3:24 PM To: Hollander Don <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@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@cnnic.cn<mailto:yaojk@cnnic.cn> 发件人: John C Klensin <john-ietf@jck.com<mailto:john-ietf@jck.com>> 日期: 2017年7月14日 GMT+8 04:03:53 重发－收件人: healthyao2000@qq.com<mailto:healthyao2000@qq.com> 收件人: Nalini J Elkins <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidet hestack.com>>, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>, YAO Jiankang <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>, Marvin Cheng <mwu@coremail.cn<mailto:mwu@coremail.cn>>, Yuki Ho <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, Harish Chowdhary <harish@nixi.in<mailto:harish@nixi.in>>, "Dr. AJAY D A T A" <ajay@data.in<mailto:ajay@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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fhtml%2Fissues%2F845&data=02%7C01%7Cmarksv%40microsoft.com%7Cdb9dcf092ce04a32526108d4d21e7b2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636364475752330058&sdata=djWC1CKX%2B5xJeSP6DdPhQMOzgfS7MU%2FlbforaitxjLk%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Cmarksv%40microsoft.com%7Cdb9dcf092ce04a32526108d4d21e7b2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636364475752330058&sdata=kaJOm5%2FgIR9iiNk1kuYref3ryg%2FO7X1ZINd7cNGGKYE%3D&reserved=0. 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fhtml&data=02%7C01%7Cmarksv%40microsoft.com%7Cdb9dcf092ce04a32526108d4d21e7b2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636364475752330058&sdata=Pt5qLY3EVjrZNz0BYjX6VkUdObvKRh5T2Kv8Oj485%2FI%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks.protection&data=02%7C01%7Cmarksv%40microsoft.com%7Cdb9dcf092ce04a32526108d4d21e7b2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636364475752330058&sdata=ME%2FuoKSYvCQtQQtbeTixmJz8hqVGwGArF%2BY%2FunTx6DM%3D&reserved=0. 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
--On Tuesday, July 25, 2017 00:22 +0000 Mark Svancarek <marksv@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?
Ask chaals -- his committee. My rather harsh comments apply mostly if you want changes in 5.2. I'm just guess9ing, but, if you are willing to wait until late this calendar year for 5.2, start working on 5.3 and hope to have a standard that does the right thing sometime late in 2018, that is probably a lot easier although some of the same considerations would still apply (see chaals's note). Also, be a little careful about "RFC-complaint. There is no "mandatory to implement" requirement for SMTPUTF8 or even support for IDNA in email clients or servers. john
From: Mark Svancarek Date: 2017-07-25 08:22 To: John C Klensin CC: Jiankang; Hollander Don; Nalini J Elkins; HEALTH Yao; Marvin Cheng; uki Ho; Harish Chowdhary; Dr. AJAY D A T A; ua-eai@icann.org; Jan Nelson; Shawn Steele; Stuart Stuple Subject: RE: HTML 5.2 and Internationalized Eamil Addresses
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?
+1 I share the same concern with you. Jiankang Yao
Hi, Coremail doesn't use email input type. Different versions of the browser, the implementation of the e-mail address of the inspection specifications may be different. 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. cyt 2017.07.25 -----原始邮件----- 发件人:"Jiankang Yao" <yaojk@cnnic.cn> 发送时间:2017-07-25 14:02:34 (星期二) 收件人: "Mark Svancarek" <marksv@microsoft.com>, "John C Klensin" <john-ietf@jck.com> 抄送: "Jan Nelson" <Jan.Nelson@microsoft.com>, "Nalini Elkins" <nalini.elkins@insidethestack.com>, "uki Ho" <ylhe@coremail.cn>, "ua-eai@icann.org" <ua-eai@icann.org>, "Shawn Steele" <Shawn.Steele@microsoft.com>, "Harish Chowdhary" <harish@nixi.in> 主题: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses From: Mark Svancarek Date: 2017-07-25 08:22 To: John C Klensin CC: Jiankang; Hollander Don; Nalini J Elkins; HEALTH Yao; Marvin Cheng; uki Ho; Harish Chowdhary; Dr. AJAY D A T A; ua-eai@icann.org; Jan Nelson; Shawn Steele; Stuart Stuple Subject: RE: HTML 5.2 and Internationalized Eamil Addresses
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?
+1 I share the same concern with you. Jiankang Yao
Hmm, this complicates things. If the Email input type were revised in a future spec to match the “standard” RFC definition, it would still disallow some Coremail-assigned email addresses – did I understand this correctly? From: ua-eai-bounces@icann.org [mailto:ua-eai-bounces@icann.org] On Behalf Of cyt@coremail.cn Sent: Tuesday, July 25, 2017 3:38 AM To: HEALTH Yao <yaojk@cnnic.cn> Cc: john c klensin <john-ietf@jck.com>; ua-eai@icann.org Subject: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses Hi, Coremail doesn't use email input type. Different versions of the browser, the implementation of the e-mail address of the inspection specifications may be different. 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. cyt 2017.07.25 -----原始邮件----- 发件人:"Jiankang Yao" <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>> 发送时间:2017-07-25 14:02:34 (星期二) 收件人: "Mark Svancarek" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "John C Klensin" <john-ietf@jck.com<mailto:john-ietf@jck.com>> 抄送: "Jan Nelson" <Jan.Nelson@microsoft.com<mailto:Jan.Nelson@microsoft.com>>, "Nalini Elkins" <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidethestack.com>>, "uki Ho" <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, "ua-eai@icann.org<mailto:ua-eai@icann.org>" <ua-eai@icann.org<mailto:ua-eai@icann.org>>, "Shawn Steele" <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>>, "Harish Chowdhary" <harish@nixi.in<mailto:harish@nixi.in>> 主题: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses From: Mark Svancarek<mailto:marksv@microsoft.com> Date: 2017-07-25 08:22 To: John C Klensin<mailto:john-ietf@jck.com> CC: Jiankang<mailto:healthyao2000@qq.com>; Hollander Don<mailto:don.hollander@icann.org>; Nalini J Elkins<mailto:nalini.elkins@insidethestack.com>; HEALTH Yao<mailto:yaojk@cnnic.cn>; Marvin Cheng<mailto:mwu@coremail.cn>; uki Ho<mailto:ylhe@coremail.cn>; Harish Chowdhary<mailto:harish@nixi.in>; Dr. AJAY D A T A<mailto:ajay@data.in>; ua-eai@icann.org<mailto:ua-eai@icann.org>; Jan Nelson<mailto:Jan.Nelson@microsoft.com>; Shawn Steele<mailto:Shawn.Steele@microsoft.com>; Stuart Stuple<mailto:stuartst@microsoft.com> Subject: RE: HTML 5.2 and Internationalized Eamil Addresses
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?
+1 I share the same concern with you. Jiankang Yao
Hi, Mark: Coremail just use the "incorrect" email address internally. But user input or paste all type email address in the same place(TO/CC/BCC). The input string may not conform to the standard RFC, but the email address sent to outside is compliant. Checking the email address by regular expression can achieve more flexible logic. The email input type may be more appropriate in other cases. cyt 2017.07.26 -----原始邮件----- 发件人:"Mark Svancarek" <marksv@microsoft.com> 发送时间:2017-07-25 23:33:58 (星期二) 收件人: "cyt@coremail.cn" <cyt@coremail.cn>, "HEALTH Yao" <yaojk@cnnic.cn> 抄送: "john c klensin" <john-ietf@jck.com>, "ua-eai@icann.org" <ua-eai@icann.org> 主题: RE: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses Hmm, this complicates things. If the Email input type were revised in a future spec to match the “standard” RFC definition, it would still disallow some Coremail-assigned email addresses – did I understand this correctly? From:ua-eai-bounces@icann.org [mailto:ua-eai-bounces@icann.org] On Behalf Of cyt@coremail.cn Sent: Tuesday, July 25, 2017 3:38 AM To: HEALTH Yao <yaojk@cnnic.cn> Cc: john c klensin <john-ietf@jck.com>; ua-eai@icann.org Subject: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses Hi, Coremail doesn't use email input type. Different versions of the browser, the implementation of the e-mail address of the inspection specifications may be different. 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. cyt 2017.07.25 -----原始邮件----- 发件人:"Jiankang Yao" <yaojk@cnnic.cn> 发送时间:2017-07-25 14:02:34 (星期二) 收件人: "Mark Svancarek" <marksv@microsoft.com>, "John C Klensin" <john-ietf@jck.com> 抄送: "Jan Nelson" <Jan.Nelson@microsoft.com>, "Nalini Elkins" <nalini.elkins@insidethestack.com>, "uki Ho" <ylhe@coremail.cn>, "ua-eai@icann.org" <ua-eai@icann.org>, "Shawn Steele" <Shawn.Steele@microsoft.com>, "Harish Chowdhary" <harish@nixi.in> 主题: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses From: Mark Svancarek Date: 2017-07-25 08:22 To: John C Klensin CC: Jiankang; Hollander Don; Nalini J Elkins; HEALTH Yao; Marvin Cheng; uki Ho; Harish Chowdhary; Dr. AJAY D A T A; ua-eai@icann.org; Jan Nelson; Shawn Steele; Stuart Stuple Subject: RE: HTML 5.2 and Internationalized Eamil Addresses
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?
+1 I share the same concern with you. Jiankang Yao
--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
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
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@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@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
-- Sent from my Android device with BharatSync Communicator.
Hello Mark, others, On 2017/07/24 07:14, Mark Svancarek via UA-EAI 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@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?
It's much more the browsers that need to be influenced than the "spec committee". As John has already explained, W3C, in particular when it comes to HTML and related technology, doesn't move parts of a spec forward if they don't have actual implementations. Regards, Martin.
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@qq.com] Sent: Thursday, July 13, 2017 3:24 PM To: Hollander Don <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@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@cnnic.cn<mailto:yaojk@cnnic.cn> 发件人: John C Klensin <john-ietf@jck.com<mailto:john-ietf@jck.com>> 日期: 2017年7月14日 GMT+8 04:03:53 重发－收件人: healthyao2000@qq.com<mailto:healthyao2000@qq.com> 收件人: Nalini J Elkins <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidethestack.com>>, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>, YAO Jiankang <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>, Marvin Cheng <mwu@coremail.cn<mailto:mwu@coremail.cn>>, Yuki Ho <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, Harish Chowdhary <harish@nixi.in<mailto:harish@nixi.in>>, "Dr. AJAY D A T A" <ajay@data.in<mailto:ajay@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
Hi, I'm a co-chair of the relevant W3C Working Group ("Web Platform Working Group" <https://www.w3.org/WebPlatform/WG/>) as well as a member of this list - and the person who raised the actual issues on HTML to make it support EAI better. I can confirm that the WG understands the issue, and that as Martin says, without browser implementation it is difficult to make something a W3C Recommendation. It will *help* if email providers can comment on the relevant issues, such as https://github.com/w3c/html/issues/845 explaining who they are, that they are shipping products, ideally what sort of user numbers rely on this feature. It will help even more if we can show browser implementation - there are many browsers beyond the "usual suspects - google, microsoft, apple and mozilla" who are often seen as the ultimate arbiters, and some of them work in markets where this feature would be helpful. It is also true, as Mark says, that the problem here is that "we" are making life a bit harder hard for developers who want to do useful things with non-ASCII email addresses, rather than making it impossible. Like many, Yandex mail uses a hack to allow non-ASCII - as I did in this mail composed in Yandex mail's web client. The fact that so many systems are forced to create such a workaround constitutes some part of an argument for standardising it so browsers aren't dealing with such a mess, but getting a prototype implementation would be really helpful too - most browser makers provide an email service, and seem OK with that being work each such service does for themselves. It is highly unlikely given the apparent lack of browser implementation today that we will get any progress for HTML 5.2, which is planned to ship later this year. But it is possible to get changes into early drafts of HTML 5.3. Without browser implementation driving "de facto" standardisation, it will be important to describe the common features and the benefits and drawbacks of client-side implementation if this is to have much chance of surviving from a draft to a Recommendation. cheers Chaals 24.07.2017, 03:44, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>:
Hello Mark, others,
On 2017/07/24 07:14, Mark Svancarek via UA-EAI 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@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?
It's much more the browsers that need to be influenced than the "spec committee". As John has already explained, W3C, in particular when it comes to HTML and related technology, doesn't move parts of a spec forward if they don't have actual implementations.
Regards, Martin.
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@qq.com] Sent: Thursday, July 13, 2017 3:24 PM To: Hollander Don <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@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@cnnic.cn<mailto:yaojk@cnnic.cn> 发件人: John C Klensin <john-ietf@jck.com<mailto:john-ietf@jck.com>> 日期: 2017年7月14日 GMT+8 04:03:53 重发－收件人: healthyao2000@qq.com<mailto:healthyao2000@qq.com> 收件人: Nalini J Elkins <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidethestack.com>>, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>, YAO Jiankang <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>, Marvin Cheng <mwu@coremail.cn<mailto:mwu@coremail.cn>>, Yuki Ho <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, Harish Chowdhary <harish@nixi.in<mailto:harish@nixi.in>>, "Dr. AJAY D A T A" <ajay@data.in<mailto:ajay@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
_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
-- Chaals is Charles McCathie Nevile find more at http://yandex.com
Thanks for that. I don’t expect it to be included in 5.2, but I would like to work on a strategy and tactics for getting it deployed in 5.3
From what I’ve read:
1) Define the problem. This shouldn’t be hard and according to Charles, the relevant group understand the issue. 2) Get community members to advocate for its inclusion in 5.3 a. This could be the existing and future EAI providers b. This could be other browser based services that are expected to reply on an EAI facility c. This could be niche browser developers – particularly those in IDN communities – China, India & Russia feel like large such communities 3) Get one or more of the major players to build facilities into their core browser and then advocate for an associated standard Wordpress is a very commonly used Content Management System that doesn’t support EAI. I suspect it would be useful to get them on board. So, another task is engaging the relevant parties from the above lists. What else? D On 24/07/17, 2:27 PM, "ua-eai-bounces@icann.org on behalf of chaals is Charles McCathie Nevile" <ua-eai-bounces@icann.org on behalf of chaals@yandex.ru> wrote: Hi, I'm a co-chair of the relevant W3C Working Group ("Web Platform Working Group" <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_WebPlatform_... >) as well as a member of this list - and the person who raised the actual issues on HTML to make it support EAI better. I can confirm that the WG understands the issue, and that as Martin says, without browser implementation it is difficult to make something a W3C Recommendation. It will *help* if email providers can comment on the relevant issues, such as https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_html_iss... explaining who they are, that they are shipping products, ideally what sort of user numbers rely on this feature. It will help even more if we can show browser implementation - there are many browsers beyond the "usual suspects - google, microsoft, apple and mozilla" who are often seen as the ultimate arbiters, and some of them work in markets where this feature would be helpful. It is also true, as Mark says, that the problem here is that "we" are making life a bit harder hard for developers who want to do useful things with non-ASCII email addresses, rather than making it impossible. Like many, Yandex mail uses a hack to allow non-ASCII - as I did in this mail composed in Yandex mail's web client. The fact that so many systems are forced to create such a workaround constitutes some part of an argument for standardising it so browsers aren't dealing with such a mess, but getting a prototype implementation would be really helpful too - most browser makers provide an email service, and seem OK with that being work each such service does for themselves. It is highly unlikely given the apparent lack of browser implementation today that we will get any progress for HTML 5.2, which is planned to ship later this year. But it is possible to get changes into early drafts of HTML 5.3. Without browser implementation driving "de facto" standardisation, it will be important to describe the common features and the benefits and drawbacks of client-side implementation if this is to have much chance of surviving from a draft to a Recommendation. cheers Chaals 24.07.2017, 03:44, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>: > Hello Mark, others, > > On 2017/07/24 07:14, Mark Svancarek via UA-EAI 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@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? > > It's much more the browsers that need to be influenced than the "spec > committee". As John has already explained, W3C, in particular when it > comes to HTML and related technology, doesn't move parts of a spec > forward if they don't have actual implementations. > > Regards, Martin. > >> 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@qq.com] >> Sent: Thursday, July 13, 2017 3:24 PM >> To: Hollander Don <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@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@cnnic.cn<mailto:yaojk@cnnic.cn> >> 发件人: John C Klensin <john-ietf@jck.com<mailto:john-ietf@jck.com>> >> 日期: 2017年7月14日 GMT+8 04:03:53 >> 重发－收件人: healthyao2000@qq.com<mailto:healthyao2000@qq.com> >> 收件人: Nalini J Elkins <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidethestack.com>>, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>, YAO Jiankang <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>, Marvin Cheng <mwu@coremail.cn<mailto:mwu@coremail.cn>>, Yuki Ho <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, Harish Chowdhary <harish@nixi.in<mailto:harish@nixi.in>>, "Dr. AJAY D A T A" <ajay@data.in<mailto:ajay@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__github.com_w3c_html_iss... <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protecti... > . 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__github.com_w3c_html&d=D... <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protecti... > . 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 > > _______________________________________________ > UA-EAI mailing list > UA-EAI@icann.org > https://mm.icann.org/mailman/listinfo/ua-eai -- Chaals is Charles McCathie Nevile find more at https://urldefense.proofpoint.com/v2/url?u=http-3A__yandex.com&d=DwIGaQ&c=Fm... _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
I like this strategy... what is the timeline for 5.3? -----Original Message----- From: Don Hollander [mailto:don.hollander@icann.org] Sent: Monday, July 24, 2017 1:22 AM To: chaals is Charles McCathie Nevile <chaals@yandex.ru>; Martin J. Dürst <duerst@it.aoyama.ac.jp>; Mark Svancarek <marksv@microsoft.com>; john-ietf@jck.com; chaals is Charles McCathie Nevile <chaals@яндекс.рф> Cc: Jan Nelson <Jan.Nelson@microsoft.com>; Shawn Steele <Shawn.Steele@microsoft.com>; Nalini J Elkins <nalini.elkins@insidethestack.com>; Jiankang <healthyao2000@qq.com>; ua-eai@icann.org; uki Ho <ylhe@coremail.cn>; Harish Chowdhary <harish@nixi.in> Subject: Re: [UA-EAI] HTML 5.2 and Internationalized Eamil Addresses Thanks for that. I don’t expect it to be included in 5.2, but I would like to work on a strategy and tactics for getting it deployed in 5.3 From what I’ve read: 1) Define the problem. This shouldn’t be hard and according to Charles, the relevant group understand the issue. 2) Get community members to advocate for its inclusion in 5.3 a. This could be the existing and future EAI providers b. This could be other browser based services that are expected to reply on an EAI facility c. This could be niche browser developers – particularly those in IDN communities – China, India & Russia feel like large such communities 3) Get one or more of the major players to build facilities into their core browser and then advocate for an associated standard Wordpress is a very commonly used Content Management System that doesn’t support EAI. I suspect it would be useful to get them on board. So, another task is engaging the relevant parties from the above lists. What else? D On 24/07/17, 2:27 PM, "ua-eai-bounces@icann.org on behalf of chaals is Charles McCathie Nevile" <ua-eai-bounces@icann.org on behalf of chaals@yandex.ru> wrote: Hi, I'm a co-chair of the relevant W3C Working Group ("Web Platform Working Group" <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_WebPlatform_... >) as well as a member of this list - and the person who raised the actual issues on HTML to make it support EAI better. I can confirm that the WG understands the issue, and that as Martin says, without browser implementation it is difficult to make something a W3C Recommendation. It will *help* if email providers can comment on the relevant issues, such as https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_html_iss... explaining who they are, that they are shipping products, ideally what sort of user numbers rely on this feature. It will help even more if we can show browser implementation - there are many browsers beyond the "usual suspects - google, microsoft, apple and mozilla" who are often seen as the ultimate arbiters, and some of them work in markets where this feature would be helpful. It is also true, as Mark says, that the problem here is that "we" are making life a bit harder hard for developers who want to do useful things with non-ASCII email addresses, rather than making it impossible. Like many, Yandex mail uses a hack to allow non-ASCII - as I did in this mail composed in Yandex mail's web client. The fact that so many systems are forced to create such a workaround constitutes some part of an argument for standardising it so browsers aren't dealing with such a mess, but getting a prototype implementation would be really helpful too - most browser makers provide an email service, and seem OK with that being work each such service does for themselves. It is highly unlikely given the apparent lack of browser implementation today that we will get any progress for HTML 5.2, which is planned to ship later this year. But it is possible to get changes into early drafts of HTML 5.3. Without browser implementation driving "de facto" standardisation, it will be important to describe the common features and the benefits and drawbacks of client-side implementation if this is to have much chance of surviving from a draft to a Recommendation. cheers Chaals 24.07.2017, 03:44, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>: > Hello Mark, others, > > On 2017/07/24 07:14, Mark Svancarek via UA-EAI 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@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? > > It's much more the browsers that need to be influenced than the "spec > committee". As John has already explained, W3C, in particular when it > comes to HTML and related technology, doesn't move parts of a spec > forward if they don't have actual implementations. > > Regards, Martin. > >> 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@qq.com] >> Sent: Thursday, July 13, 2017 3:24 PM >> To: Hollander Don <don.hollander@icann.org<mailto:don.hollander@icann.org>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@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@cnnic.cn<mailto:yaojk@cnnic.cn> >> 发件人: John C Klensin <john-ietf@jck.com<mailto:john-ietf@jck.com>> >> 日期: 2017年7月14日 GMT+8 04:03:53 >> 重发－收件人: healthyao2000@qq.com<mailto:healthyao2000@qq.com> >> 收件人: Nalini J Elkins <nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidethestack.com>>, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>>, YAO Jiankang <yaojk@cnnic.cn<mailto:yaojk@cnnic.cn>>, Marvin Cheng <mwu@coremail.cn<mailto:mwu@coremail.cn>>, Yuki Ho <ylhe@coremail.cn<mailto:ylhe@coremail.cn>>, Harish Chowdhary <harish@nixi.in<mailto:harish@nixi.in>>, "Dr. AJAY D A T A" <ajay@data.in<mailto:ajay@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__github.com_w3c_html_iss... <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protecti... > . 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__github.com_w3c_html&d=D... <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protecti... > . 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 > > _______________________________________________ > UA-EAI mailing list > UA-EAI@icann.org > https://mm.icann.org/mailman/listinfo/ua-eai -- Chaals is Charles McCathie Nevile find more at https://urldefense.proofpoint.com/v2/url?u=http-3A__yandex.com&d=DwIGaQ&c=Fm... _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
participants (8)
-
chaals is Charles McCathie Nevile -
cyt＠coremail.cn -
Don Hollander -
Dr. Ajay Data -
Jiankang Yao -
John C Klensin -
Mark Svancarek -
Martin J. Dürst