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

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

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.