Heck my name is ascii compatible but it isn't available.
Let's say the Internet had been invented in Japan instead of the US. How would you feel if people told you that you had to write your name in katakana everywhere? As another commenter mentioned, internationalization is here to stay, and if we want to expand to the next few billion users it's even more important. FWIW internationalized usernames are already available on a number of non-email platforms (Weibo as a prime example). For email to remain competitive, it's important to keep up in the internationalization space.
(checking now just to make sure, I see that weibo allows three options for logging in: an email address (not internationalized), an account number (not internationalized), and a phone number (not internationalized))
Sure, it's understandable as email is an old and a widely used protocol, so changes are difficult to push through. But it's not acceptable, and it's not "relatively trivial".
There's no risk of "breaking the web", since the web is already broken for billions of people.
If email can't be made to support UTF-8, then email should be replaced altogether.
The problem (one problem?) is legacy devices. At the time most phones and possibly even some browsers had limited input to URL fields in ascii only. The keyboard they'd show when you when to enter a URL didn't provide the input methods for non-ascii text.
So, having a non-ascii domain would have only lost you customers. Or made it more confusing. As in do I go to mitsubishi.com or 三菱.com? (三菱.jp is registered but googling for site:三菱.jp brings up zero hits)
I'm not saying I'm against non-ascii email names. I'm just suggesting it's not likely to change much anytime soon. Just a guess
That sounds convenient.
/s
Question: What do you guys think it'd take to get the other N% of email providers, clients, servers, and whatnot onboard?
Is this an ipV6-like situation?
Almost all email moves between only a handful of companies. Google, Microsoft, Yahoo, Facebook, Apple. Between them they dominate the landscape. It only takes a handful of engineers and product managers at these companies to decide "let's do this" and pretty quickly such email addresses can become a reality for at least person to person mail.
Of course for them to become usable for signing up to websites, mailing lists etc, will take much longer. But people may not mind having two email addresses if they can put one on their business card.
According to the standard: "If the message cannot be forwarded because the next-hop system cannot accept the extension, it MUST be rejected or a non-delivery message MUST be generated and sent."
Google could preserve a backup ASCII email for all UTF-8 email addresses, which would be used in the case the recipient doesn't support SMTPUTF8.
Of course, I don't know if Google has plans to support this.
That's pretty naive. You need to step outside your comfy bubble.
Out of all the small businesses on the internet, how many of them are still running an email server under someone's desk?
And not to mention, what about all the client-side javascript out there that parses email addresses on web forms? Think about all those throw-away regexes to parse email forms on websites. I've seen a lot of them break just on these new TLDs - and they are ASCII!
Does anyone know how canonicalization is handled? Does every mail program need to know how to precompose/decompose etc? How do you protect against impersonation using look-alike letters?
This is, as far as I know, not yet a solved problem even at the domain name level[0], and it's likely to open a whole new can of worms at the account level.
There's three reasons why text might appear blocked out: corrupt data (we'll ignore this), data in formats the text renderer doesn't "understand," and data in formats it DOES understand but doesn't have the prerequisite fonts to draw.
Typically when it is a lack-of-fonts issue you can copy it back out and paste it elsewhere and it will work fine as the data's consistency is kept.
But when the text renderer literally doesn't understand the underlying data (either because it is misconfigured or doesn't fully support UNICODE), when you try to copy back out you'll often get a corrupted version of the underlying data which cannot be reused (e.g. a 2 byte character treated as two 1 byte characters).
That issue is less and less common in 2014, as MOST text renderers support 2 byte UNICODE characters even if they won't have the fonts to render the full sets. But around the year 2000, it was fairly common to run across a text editor which under-the-hood was just ASCII and it would corrupt irrecoverably UNICODE inputed.
Or worse, somebody is trying to give me their address over the phone.
Here's an example: Try to figure out how to type:
宮本茂@任天堂株式会社.com
Here's another I'm pretty certain I can't figure out with a virtual keyboard.
প্রিয়াংশু.চ্যাটার্জী@बॉलीवुड.com
How about mixed languages? Like the case of a foreign worker assigned to another foreign department in yet a third country.
김기덕@बॉलीवुड.ประเทศไทย.com
I'm not going to tell you what languages these are in. Just pretend you were handed these on business cards or saw them on a slide deck at a conference and can't get a digital copy. Let me know how it goes.
If my address was a word in hebrew, or something people can pronounce and write it would actually help, saving time and avoiding misspellings.
But this should be an alias, or it should be very easy to create one, I already have my email for some years, I don't want to create a new one and handle two accounts unnecessarily.
Also lets say someone creates his email address in his native language, so it is easier to give his address to his friends at school, later in life he wants to give his address to a VC from US he met. even if he gives a business card with his email printed in clear letters, this western person can't even spell or even type, unless he could copy/paste the address he won't be able to send him an email.
Please use only letters (a-z), numbers, and periods.
EDIT: I guess I missed this crucial sentence Of course, this is just a first step and there’s still a ways to go. In the future, we want to make it possible for you to use them to create Gmail accounts.