Excellent to hear. That was my expectation but as I looked around, I found no colleagues taking advantage of the display name functionality. For me, one of the most compelling examples for EAIs are tables with entries for common names in cultures with the given name, English use name (if appropriate), display name, and then email name. My perspective is that Universal Acceptance means that the user gets to decide how these are consistent or diverges (rather than technological limitations). -Stuart -----Original Message----- From: borokhov@apple.com [mailto:borokhov@apple.com] Sent: Wednesday, April 5, 2017 11:54 PM To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp> Cc: Stuart Stuple <stuartst@microsoft.com>; Raed Al-Fayez <rfayez@citc.gov.sa>; Don Hollander <don.hollander@icann.org>; Andrew Sullivan <ajs@anvilwalrusden.com>; ua-eai@icann.org Subject: Re: [UA-EAI] [Ext] RE: arabic1.arabic2@arabic3.arabic4
5 апр. 2017 г., в 22.19, Martin J. Dürst <duerst@it.aoyama.ac.jp> написал(а):
It's also interesting (and important) to understand what restrictions are already enforced or implied on the display name. As I wrote the above paragraph, I realized that everyone who has a name using the Latin script with a character not in the English alphabet tends to use the "right" character in their email display name (so Martin's ü). But I've never seen any character outside of CP1252 (with the exception of one group alias with Emoji).
I'm in Japan, and have seen/am seeing a lot of people's display names in Japanese.
Display names absolutely are used internationally today with all scripts. In Russia many (most?) people will use their Cyrillic names. I’ve seen plenty of Arabic and Hebrew as well. As long as you have a modern-enough client, this stuff just works. I do remember the AOL days though when instead you would see ?=koi8-r;lkajse instead – good times. ==== I think it is very important in these discussions to keep the distinction between visual and logical order in mind. Martin has correctly pointed this out in his replies to this thread.
we have chacked it on our email server . if some send mail to arabic-user@ascii-domain. then our email server detect it same but display reverse.
as pointed out by both Raed and Marin, there is no „detecting“ going on. The logical order is fixed, no matter how it is displayed.
The problem is that many email addresses are of the form first-local-part.second-local-part@label.secondlabel. So let's start with the simple case:
[some ASCII characters]@arabic-string.com
now, the bidi algorithm is probably going to do something like this (at least in my reading it should):
LTR@RTL.com
Well, yes, in an LTR context (e.g. an English text). In an Arabic text (RTL context), it will be com.arabic-string@[some ASCII characters]. And in all cases, the "RTL" part will have the characters in RTL order, but that's the bit everybody is happy with (as long as there are only RTL characters in that part).
One minor nitpick: since the context resets at paragraph boundaries, you could have a document that’s entirely in Arabic, but because the address is on its own line and starts with ASCII, you’d get the LTR layout even in what could be easily construed as an RTL „context“.
And the other aspect is directionality of the container.
ascii@CIBARA.com is a left-to-right container.
.com@CIBARAascii is a right-to-left container (I think -- might be .comCIBARAascii@)
Martin got this right. Took me a second to get what CIBARA meant – I think this is a really confusing way to present it. Cheers, Paul