Validating email addresses, and the HTML5 <input type="email"> spec
UA EAI and Technology Working Group colleagues: I have a pair of topics to bring up, and both topics are relevant to both working groups. Topic 1. *HTML5 <input type="email"> specification* HTML includes a form field entity known as <input>. This takes a "type" attribute. One state for the "type" attribute is "email"[1]. When the page has a <input type="email"> field, the browser must check that the email address matches a syntax[2] which is limited to ASCII. Thus, by specification, this form field may not accept EAI email addresses. This is a problem for Universal Acceptance. John Levine opened an issue against the HTML 5 spec about this: *Validating internationalized mail addresses in <input type="email">* #4562 [3]. Since it was opened 2019, discussion has started and stopped in this issue. On April 30, the discussion started again[4]. I have the impression that this is a particularly opportune moment. From the comments, influential people seem to be involved from both the Universal Acceptance and HTML implementor groups. People in these working groups who would like to move EAI in HTML forward, I suggest that you read through the recent discussion. Look for questions which the HTML folks are asking which have not received answers that satisfy them. Perhaps post suggested interventions on our WG lists, or suggest them to experts we know such as John Levine, or even (if you think you can do so productively) post in that issue thread. For example, [5]
Can you tell me what kind of inputs are there that IDNA 2008 accepts but that UTS 46 /in non-transitional mode/ either rejects or maps to different ASCII form than IDNA 2008?
As an UTS 46 implementor, my current understanding is that there are none, but if there are some, it would be useful for me to know. [5]
It seems to me that one useful function UASG could serve is to be a centre of expertise which is capable of giving reliable, well-thought-out answers to questions like this. Topic 2. *A UASG White paper on Email Address Validation* I encouraged the UA Technology working group to set a 2024 goal[5] of writing a paper recommending how best to validate incoming email addresses as a universally-accepting application. Here is a very simple, high-level outline of that paper:
1. Understand why you are validating 2. The best way to validate is by sending message to user and let user send back a confirmation receipt 3. Simple minded regular expression and reject valid email addresses. 4. HTML5 specification is broken When reading the issue #4562 discussion of the past two weeks, I began to get the more extreme thought that we should say under #4, because the HTML5 specification is broken, we recommend against using <input type="email">, and instead recommend using <input type="text"> and not expect the browser to do any significant email address validation.
It seems like now is a good time to solicit ideas for this paper. If you have thoughts, please send them to the UA-Tech WG email list. I will collect them, and write a draft. Thoughts? —Jim DeLaHunt [1] 4.10.5.1.5 The Input Element, Email state (type=email), <https://html.spec.whatwg.org/#email-state-(type=email)> [2] "A valid email address" <https://html.spec.whatwg.org/#valid-e-mail-address> [3] Validating internationalized mail addresses in <input type="email"> <https://github.com/whatwg/html/issues/4562> [4] Comment by hsivonen about #4562 on 2024-04-30 08:39Z <https://github.com/whatwg/html/issues/4562#issuecomment-2084725431> and following comments [5] Comment by hsivonen about #4562 on 2024-05-08 06:49Z <https://github.com/whatwg/html/issues/4562#issuecomment-2099862952> [6] UA Technology WG, 2024-02-05 meeting notes, p.4 <https://community.icann.org/display/TUA/UA+Technology+WG?preview=/58720693/3...> -- --Jim DeLaHunt,jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant, Vancouver, Canada
Thank you Jim. Relevancy is decided by the leadership of these two groups. IMHO, the topics are extremely important to bring to the table. I will try and join the meeting later in the evening today [13 May 2024]. Gopal T V 0 9840121302 https://vidwan.inflibnet.ac.in/profile/57545 https://www.facebook.com/gopal.tadepalli ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Dr. T V Gopal Professor Department of Computer Science and Engineering College of Engineering Anna University Chennai - 600 025, INDIA Ph : (Off) 22351723 Extn. 3340 (Res) 24454753 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ________________________________ From: UA-Tech <ua-tech-bounces@icann.org> on behalf of Jim DeLaHunt via UA-Tech <ua-tech@icann.org> Sent: 13 May 2024 11:19 To: UA EAI WG <ua-eai@icann.org>; UA Technology Working Group <ua-tech@icann.org> Subject: [UA-Tech] Validating email addresses, and the HTML5 <input type="email"> spec UA EAI and Technology Working Group colleagues: I have a pair of topics to bring up, and both topics are relevant to both working groups. Topic 1. HTML5 <input type="email"> specification HTML includes a form field entity known as <input>. This takes a "type" attribute. One state for the "type" attribute is "email"[1]. When the page has a <input type="email"> field, the browser must check that the email address matches a syntax[2] which is limited to ASCII. Thus, by specification, this form field may not accept EAI email addresses. This is a problem for Universal Acceptance. John Levine opened an issue against the HTML 5 spec about this: Validating internationalized mail addresses in <input type="email"> #4562 [3]. Since it was opened 2019, discussion has started and stopped in this issue. On April 30, the discussion started again[4]. I have the impression that this is a particularly opportune moment. From the comments, influential people seem to be involved from both the Universal Acceptance and HTML implementor groups. People in these working groups who would like to move EAI in HTML forward, I suggest that you read through the recent discussion. Look for questions which the HTML folks are asking which have not received answers that satisfy them. Perhaps post suggested interventions on our WG lists, or suggest them to experts we know such as John Levine, or even (if you think you can do so productively) post in that issue thread. For example, [5] Can you tell me what kind of inputs are there that IDNA 2008 accepts but that UTS 46 in non-transitional mode either rejects or maps to different ASCII form than IDNA 2008? As an UTS 46 implementor, my current understanding is that there are none, but if there are some, it would be useful for me to know. [5] It seems to me that one useful function UASG could serve is to be a centre of expertise which is capable of giving reliable, well-thought-out answers to questions like this. Topic 2. A UASG White paper on Email Address Validation I encouraged the UA Technology working group to set a 2024 goal[5] of writing a paper recommending how best to validate incoming email addresses as a universally-accepting application. Here is a very simple, high-level outline of that paper: 1. Understand why you are validating 2. The best way to validate is by sending message to user and let user send back a confirmation receipt 3. Simple minded regular expression and reject valid email addresses. 4. HTML5 specification is broken When reading the issue #4562 discussion of the past two weeks, I began to get the more extreme thought that we should say under #4, because the HTML5 specification is broken, we recommend against using <input type="email">, and instead recommend using <input type="text"> and not expect the browser to do any significant email address validation. It seems like now is a good time to solicit ideas for this paper. If you have thoughts, please send them to the UA-Tech WG email list. I will collect them, and write a draft. Thoughts? —Jim DeLaHunt [1] 4.10.5.1.5 The Input Element, Email state (type=email), <https://html.spec.whatwg.org/#email-state-(type=email)><https://html.spec.whatwg.org/#email-state-(type=email)> [2] "A valid email address" <https://html.spec.whatwg.org/#valid-e-mail-address><https://html.spec.whatwg.org/#valid-e-mail-address> [3] Validating internationalized mail addresses in <input type="email"> <https://github.com/whatwg/html/issues/4562><https://github.com/whatwg/html/issues/4562> [4] Comment by hsivonen about #4562 on 2024-04-30 08:39Z <https://github.com/whatwg/html/issues/4562#issuecomment-2084725431><https://github.com/whatwg/html/issues/4562#issuecomment-2084725431> and following comments [5] Comment by hsivonen about #4562 on 2024-05-08 06:49Z <https://github.com/whatwg/html/issues/4562#issuecomment-2099862952><https://github.com/whatwg/html/issues/4562#issuecomment-2099862952> [6] UA Technology WG, 2024-02-05 meeting notes, p.4 <https://community.icann.org/display/TUA/UA+Technology+WG?preview=/58720693/322109590/Meeting%20notes%20UA%20Tech%20WG%2020240205.pdf><https://community.icann.org/display/TUA/UA+Technology+WG?preview=/58720693/322109590/Meeting%20notes%20UA%20Tech%20WG%2020240205.pdf> -- --Jim DeLaHunt, jdlh@jdlh.com<mailto:jdlh@jdlh.com> http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant, Vancouver, Canada
Jim, thank you for bringing an update concerning my nemesis, HTML5 input. As you know, I have talked endlessly about this being our absolute priority. It seems Arnt and John are holding the fort over at the Github repo, but if anybody else has the level of expertise required to help over there (it already moved past my knowledge level), please do so. This is vital. Best, On 13 May 2024 02:49, Jim DeLaHunt via UA-EAI wrote:
UA EAI and Technology Working Group colleagues:
I have a pair of topics to bring up, and both topics are relevant to both working groups.
Topic 1. *HTML5 <input type="email"> specification*
HTML includes a form field entity known as <input>. This takes a "type" attribute. One state for the "type" attribute is "email"[1]. When the page has a <input type="email"> field, the browser must check that the email address matches a syntax[2] which is limited to ASCII. Thus, by specification, this form field may not accept EAI email addresses.
This is a problem for Universal Acceptance.
John Levine opened an issue against the HTML 5 spec about this: *Validating internationalized mail addresses in <input type="email">* #4562 [3]. Since it was opened 2019, discussion has started and stopped in this issue. On April 30, the discussion started again[4]. I have the impression that this is a particularly opportune moment. From the comments, influential people seem to be involved from both the Universal Acceptance and HTML implementor groups.
People in these working groups who would like to move EAI in HTML forward, I suggest that you read through the recent discussion. Look for questions which the HTML folks are asking which have not received answers that satisfy them. Perhaps post suggested interventions on our WG lists, or suggest them to experts we know such as John Levine, or even (if you think you can do so productively) post in that issue thread.
For example, [5]
Can you tell me what kind of inputs are there that IDNA 2008 accepts but that UTS 46 /in non-transitional mode/ either rejects or maps to different ASCII form than IDNA 2008?
As an UTS 46 implementor, my current understanding is that there are none, but if there are some, it would be useful for me to know. [5]
It seems to me that one useful function UASG could serve is to be a centre of expertise which is capable of giving reliable, well-thought-out answers to questions like this.
Topic 2. *A UASG White paper on Email Address Validation*
I encouraged the UA Technology working group to set a 2024 goal[5] of writing a paper recommending how best to validate incoming email addresses as a universally-accepting application.
Here is a very simple, high-level outline of that paper:
1. Understand why you are validating 2. The best way to validate is by sending message to user and let user send back a confirmation receipt 3. Simple minded regular expression and reject valid email addresses. 4. HTML5 specification is broken When reading the issue #4562 discussion of the past two weeks, I began to get the more extreme thought that we should say under #4, because the HTML5 specification is broken, we recommend against using <input type="email">, and instead recommend using <input type="text"> and not expect the browser to do any significant email address validation.
It seems like now is a good time to solicit ideas for this paper. If you have thoughts, please send them to the UA-Tech WG email list. I will collect them, and write a draft.
Thoughts? —Jim DeLaHunt
[1] 4.10.5.1.5 The Input Element, Email state (type=email), <https://html.spec.whatwg.org/#email-state-(type=email)> [2] "A valid email address" <https://html.spec.whatwg.org/#valid-e-mail-address> [3] Validating internationalized mail addresses in <input type="email"> <https://github.com/whatwg/html/issues/4562> [4] Comment by hsivonen about #4562 on 2024-04-30 08:39Z <https://github.com/whatwg/html/issues/4562#issuecomment-2084725431> and following comments [5] Comment by hsivonen about #4562 on 2024-05-08 06:49Z <https://github.com/whatwg/html/issues/4562#issuecomment-2099862952> [6] UA Technology WG, 2024-02-05 meeting notes, p.4 <https://community.icann.org/display/TUA/UA+Technology+WG?preview=/58720693/3...>
-- --Jim DeLaHunt,jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant, Vancouver, Canada
_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Mark W. Datysgeld Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] ICANN GNSO Councilor
It appears that Mark Datysgeld via UA-EAI <mark@governanceprimer.com> said:
-=-=-=-=-=- -=-=-=-=-=-
Jim, thank you for bringing an update concerning my nemesis, HTML5 input. As you know, I have talked endlessly about this being our absolute priority.
It seems Arnt and John are holding the fort over at the Github repo, but if anybody else has the level of expertise required to help over there (it already moved past my knowledge level), please do so. This is vital.
Honestly, I wouldn't bother. For many years if you want to let people enter an EAI address, you use a regular text box, not an email box. In view of all of the bad ideas the HTML people have about the ways they want to forbid valid EAI addresses, I expect that we'll still tell people to use a regular text box to enter an EAI address. R's, John
I understand the point, John. However, at least in my experience doing UA outreach, the question I often end up being asked by people who are better informed is along the lines of "have you talked to the W3C?", and if the person is even better informed they will ask "have you talked to the WHATWG?". There is a significant expectation from the broader community that these issues will be fixed via standards instead of one website/software at a time with proper library implementation. It would also provide us with the ability to point to the WHATWG's greater notability and say "see, they accepted EAI/UA as legitimate" to other players we want to convince or pressure. So, yeah... I'm still of the opinion that this would give us significant returns. Best, On 13 May 2024 17:08, John Levine wrote:
It appears that Mark Datysgeld via UA-EAI<mark@governanceprimer.com> said:
-=-=-=-=-=- -=-=-=-=-=-
Jim, thank you for bringing an update concerning my nemesis, HTML5 input. As you know, I have talked endlessly about this being our absolute priority.
It seems Arnt and John are holding the fort over at the Github repo, but if anybody else has the level of expertise required to help over there (it already moved past my knowledge level), please do so. This is vital. Honestly, I wouldn't bother. For many years if you want to let people enter an EAI address, you use a regular text box, not an email box. In view of all of the bad ideas the HTML people have about the ways they want to forbid valid EAI addresses, I expect that we'll still tell people to use a regular text box to enter an EAI address.
R's, John -- Mark W. Datysgeld Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] ICANN GNSO Councilor
time with proper library implementation. It would also provide us with the ability to point to the WHATWG's greater notability and say "see, they accepted EAI/UA as legitimate" to other players we want to convince or pressure.
So, yeah... I'm still of the opinion that this would give us significant returns.
That would be great if they were willing to do that. At this point it is painfully clear that they think that they know better than anyone else what "should" be in an EAI address, and if real EAI addresses don't happen to match that, which many won't, well, too bad. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Hi, I’ve been out and about talking to people, and you’d be surprised: Some of them know their work and do it well. Some of those web people know the web better than I do. There are people whose entire job is contact forms. For such people, a contact form has three purposes: 1. Allow real people to do what they need to do. (If a customer wants to send a message to customer service, then the form’s primary purpose is to get the message there.) 2. Never send even a single message in response to bad guys. (There’s someone who goes around sending one of my addresses to contact forms, perhaps in the hope that I’ll visit spammers at home and bring an axe.) 3. Provide the site owner with actionable data. (If it’s a telco and the contact form is for customers, then add a required field, “your phone number” so customer service will know which customer it is.) Handling email syntax correctly isn’t on that list because it isn’t even nearly as important as those three. It’s not something they forgot because they’re ignorant. They know their work and they know their three big priorities. We’re not going to persuade anyone by insisting. In particular, if I ask the question “what’s most important to you, supporting all valid email addresses or rejecting input from bad guys?” the answer is that they prefer rejecting input, at once, without doubt. I know someone who has the email address<mailto:> #@example.com<mailto:#@example.com> (except that it’s a different domain). That address has very little chance of being accepted by a contact form. Is that OK? I keep my opinion to myself, because I’m writing this at work. My job is to further UA and I’d rather not digress into #@. He’s a nice guy and he has written software that helps us all, but he has a rare and unusual address, not one of my top-50 problems. Instead I’ll present an argument that #@example.com<mailto:#@example.com> is an invalid address: “Most people will think it’s invalid or be puzzled by the address”. You all agree that most people will think so? Yes? There’s a kind of mentally agreed syntax for email addresses, and # isn’t allowed in that. Building on that, “if a telco wants to assess an address and guess whether it’s from a prospective customer or not, then #@ is a sign that it isn’t”. Prospective customers have addresses that match the general public’s general idea of an email address. The W3C has a fairly good regex for ASCII email addresses. It’s not perfect, but it’s not bad. If the general public considers an address valid, then that regex does, too, and the regex doesn’t accept very much else. They’ve been trying to extend it for Unicode, and not getting anywhere. I now think I understand why: a regex can’t provide the same good match in the case of Unicode. A regex will either be too strict or surprisingly lax, it won’t provide the same sort of fit. (The github issue that started this discussion is IMO doomed to repeat in cycles.) By coincidence, there’s also unhappiness in the IETF about the Unicode address syntax. That held up publication of RFC 9553 for a little while. I think the time is right to get an RFC published that * satisfies the IETFers who think that 1*UTF8CHAR is too lax for email localparts * matches the general notions of the people who validate email addresses for a living * can be referenced in a W3C document such as that for type=email and * accommodates the kinds of addresses Xgenplus and Coremail hand out to customers. I still don’t have travel permission to the next IETF meeting, in July, but if I get it, I’ll submit a draft before the event and will be talking as smoothly as I can about it. I know roughly what I want to say, there’s some doubt about particular details (e.g. concerning ASCII digits in non-ASCII email addresses). Arnt
Thanks, Arnt, this is clear and helpful. I understand the situation much better. LMK if you don’t get the travel budget, I will help look for someone who can represent on your behalf. That would be very unfortunate (and I can’t be sure of finding such a person) so don’t take that as an excuse for your management not approving the travel. /marksv From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of Arnt Gulbrandsen via UA-EAI Sent: Wednesday, May 22, 2024 2:02 AM To: UA EAI WG <ua-eai@icann.org>; UA Technology Working Group <ua-tech@icann.org> Subject: [EXTERNAL] Re: [UA-EAI] Validating email addresses, and the HTML5 <input type="email"> spec Hi, I’ve been out and about talking to people, and you’d be surprised: Some of them know their work and do it well. Some of those web people know the web better than I do. There are people whose entire job is contact forms. For such people, a contact form has three purposes: 1. Allow real people to do what they need to do. (If a customer wants to send a message to customer service, then the form’s primary purpose is to get the message there.) 2. Never send even a single message in response to bad guys. (There’s someone who goes around sending one of my addresses to contact forms, perhaps in the hope that I’ll visit spammers at home and bring an axe.) 3. Provide the site owner with actionable data. (If it’s a telco and the contact form is for customers, then add a required field, “your phone number” so customer service will know which customer it is.) Handling email syntax correctly isn’t on that list because it isn’t even nearly as important as those three. It’s not something they forgot because they’re ignorant. They know their work and they know their three big priorities. We’re not going to persuade anyone by insisting. In particular, if I ask the question “what’s most important to you, supporting all valid email addresses or rejecting input from bad guys?” the answer is that they prefer rejecting input, at once, without doubt. I know someone who has the email address #@example.com<mailto:#@example.com> (except that it’s a different domain). That address has very little chance of being accepted by a contact form. Is that OK? I keep my opinion to myself, because I’m writing this at work. My job is to further UA and I’d rather not digress into #@. He’s a nice guy and he has written software that helps us all, but he has a rare and unusual address, not one of my top-50 problems. Instead I’ll present an argument that #@example.com<mailto:#@example.com> is an invalid address: “Most people will think it’s invalid or be puzzled by the address”. You all agree that most people will think so? Yes? There’s a kind of mentally agreed syntax for email addresses, and # isn’t allowed in that. Building on that, “if a telco wants to assess an address and guess whether it’s from a prospective customer or not, then #@ is a sign that it isn’t”. Prospective customers have addresses that match the general public’s general idea of an email address. The W3C has a fairly good regex for ASCII email addresses. It’s not perfect, but it’s not bad. If the general public considers an address valid, then that regex does, too, and the regex doesn’t accept very much else. They’ve been trying to extend it for Unicode, and not getting anywhere. I now think I understand why: a regex can’t provide the same good match in the case of Unicode. A regex will either be too strict or surprisingly lax, it won’t provide the same sort of fit. (The github issue that started this discussion is IMO doomed to repeat in cycles.) By coincidence, there’s also unhappiness in the IETF about the Unicode address syntax. That held up publication of RFC 9553 for a little while. I think the time is right to get an RFC published that * satisfies the IETFers who think that 1*UTF8CHAR is too lax for email localparts * matches the general notions of the people who validate email addresses for a living * can be referenced in a W3C document such as that for type=email and * accommodates the kinds of addresses Xgenplus and Coremail hand out to customers. I still don’t have travel permission to the next IETF meeting, in July, but if I get it, I’ll submit a draft before the event and will be talking as smoothly as I can about it. I know roughly what I want to say, there’s some doubt about particular details (e.g. concerning ASCII digits in non-ASCII email addresses). Arnt
Hi Arnt, Thanks for your feedback, this is very helpful to get a better understanding of the reasons that lead us where we are right now. I've come to the same conclusion a while ago and I've also been thinking that a new RFC that would narrow the choices for the local part would be really helpful. I'll definitively read your draft whenever it comes out, or you can send me a preliminary version any time for review. Julien On 22/05/2024 05:02, Arnt Gulbrandsen via UA-Tech wrote:
Hi,
I’ve been out and about talking to people, and you’d be surprised: Some of them know their work and do it well. Some of those web people know the web better than I do.
There are people whose entire job is contact forms. For such people, a contact form has three purposes:
1. Allow real people to do what they need to do. (If a customer wants to send a message to customer service, then the form’s primary purpose is to get the message there.) 2. Never send even a single message in response to bad guys. (There’s someone who goes around sending one of my addresses to contact forms, perhaps in the hope that I’ll visit spammers at home and bring an axe.) 3. Provide the site owner with actionable data. (If it’s a telco and the contact form is for customers, then add a required field, “your phone number” so customer service will know which customer it is.)
Handling email syntax correctly isn’t on that list because it isn’t even nearly as important as those three. It’s not something they forgot because they’re ignorant. They know their work and they know their three big priorities. We’re not going to persuade anyone by insisting.
In particular, if I ask the question “what’s most important to you, supporting all valid email addresses or rejecting input from bad guys?” the answer is that they prefer rejecting input, at once, without doubt.
I know someone who has the email address<mailto:>#@example.com <mailto:#@example.com> (except that it’s a different domain). That address has very little chance of being accepted by a contact form. Is that OK? I keep my opinion to myself, because I’m writing this at work. My job is to further UA and I’d rather not digress into #@. He’s a nice guy and he has written software that helps us all, but he has a rare and unusual address, not one of my top-50 problems.
Instead I’ll present an argument that #@example.com <mailto:#@example.com> is an invalid address: “Most people will think it’s invalid or be puzzled by the address”. You all agree that most people will think so? Yes? There’s a kind of mentally agreed syntax for email addresses, and # isn’t allowed in that. Building on that, “if a telco wants to assess an address and guess whether it’s from a prospective customer or not, then #@ is a sign that it isn’t”. Prospective customers have addresses that match the general public’s general idea of an email address.
The W3C has a fairly good regex for ASCII email addresses. It’s not perfect, but it’s not bad. If the general public considers an address valid, then that regex does, too, and the regex doesn’t accept very much else. They’ve been trying to extend it for Unicode, and not getting anywhere. I now think I understand why: a regex can’t provide the same good match in the case of Unicode. A regex will either be too strict or surprisingly lax, it won’t provide the same sort of fit. (The github issue that started this discussion is IMO doomed to repeat in cycles.)
By coincidence, there’s also unhappiness in the IETF about the Unicode address syntax. That held up publication of RFC 9553 for a little while.
I think the time is right to get an RFC published that
* satisfies the IETFers who think that 1*UTF8CHAR is too lax for email localparts * matches the general notions of the people who validate email addresses for a living * can be referenced in a W3C document such as that for type=email and * accommodates the kinds of addresses Xgenplus and Coremail hand out to customers.
I still don’t have travel permission to the next IETF meeting, in July, but if I get it, I’ll submit a draft before the event and will be talking as smoothly as I can about it. I know roughly what I want to say, there’s some doubt about particular details (e.g. concerning ASCII digits in non-ASCII email addresses).
Arnt
_______________________________________________ UA-Tech mailing list UA-Tech@icann.org https://mm.icann.org/mailman/listinfo/ua-tech _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (8)
-
Arnt Gulbrandsen -
gopal -
Jim DeLaHunt -
John Levine -
John R. Levine -
Julien Bernard -
Mark Datysgeld -
Mark Svancarek (CELA)