Dear all, We have RTL problem in LTR world already. Try this. F.E. / I will use ASCII just to make a point> com.gmail@stojicevic.dusan I send one email to this mail address and it gone "as usual". After a minute, I've got a massage in attach. So, consumer mail clients are prepared with the LTR rule: that on the left side from "@" sign is name, and on the right side is domain name. But, they don't check this rule. I presume that in the RTL world, consumer mail clients do the same - with RTL rule. The real question is - should mail clients check this? Regards, Dušan On 24.2.2015 2:17, Mark Svancarek wrote:
I’ve seen some discussion activity at w3.org (as recently as last December https://www.w3.org/International/wiki/EAI_Address_Issues ) but it doesn’t seem actionable. I think we’ll need to use this group to get all similar issues clarified and make them usable by developers.
*From:*ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Don Hollander *Sent:* Monday, February 23, 2015 4:46 PM *To:* Brent London *Cc:* ua-discuss@icann.org; Edmon Chung *Subject:* Re: [UA-discuss] Regarding "RTL"
Thanks Brent, Alireza & Edmon.
This is a very interesting question of the approach that a software supplier might take.
I have two questions:
1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one?
2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address?
I think it’s very interesting.
Don
On 24/02/2015, at 1:18 pm, Brent London <brentlondon@google.com <mailto:brentlondon@google.com>> wrote:
It becomes problematic, as Edmon mentioned, when there are dots in both sides. It's especially confusing if both sides contain a string that plausibly could be a TLD:
customer.care@شزذ.يثب <mailto:customer.care@%D8%B4%D8%B2%D8%B0.%D9%8A%D8%AB%D8%A8>
Brent London
brentlondon@google.com <mailto:brentlondon@google.com>
+1 650-214-5206
On Sun, Feb 22, 2015 at 5:46 AM, Alireza Saleh <saleh+ua@nic.ir <mailto:saleh+ua@nic.ir>> wrote:
There is no problem as long as the usernames starts and ends with a character with a property of AL (Arabic Letter), R (Right to left) or L (Left to right) otherwise in a LTR context it may jump around @ sign and make the address unreadable. The email address may also become unreadable in LTR context If the username part starts with L and ends with AL like :
testمثال@مثال.تست <mailto:test%D9%85%D8%AB%D8%A7%D9%84@%D9%85%D8%AB%D8%A7%D9%84.%D8%AA%D8%B3%D8%AA>
the red part is username.
-Alireza
On Feb 22, 2015, at 11! :47 AM, Edmon Chung <edmon@registry.asia <mailto:edmon@registry.asia>> wrote:
What about where the username part contains a dot or other separators? Is there a difference between “.” And “-“ or “_”?
tld.sld@name.user <mailto:tld.sld@name.user> ?
tld.sld@name-user <mailto:tld.sld@name-user> / tld.sld@user-name <mailto:tld.sld@user-name> ?
etc.?
Edmon
*From:*ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Alireza Saleh *Sent:* Sunday, February 22, 2015 4:07 PM *To:* Edmon Chung *Cc:* ua-discuss@icann.org <mailto:ua-discuss@icann.org> *Subject:* Re: [UA-discuss] Regarding "RTL"
This is very interesting question. I’ve also thought about it before. This is a new topic and there is no similar experiences. I don’t have exact answer to this question but overall I think people mainly prefer the RTL version with right alignement. however the bidi property of @ allows its usage in the middle of RTL texts without creating any confusions unlike <http://>.
نام@مثال.آزمایشی <mailto:%D9%86%D8%A7%D9%85@xn--mgbh0fb.xn--hgbk6aj7f53bba>
TLD.SLD@NAME <mailto:TLD.SLD@NAME>
__
__
_-Alireza_
__
__
__
_On Feb 22, 2015, at 4:01 AM, Edmon Chung <edmon@registry.asia <mailto:edmon@registry.asia>> wrote:_
_That applies to email (EAI) addresses as well I suppose?_
_Which Brent has been bringing up._
_So, within a RTL ! context (e.g. if the user interface or other elements are RTL) one should expect_
__
_tld.domain@name.user:mailto <mailto:tld.domain@name.user:mailto>_
__
_Is that correct Alireza?_
__
_Edmon_
__
__
__
*_From:_*_ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Alireza Saleh *Sent:* Sunday, February 22, 2015 2:54 AM *To:* Mark Svancarek *Cc:* ua-discuss@icann.org <mailto:ua-discuss@icann.org> *Subject:* Re: [UA-discuss] Regarding "RTL"_
__
_Dear Mark, _
__
_Just a quick note about your question, it is expected the label starts from the right side of the address baar, and from right to left. So the main issue would be the alignment. Natively it should look like:_
__
_com.microsoft.www://http_
__
_-Alireza_
__
__
__
_On Feb 20, 2015, at 10:35 PM, Mark Svancarek <marksv@microsoft.com <mailto:marksv@microsoft.com>> wrote:_
_
_
_Hi, I had some questions regarding my recent usage of the term “RTL”. By this I mean “right to left”, a characteristic of Arabic and Hebrew. At Microsoft we also call this “bidi” (bidirectional)._
__
_Here’s a discussion regarding RTL. (I’ve also attached a much more detailed explanation, which includes Microsoft’s recommendations, but it’s in PowerPoint. Hopefully you already! use a compatible viewer.)_
_Bidi display of IRIs (URLs/URIs)_
_Bidirectional display of IRIs (an IRI with some Right-To-Left characters, eg: Arabic) has some odd quirks. There’s an IETF WG working on creating an IRI RFC. It’d be nice if we could help ensure that there were reasonable standards for the display of bidi IRIs. The existing IRI drafts suggest using the Unicode Bidi Algorithm to display IRIs, but that has some problems._
User and government feedback indicates that our current behavior is a bit unexpected. Currently we have some odd quirks about the display of Bidi IRIs in Microsoft. This is just an example, other places may have different odd quirks.
*Logical Order*
*IE with LTR context*
*IE with RTL context*
http://www.microsoft.com <http://www.microsoft.com/>
http://www.microsoft.com <http://www.microsoft.com/>
http://www.microsoft.com <http://www.microsoft.com/>
http://اا1اا.بب2بب.ةة3ةة <http://xn--1-ymcaba.xn--2-0mcaba.xn--3-2mcaba/>
http://اا1اا.بب2بب.ةة3ةة <http://xn--1-ymcaba.xn--2-0mcaba.xn--3-2mcaba/>
http://اا1اا.بب2بب.ةة3ةة <http://xn--1-ymcaba.xn--2-0mcaba.xn--3-2mcaba/>
http://a1a.اا2اا.بب3بب.d4d <http://a1a.xn--2-ymcaba.xn--3-0mcaba.d4d/>
http://a1a.اا2اا.بب3بب.d4d <http://a1a.xn--2-ymcaba.xn--3-0mcaba.d4d/>
http://a1a.اا2اا.بب3بب.d4d <http://a1a.xn--2-ymcaba.xn--3-0mcaba.d4d/>
http://*اا*1*اا*.b2b.c3c.بب4بب <http://xn--1-ymcaba.b2b.c3c.xn--4-0mcaba/>
http://اا1اا.b2b.c3c.بب4بب <http://xn--1-ymcaba.b2b.c3c.xn--4-0mcaba/>
http://اا1اا.b2b.c3c.بب4بب <http://xn--1-ymcaba.b2b.c3c.xn--4-0mcaba/>
As we can see, the order of some of the elements may seem counter-intuitive. The highlighted sections start in one direction, but then jump or rearrange direction so that the elements don’t follow the same order.
The Unicode Bidi algorithm has the idea that some characters aren’t inherently RTL or LTR. In! stead they take on the properties of the characters surrounding them. This is why some pairs get “flipped” in the rendered order.
*User Expectations*
Limited usability investigations have demonstrated that users expect IRIs and other paths to be in the form of an ordered list. The ! “separators” of the various fields vary, but the entire unit is treated as a list. E.g.: http://www.microsoft.com <http://www.microsoft.com/> is a list { “http”, “www”, “microsoft”, “com” }. Users expect it to be rendered “in order” with the first element, then second, etc.
What is a bit unclear is exactly which direction the users expect the lists! to be rendered in. There seem to be 2 main options for what users expect:
·Always render the path elements from Left to Right (e.g. “www.microsoft.com <http://www.microsoft.com/>”) regardless of the script.
·Always render the path elements from Right to Left in a Bidi context (application), e.g.: “com.microsoft.www//:http”, EVEN FOR ASCII IRIs.
We need to confirm what the user expectations are for Bidi Display, and ensure that any edits to IETF IRI standards match those expectations.
<BiDiIRIsUC1.pptx>
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com