3 ms·

The article points at the regexp but fails to point at what the standard says about how that's supposed to be used. https://www.w3.org/TR/html5/forms.html#e-ma

The article points at the regexp but fails to point at what the standard says about how that's supposed to be used. https://www.w3.org/TR/html5/forms.html#e-mail-state-(type=email) https://www.w3.org/TR/html5/forms.html#e-mail-state-(type=em... User agents may transform the value for display and editing; in particular, user agents should convert punycode in the value to IDN in the display and vice versa. ie you're supposed to be able to type human-readable addresses but they're converted to punycode for submission, because that's what the server will need in order to use the address. The regexp is used to validate the punycode not what the user types. Which isn't to say this isn't a thorny problem; more discussion of the issue here https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489 https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489

mike-cardwell 10y ago
"they're converted to punycode for submission, because that's what the server will need in order to use the address" I disagree with that. Neither the client nor the server need to know anything about punycode. The only time punycode is required is at the very last moment when it comes time to actually send an email to that address. Whether it's the email sending library or the mail server it's self, it doesn't matter. A user should be able to type "person@ü.example.com" into a form. I should receive "person@ü.example.com" on the server side. I should save "person@ü.example.com" to the database. I should be able to send "person@ü.example.com" back to the browser for display, and I should be able to pass "person@ü.example.com" as the To address to my mail sending library. Punycode is an implementation detail that I shouldn't need to think about.
- bazzargh 10y ago
  That's a perfectly reasonable objection, and answered to an extent over here https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489#c18 https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489#c18 tl;dr: "backwards compatibility" I'd also agree that my code should be able to handle unicode, for a different reason: I never trust validation by a browser (old clients, bad clients, malicious clients)
- mnarayan01 10y ago
  Having both "person@ü.example.com" and "person@xn--tda.example.com" be both valid and equivalent makes just abstracting over it more problematic.

mike-cardwell 10y ago

"they're converted to punycode for submission, because that's what the server will need in order to use the address" I disagree with that. Neither the client nor the server need to know anything about punycode. The only time punycode is required is at the very last moment when it comes time to actually send an email to that address. Whether it's the email sending library or the mail server it's self, it doesn't matter. A user should be able to type "person@ü.example.com" into a form. I should receive "person@ü.example.com" on the server side. I should save "person@ü.example.com" to the database. I should be able to send "person@ü.example.com" back to the browser for display, and I should be able to pass "person@ü.example.com" as the To address to my mail sending library. Punycode is an implementation detail that I shouldn't need to think about.

bazzargh 10y ago
That's a perfectly reasonable objection, and answered to an extent over here https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489#c18 https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489#c18 tl;dr: "backwards compatibility" I'd also agree that my code should be able to handle unicode, for a different reason: I never trust validation by a browser (old clients, bad clients, malicious clients)
mnarayan01 10y ago
Having both "person@ü.example.com" and "person@xn--tda.example.com" be both valid and equivalent makes just abstracting over it more problematic.