[UA-EAI] [Ext] RE: arabic1.arabic2 at arabic3.arabic4

[Stuart Stuple]

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 at apple.com [mailto:borokhov at apple.com] 
Sent: Wednesday, April 5, 2017 11:54 PM
To: "Martin J. Dürst" <duerst at it.aoyama.ac.jp>
Cc: Stuart Stuple <stuartst at microsoft.com>; Raed Al-Fayez <rfayez at citc.gov.sa>; Don Hollander <don.hollander at icann.org>; Andrew Sullivan <ajs at anvilwalrusden.com>; ua-eai at icann.org
Subject: Re: [UA-EAI] [Ext] RE: arabic1.arabic2 at arabic3.arabic4


> 5 апр. 2017 г., в 22.19, Martin J. Dürst <duerst at 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 at 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 at 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 at 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 at CIBARA.com is a left-to-right container.
> 
> .com at 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