Re:The Sad State of HTML Email Input Fields and IDNs
by bazzargh on Sunday October 23, 2016 @08:40AM
(#12773291)
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 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)
Re:The Sad State of HTML Email Input Fields and IDNs
by mnarayan01 on Sunday October 23, 2016 @04:21PM
(#12775235)
Having both "person@ü.example.com" and "[email protected]" be both valid and equivalent makes just abstracting over it more problematic.
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.