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://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب 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. Instead 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 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.
Dear Mark, All, There is a community led effort called the Task Force on Arabic script IDNs (TF-AIDN) <https://community.icann.org/display/MES/Task+Force+on+Arabic+Script+IDNs> whom we can reach out to get the relevant feedback on such issues, as Universal Acceptance is one of the objectives for this task force. We have a few members from the task force signed on this list but I can assist coordinating with TF-AIDN, in case there are specific queries from this group. Regards, Sarmad From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek Sent: Saturday, February 21, 2015 12:05 AM To: ua-discuss@icann.org Subject: [UA-discuss] Regarding "RTL" 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:// <http://اا1اا.بب2بب.ةة3ةة> اا1اا.بب2بب.ةة3ةة http:// <http://اا1اا.بب2بب.ةة3ةة> اا1اا.بب2بب.ةة3ةة <http://اا1اا.بب2بب.ةة3ةة> http://اا1اا.بب2بب.ةة3ةة http://a1a. <http://a1a.اا2اا.بب3بب.d4d> اا2اا.بب3بب.d4d http://a1a. <http://a1a.اا2اا.بب3بب.d4d> اا2اا.بب3بب.d4d <http://a1a.اا2اا.بب3بب.d4d> http://a1a.اا2اا.بب3بب.d4d http:// <http://اا1اا.b2b.c3c.بب4بب> اا1اا.b2b.c3c.بب4بب http:// <http://اا1اا.b2b.c3c.بب4بب> اا1اا.b2b.c3c.بب4بب <http://اا1اا.b2b.c3c.بب4بب> http://اا1اا.b2b.c3c.بب4بب 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. Instead 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 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.
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> 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://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب
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. Instead 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 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”) 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>
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 Is that correct Alireza? Edmon From: 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 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://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://اا1اا.بب2بب.ةة3ةة <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://a1a.اا2اا.بب3بب.d4d <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/> http://اا1اا.b2b.c3c.بب4بب 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. Instead 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. “ <http://www.microsoft.com/> 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>
The expectation is also that the OS, mail agents and smtp servers properly understand RTL or LTR context and interpret the @ correctly in order to effect proper mail routing. iirc, a lot depends upon the "first touch" system which converts the address into a standard ascii-based string. If it gets it wrong, there is nothing downstream systems can do, and the mail is effectively lost. Ram ------------------- Ram Mohan EVP & CTO +1.215.431.0958 skype: gliderpilot30 On Feb 22, 2015 6:03 AM, "Edmon Chung" <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
Is that correct Alireza?
Edmon
*From:* 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 *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> 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://اا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. Instead 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 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”) 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>
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://>. نام@مثال.آزمایشی TLD.SLD@NAME -Alireza On Feb 22, 2015, at 4:01 AM, Edmon Chung <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
Is that correct Alireza?
Edmon
From: 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 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> 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://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب
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. Instead 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 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”) 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>
What about where the username part contains a dot or other separators? Is there a difference between “.” And “-“ or “_”? 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] On Behalf Of Alireza Saleh Sent: Sunday, February 22, 2015 4:07 PM To: Edmon Chung Cc: 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:???@????.???????> @مثال.آزمایشی 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: <mailto:ua-discuss-bounces@icann.org> 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: <mailto:ua-discuss@icann.org> 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> com.microsoft.www://http -Alireza On Feb 20, 2015, at 10:35 PM, Mark Svancarek < <mailto:marksv@microsoft.com> 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://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://اا1اا.بب2بب.ةة3ةة <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://a1a.اا2اا.بب3بب.d4d <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/> http://اا1اا.b2b.c3c.بب4بب 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. Instead 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. “ <http://www.microsoft.com/> 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>
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مثال@مثال.تست the red part is username. -Alireza On Feb 22, 2015, at 11:47 AM, Edmon Chung <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 ? tld.sld@name-user / tld.sld@user-name ? etc.?
Edmon
From: 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 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://>.
نام@مثال.آزمایشی TLD.SLD@NAME
-Alireza
On Feb 22, 2015, at 4:01 AM, Edmon Chung <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
Is that correct Alireza?
Edmon
From: 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 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> 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://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب
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. Instead 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 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”) 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>
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@شزذ.يثب Brent London brentlondon@google.com +1 650-214-5206 On Sun, Feb 22, 2015 at 5:46 AM, Alireza Saleh <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مثال@مثال.تست
the red part is username.
-Alireza
On Feb 22, 2015, at 11:47 AM, Edmon Chung <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 ? tld.sld@name-user / tld.sld@user-name ? etc.?
Edmon
*From:* ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org <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 *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://>.
نام@مثال.آزمایشی <%D9%86%D8%A7%D9%85@xn--mgbh0fb.xn--hgbk6aj7f53bba> TLD.SLD@NAME
-Alireza
On Feb 22, 2015, at 4:01 AM, Edmon Chung <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
Is that correct Alireza?
Edmon
*From:* ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org <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 *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> 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://اا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. Instead 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 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”) 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>
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> 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@شزذ.يثب
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مثال@مثال.تست
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 <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 <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>
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@شزذ.يثب> 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مثال@مثال.تست> 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>
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
1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one?
I think the appropriate forum for this would be m3aawg <https://www.maawg.org/>, although I'm unsure of whether it's actually been raised there yet.
2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address?
Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From header. See the first expandable section of this <https://support.google.com/mail/answer/1366858?hl=en> article for more info. Gmail ignores dots in the usernames of gmail.com addresses, which is doable because Gmail controls the gmail.com namespace. So hello.world@gmail.com goes to the same user as helloworld@gmail.com. We can't, however, do that for other domains. For example, helloworld@outlook.com and hello.world@outlook.com are different users.
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.
I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. Brent London brentlondon@google.com +1 650-214-5206 On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs> wrote:
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 <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> 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@شزذ.يثب
Brent London
brentlondon@google.com
+1 650-214-5206
On Sun, Feb 22, 2015 at 5:46 AM, Alireza Saleh <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مثال@مثال.تست
the red part is username.
-Alireza
On Feb 22, 2015, at 11! :47 AM, Edmon Chung <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 ?
tld.sld@name-user / tld.sld@user-name ?
etc.?
Edmon
*From:* ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org <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 *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://>.
نام@مثال.آزمایشی <%D9%86%D8%A7%D9%85@xn--mgbh0fb.xn--hgbk6aj7f53bba>
TLD.SLD@NAME
*-Alireza*
*On Feb 22, 2015, at 4:01 AM, Edmon Chung <edmon@registry.asia <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 <tld.domain@name.user:mailto>*
*Is that correct Alireza?*
*Edmon*
*From:*
* ua-discuss-bounces@icann.org <ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org <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 <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 <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://اا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/>
...
[Message clipped]
---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com> To: dusan@dukes.in.rs Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently:
com.gmail@dusan.stojicevic
Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found
----- Original message -----
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=;
b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V
X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F
NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR
j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i
uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs. [178.221.219.238]) by mx.google.com with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com
Yes, this is my concern. I think we have an opportunity to set well-defined expectations and ensure implementations converge to them. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Brent London Sent: Tuesday, February 24, 2015 2:52 PM To: Dusan Stojicevic Cc: ua-discuss@icann.org Subject: Re: [UA-discuss] Regarding "RTL" 1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one? I think the appropriate forum for this would be m3aawg<https://www.maawg.org/>, although I'm unsure of whether it's actually been raised there yet. 2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address? Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From heade! r. See the first expandable section of this<https://support.google.com/mail/answer/1366858?hl=en> article for more info. Gmail ignores dots in the usernames of gmail.com<http://gmail.com> addresses, which is doable because Gmail controls the gmail.com<http://gmail.com> namespace. So hello.world@gmail.com<mailto:hello.world@gmail.com> goes to the same user as helloworld@gmail.com<mailto:helloworld@gmail.com>. We can't, however, do that for other domains. For example, helloworld@outlook.com<mailto:helloworld@outlook.com> and hello.world@outlook.com<mailto:hello.world@outlook.com> are different users. 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. I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. Brent London brentlondon@google.com<mailto:brentlondon@google.com> +1 650-214-5206 On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> wrote: 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<mailto: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<http://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> [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<mailto: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<tel: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/> ... [Message clipped] ---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com<mailto:mailer-daemon@googlemail.com>> To: dusan@dukes.in.rs<mailto:dusan@dukes.in.rs> Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently: com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic> Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found ----- Original message ----- X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net<http://1e100.net>; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=; b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs<http://178-221-219-238.dynamic.isp.telekom.rs>. [178.221.219.238]) by mx.google.com<http://mx.google.com> with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic>> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs<mailto:54EC3080.1080807@dukes.in.rs>> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic> Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean --- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com
Thanks, Brent, and I agree with Mark. Dušan On 24.2.2015 23:56, Mark Svancarek wrote:
Yes, this is my concern. I think we have an opportunity to set well-defined expectations and ensure implementations converge to them.
/Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. /
*From:*ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Brent London *Sent:* Tuesday, February 24, 2015 2:52 PM *To:* Dusan Stojicevic *Cc:* ua-discuss@icann.org *Subject:* Re: [UA-discuss] Regarding "RTL"
1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one?
I think the appropriate forum for this would be m3aawg <https://www.maawg.org/>, although I'm unsure of whether it's actually been raised there yet.
2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address?
Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From heade! r. See the first expandable section of this <https://support.google.com/mail/answer/1366858?hl=en> article for more info.
Gmail ignores dots in the usernames of gmail.com <http://gmail.com> addresses, which is doable because Gmail controls the gmail.com <http://gmail.com> namespace. So hello.world@gmail.com <mailto:hello.world@gmail.com> goes to the same user as helloworld@gmail.com <mailto:helloworld@gmail.com>. We can't, however, do that for other domains. For example, helloworld@outlook.com <mailto:helloworld@outlook.com> and hello.world@outlook.com <mailto:hello.world@outlook.com> are different users.
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.
I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined.
Brent London
brentlondon@google.com <mailto:brentlondon@google.com>
+1 650-214-5206
On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs <mailto:dusan@dukes.in.rs>> wrote:
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 <mailto: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 <http://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> [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 <mailto: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 <tel: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/>
...
[Message clipped]
---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com <mailto:mailer-daemon@googlemail.com>> To: dusan@dukes.in.rs <mailto:dusan@dukes.in.rs> Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently:
com.gmail@dusan.stojicevic <mailto:com.gmail@dusan.stojicevic>
Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found
----- Original message -----
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net <http://1e100.net>; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=; b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs <mailto:dusan@dukes.in.rs>> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs <http://178-221-219-238.dynamic.isp.telekom.rs>. [178.221.219.238]) by mx.google.com <http://mx.google.com> with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic <mailto:com.gmail@dusan.stojicevic>> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs <mailto:54EC3080.1080807@dukes.in.rs>> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs <mailto:dusan@dukes.in.rs>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic <mailto:com.gmail@dusan.stojicevic> Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com
I think we have an opportunity to set well-defined expectations and ensure implementations converge to them.
After ICANN 51 in Los Angeles, Dave Crocker and I started working on rules for this issue, and we found it to be a messier problem than anticipated. People have different views about the "best state" of the world. Some say that the local-part should always be on the left, which creates a confusing UX for RTL users but makes the rule easy to understand. Alternatively, the arrangement could be context-dependent, but that reduces the usability of the string as an identifier and doesn't really solve the problem of confusability. There's also a whole practical question of: can we implement this? The prevalence of the Unicode Bidirectional Algorithm means that, unless the rule conforms to that algorithm, new rules would create a whole *new* type of universal acceptance issue, as some systems would process the string per the algorithm, and others would process it per the rule. This is such a messy issue that I think we should keep it on the UASG backburner and/or delegate it to a group dedicated to anti-abuse, like the m3aawg. Brent London brentlondon@google.com +1 650-214-5206 On Tue, Feb 24, 2015 at 3:01 PM, Dusan Stojicevic <dusan@dukes.in.rs> wrote:
Thanks, Brent, and I agree with Mark.
Dušan
On 24.2.2015 23:56, Mark Svancarek wrote:
Yes, this is my concern. I think we have an opportunity to set well-defined expectations and ensure implementations converge to them.
*Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. *
*From:* ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org <ua-discuss-bounces@icann.org>] *On Behalf Of *Brent London *Sent:* Tuesday, February 24, 2015 2:52 PM *To:* Dusan Stojicevic *Cc:* ua-discuss@icann.org *Subject:* Re: [UA-discuss] Regarding "RTL"
1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one?
I think the appropriate forum for this would be m3aawg <https://www.maawg.org/>, although I'm unsure of whether it's actually been raised there yet.
2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address?
Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From heade! r. See the first expandable section of this <https://support.google.com/mail/answer/1366858?hl=en> article for more info.
Gmail ignores dots in the usernames of gmail.com addresses, which is doable because Gmail controls the gmail.com namespace. So hello.world@gmail.com goes to the same user as helloworld@gmail.com. We can't, however, do that for other domains. For example, helloworld@outlook.com and hello.world@outlook.com are different users.
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.
I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined.
Brent London
brentlondon@google.com
+1 650-214-5206
On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs> wrote:
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 <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> 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@شزذ.يثب
Brent London
brentlondon@google.com
+1 650-214-5206
On Sun, Feb 22, 2015 at 5:46 AM, Alireza Saleh <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مثال@مثال.تست
the red part is username.
-Alireza
On Feb 22, 2015, at 11! :47 AM, Edmon Chung <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 ?
tld.sld@name-user / tld.sld@user-name ?
etc.?
Edmon
*From:* ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org <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 *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://>.
نام@مثال.آزمایشی <%D9%86%D8%A7%D9%85@xn--mgbh0fb.xn--hgbk6aj7f53bba>
TLD.SLD@NAME
*-Alireza*
*On Feb 22, 2015, at 4:01 AM, Edmon Chung <edmon@registry.asia <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 <tld.domain@name.user:mailto>*
*Is that correct Alireza?*
*Edmon*
*From:*
* ua-discuss-bounces@icann.org <ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org <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 <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 <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://اا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/>
...
[Message clipped]
---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com> To: dusan@dukes.in.rs Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently:
com.gmail@dusan.stojicevic
Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found
----- Original message -----
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=;
b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V
X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F
NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR
j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i
uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs. [178.221.219.238]) by mx.google.com with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com
------------------------------ <http://www.avast.com/>
Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. www.avast.com
I agree, any successful solution must conform to the algorithm. It feels doable to me, though, (i.e. it seems more constrained and simpler than generic text/sentences) … assuming the prevailing base direction can be determined (F.E. “local on the left” or “always the same base directionality as the OS language setting” or even “changed from the default to a user preference in the mail app settings page”). As you say, determining the prevailing base direction is the challenge, and one where tools and docs should be clear and prescriptive. Perhaps m3aawg should be involved, but I don’t think our UA team can just throw it over the wall to them. I think we must stay involved. We can turn down the heat today, but I wouldn’t push it all the way to the back burner yet. Does that make sense? From: Brent London [mailto:brentlondon@google.com] Sent: Tuesday, February 24, 2015 3:15 PM To: Dusan Stojicevic Cc: Mark Svancarek; ua-discuss@icann.org Subject: Re: [UA-discuss] Regarding "RTL" I think we have an opportunity to set well-defined expectations and ensure implementations converge to them. After ICANN 51 in Los Angeles, Dave Crocker and I started working on rules for this issue, and we found it to be a messier problem than anticipated. People have different views about the "best state" of the world. Some say that the local-part should always be on the left, which creates a confusing UX for RTL users but makes the rule easy to understand. Alternatively, the arrangement could be context-dependent, but that reduces the usability of the string as an identifier and doesn't really solve the problem of confusability. There's also a whole practical question of: can we implement this? The prevalence of the Unicode Bidirectional Algorithm means that, unless the rule conforms to that algorithm, new rules would create a whole new type of universal acceptance issue, as some systems would process the string per the algorithm, and others would process it per the rule. This is such a messy issue that I think we should keep it on the UASG backburner and/or delegate it to a group dedicated to anti-abuse, like the m3aawg. Brent London brentlondon@google.com<mailto:brentlondon@google.com> +1 650-214-5206<tel:%2B1%20650-214-5206> On Tue, Feb 24, 2015 at 3:01 PM, Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> wrote: Thanks, Brent, and I agree with Mark. Dušan On 24.2.2015 23:56, Mark Svancarek wrote: Yes, this is my concern. I think we have an opportunity to set well-defined expectations and ensure implementations converge to them. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Brent London Sent: Tuesday, February 24, 2015 2:52 PM To: Dusan Stojicevic Cc: ua-discuss@icann.org<mailto:ua-discuss@icann.org> Subject: Re: [UA-discuss] Regarding "RTL" 1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one? I think the appropriate forum for this would be m3aawg<https://www.maawg.org/>, although I'm unsure of whether it's actually been raised there yet. 2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address? Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From heade! r. See the first expandable section of this<https://support.google.com/mail/answer/1366858?hl=en> article for more info. Gmail ignores dots in the usernames of gmail.com<http://gmail.com> addresses, which is doable because Gmail controls the gmail.com<http://gmail.com> namespace. So hello.world@gmail.com<mailto:hello.world@gmail.com> goes to the same user as helloworld@gmail.com<mailto:helloworld@gmail.com>. We can't, however, do that for other domains. For example, helloworld@outlook.com<mailto:helloworld@outlook.com> and hello.world@outlook.com<mailto:hello.world@outlook.com> are different users. 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. I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. Brent London brentlondon@google.com<mailto:brentlondon@google.com> +1 650-214-5206<tel:650-214-5206> On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> wrote: 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<mailto: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<http://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> [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<mailto: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<tel: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/> ... [Message clipped] ---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com<mailto:mailer-daemon@googlemail.com>> To: dusan@dukes.in.rs<mailto:dusan@dukes.in.rs> Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently: com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic> Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found ----- Original message ----- X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net<http://1e100.net>; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=; b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs<http://178-221-219-238.dynamic.isp.telekom.rs>. [178.221.219.238]) by mx.google.com<http://mx.google.com> with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic>> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs<mailto:54EC3080.1080807@dukes.in.rs>> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic> Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean --- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com ________________________________ [http://static.avast.com/emails/avast-mail-stamp.png]<http://www.avast.com/> Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. www.avast.com<http://www.avast.com/>
Having problem in identifying the local part from the domain part may also happen in fully ASCII email addresses. By start using more RTL addresses the confusion will also increase. One of the solution would be colorizing the email address and URLs in applications when someone receives an email or wanted to brows an address, However we shoudl increase the users knowledge in this area because I think in some cases user herself is responsible for her protection. As I said users also have problem in identifying the TLD from the rest within the URLs because it depends on the reading direction. Basically the RTL native redears start reading from right to left when they arrives at a sentence surrounded by RTL characters even whithin a LTR paragraph or context. -Alireza On Feb 25, 2015, at 3:16 AM, Mark Svancarek <marksv@microsoft.com> wrote:
I agree, any successful solution must conform to the algorithm.
It feels doable to me, though, (i.e. it seems more constrained and simpler than generic text/sentences) … assuming the prevailing base direction can be determined (F.E. “local on the left” or “always the same base directionality as the OS language setting” or even “changed from the default to a user preference in the mail app settings page”).
As you say, determining the prevailing base direction is the challenge, and one where tools and docs should be clear and prescriptive.
Perhaps m3aawg should be involved, but I don’t think our UA team can just throw it over the wall to them. I think we must stay involved. We can turn down the heat today, but I wouldn’t push it all the way to the back burner yet.
Does that make sense?
From: Brent London [mailto:brentlondon@google.com] Sent: Tuesday, February 24, 2015 3:15 PM To: Dusan Stojicevic Cc: Mark Svancarek; ua-discuss@icann.org Subject: Re: [UA-discuss] Regarding "RTL"
I think we have an opportunity to set well-defined expectations and ensure implementations converge to them.
After ICANN 51 in Los Angeles, Dave Crocker and I started working on rules for this issue, and we found it to be a messier problem than anticipated.
People have different views about the "best state" of the world. Some say that the local-part should always be on the left, which creates a confusing UX for RTL users but makes the rule easy to understand. Alternatively, the arrangement could be context-dependent, but that reduces the usability of the string as an identifier and doesn't really solve the problem of confusability.
There's also a whole practical question of: can we implement this? The prevalence of the Unicode Bidirectional Algorithm means that, unless the rule conforms to that algorithm, new rules would create a wholenew type of universal acceptance issue, as some systems would process the string per the algorithm, and others would process it per the rule.
This is such a messy issue that I think we should keep it on the UASG backburner and/or delegate it to a group dedicated to anti-abuse, like the m3aawg.
Brent London brentlondon@google.com +1 650-214-5206
On Tue, Feb 24, 2015 at 3:01 PM, Dusan Stojicevic <dusan@dukes.in.rs> wrote: Thanks, Brent, and I agree with Mark.
Dušan
On 24.2.2015 23:56, Mark Svancarek wrote: Yes, this is my concern. I think we have an opportunity to set well-defined expectations and ensure implementations converge to them.
Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined.
From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Brent London Sent: Tuesday, February 24, 2015 2:52 PM To: Dusan Stojicevic Cc: ua-discuss@icann.org Subject: Re: [UA-discuss] Regarding "RTL"
1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one?
I think the appropriate forum for this would be m3aawg, although I'm unsure of whether it's actually been raised there yet.
2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address?
Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From heade! r. See the first expandable section of this article for more info.
Gmail ignores dots in the usernames of gmail.com addresses, which is doable because Gmail controls the gmail.com namespace. So hello.world@gmail.com goes to the same user ashelloworld@gmail.com. We can't, however, do that for other domains. For example, helloworld@outlook.com and hello.world@outlook.com are different users.
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.
I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined.
Brent London brentlondon@google.com +1 650-214-5206
On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs> wrote: 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> 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@شزذ.يثب
Brent London brentlondon@google.com +1 650-214-5206
On Sun, Feb 22, 2015 at 5:46 AM, Alireza Saleh <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مثال@مثال.تست
the red part is username.
-Alireza
On Feb 22, 2015, at 11! :47 AM, Edmon Chung <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 ? tld.sld@name-user / tld.sld@user-name ? etc.?
Edmon
From: 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 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://>.
نام@مثال.آزمایشی TLD.SLD@NAME
-Alireza
On Feb 22, 2015, at 4:01 AM, Edmon Chung <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
Is that correct Alireza?
Edmon
From: 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 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> 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://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب
...
[Message clipped]
---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com> To: dusan@dukes.in.rs Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently:
com.gmail@dusan.stojicevic
Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found
----- Original message -----
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=; b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs. [178.221.219.238]) by mx.google.com with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com
Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. www.avast.com
Apologies for missing the responses to this thread... Perhaps m3aawg should be involved, but I don’t think our UA team can just
throw it over the wall to them. I think we must stay involved. We can turn down the heat today, but I wouldn’t push it all the way to the back burner yet.
Does that make sense?
Yes, that makes sense. Agreed. On Tue, Feb 24, 2015 at 11:58 PM, Alireza Saleh <saleh+ua@nic.ir> wrote:
Having problem in identifying the local part from the domain part may also happen in fully ASCII email addresses. By start using more RTL addresses the confusion will also increase. One of the solution would be colorizing the email address and URLs in applications when someone receives an email or wanted to brows an address, However we shoudl increase the users knowledge in this area because I think in some cases user herself is responsible for her protection. As I said users also have problem in identifying the TLD from the rest within the URLs because it depends on the reading direction. Basically the RTL native redears start reading from right to left when they arrives at a sentence surrounded by RTL characters even whithin a LTR paragraph or context.
-Alireza
On Feb 25, 2015, at 3:16 AM, Mark Svancarek <marksv@microsoft.com> wrote:
I agree, any successful solution must conform to the algorithm.
It feels doable to me, though, (i.e. it seems more constrained and simpler than generic text/sentences) … assuming the prevailing base direction can be determined (F.E. “local on the left” or “always the same base directionality as the OS language setting” or even “changed from the default to a user preference in the mail app settings page”).
As you say, determining the prevailing base direction is the challenge, and one where tools and docs should be clear and prescriptive.
Perhaps m3aawg should be involved, but I don’t think our UA team can just throw it over the wall to them. I think we must stay involved. We can turn down the heat today, but I wouldn’t push it all the way to the back burner yet.
Does that make sense?
*From:* Brent London [mailto:brentlondon@google.com <brentlondon@google.com>] *Sent:* Tuesday, February 24, 2015 3:15 PM *To:* Dusan Stojicevic *Cc:* Mark Svancarek; ua-discuss@icann.org *Subject:* Re: [UA-discuss] Regarding "RTL"
I think we have an opportunity to set well-defined expectations and ensure implementations converge to them.
After ICANN 51 in Los Angeles, Dave Crocker and I started working on rules for this issue, and we found it to be a messier problem than anticipated.
People have different views about the "best state" of the world. Some say that the local-part should always be on the left, which creates a confusing UX for RTL users but makes the rule easy to understand. Alternatively, the arrangement could be context-dependent, but that reduces the usability of the string as an identifier and doesn't really solve the problem of confusability.
There's also a whole practical question of: can we implement this? The prevalence of the Unicode Bidirectional Algorithm means that, unless the rule conforms to that algorithm, new rules would create a whole*new* type of universal acceptance issue, as some systems would process the string per the algorithm, and others would process it per the rule.
This is such a messy issue that I think we should keep it on the UASG backburner and/or delegate it to a group dedicated to anti-abuse, like the m3aawg.
Brent London brentlondon@google.com +1 650-214-5206
On Tue, Feb 24, 2015 at 3:01 PM, Dusan Stojicevic <dusan@dukes.in.rs> wrote:
Thanks, Brent, and I agree with Mark.
Dušan On 24.2.2015 23:56, Mark Svancarek wrote:
Yes, this is my concern. I think we have an opportunity to set well-defined expectations and ensure implementations converge to them.
*Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. *
*From:* ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org <ua-discuss-bounces@icann.org>] *On Behalf Of *Brent London *Sent:* Tuesday, February 24, 2015 2:52 PM *To:* Dusan Stojicevic *Cc:* ua-discuss@icann.org *Subject:* Re: [UA-discuss] Regarding "RTL"
1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one?
I think the appropriate forum for this would be m3aawg <https://www.maawg.org/>, although I'm unsure of whether it's actually been raised there yet.
2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address?
Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From heade! r. See the first expandable section of this <https://support.google.com/mail/answer/1366858?hl=en> article for more info.
Gmail ignores dots in the usernames of gmail.com addresses, which is doable because Gmail controls the gmail.com namespace. So hello.world@gmail.com goes to the same user ashelloworld@gmail.com. We can't, however, do that for other domains. For example, helloworld@outlook.com and hello.world@outlook.com are different users.
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.
I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined.
Brent London brentlondon@google.com +1 650-214-5206
On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs> wrote:
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 <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> 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@شزذ.يثب
Brent London brentlondon@google.com +1 650-214-5206
On Sun, Feb 22, 2015 at 5:46 AM, Alireza Saleh <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مثال@مثال.تست
the red part is username.
-Alireza
On Feb 22, 2015, at 11! :47 AM, Edmon Chung <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 ? tld.sld@name-user / tld.sld@user-name ? etc.?
Edmon
*From:* ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org <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 *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://>.
نام@مثال.آزمایشی <%D9%86%D8%A7%D9%85@xn--mgbh0fb.xn--hgbk6aj7f53bba> TLD.SLD@NAME
*-Alireza*
*On Feb 22, 2015, at 4:01 AM, Edmon Chung <edmon@registry.asia <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 <tld.domain@name.user:mailto>*
*Is that correct Alireza?*
*Edmon*
*From:*
* ua-discuss-bounces@icann.org <ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org <ua-discuss-bounces@icann.org>] On Behalf Of Alireza SalehSent: Sunday, February 22, 2015 2:54 AMTo: Mark SvancarekCc: ua-discuss@icann.org <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 <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://اا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/>
...
[Message clipped]
---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com> To: dusan@dukes.in.rs Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently:
com.gmail@dusan.stojicevic
Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found
----- Original message -----
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=;
b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V
X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F
NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR
j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i
uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs. [178.221.219.238]) by mx.google.com with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com
------------------------------ <http://www.avast.com/>
Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. www.avast.com
FWIW I am having a similar discussion inside Microsoft right now and coming to that same conclusion ;-) From: Brent London [mailto:brentlondon@google.com] Sent: Tuesday, March 3, 2015 11:58 AM To: Alireza Saleh Cc: Mark Svancarek; ua-discuss@icann.org Subject: Re: [UA-discuss] Regarding "RTL" Apologies for missing the responses to this thread... Perhaps m3aawg should be involved, but I don’t think our UA team can just throw it over the wall to them. I think we must stay involved. We can turn down the heat today, but I wouldn’t push it all the way to the back burner yet. Does that make sense? Yes, that makes sense. Agreed. On Tue, Feb 24, 2015 at 11:58 PM, Alireza Saleh <saleh+ua@nic.ir<mailto:saleh+ua@nic.ir>> wrote: Having problem in identifying the local part from the domain part may also happen in fully ASCII email addresses. By start using more RTL addresses the confusion will also increase. One of the solution would be colorizing the email address and URLs in applications when someone receives an email or wanted to brows an address, However we shoudl increase the users knowledge in this area because I think in some cases user herself is responsible for her protection. As I said users also have problem in identifying the TLD from the rest within the URLs because it depends on the reading direction. Basically the RTL native redears start reading from right to left when they arrives at a sentence surrounded by RTL characters even whithin a LTR paragraph or context. -Alireza On Feb 25, 2015, at 3:16 AM, Mark Svancarek <marksv@microsoft.com<mailto:marksv@microsoft.com>> wrote: I agree, any successful solution must conform to the algorithm. It feels doable to me, though, (i.e. it seems more constrained and simpler than generic text/sentences) … assuming the prevailing base direction can be determined (F.E. “local on the left” or “always the same base directionality as the OS language setting” or even “changed from the default to a user preference in the mail app settings page”). As you say, determining the prevailing base direction is the challenge, and one where tools and docs should be clear and prescriptive. Perhaps m3aawg should be involved, but I don’t think our UA team can just throw it over the wall to them. I think we must stay involved. We can turn down the heat today, but I wouldn’t push it all the way to the back burner yet. Does that make sense? From: Brent London [mailto:brentlondon@google.com] Sent: Tuesday, February 24, 2015 3:15 PM To: Dusan Stojicevic Cc: Mark Svancarek; ua-discuss@icann.org<mailto:ua-discuss@icann.org> Subject: Re: [UA-discuss] Regarding "RTL" I think we have an opportunity to set well-defined expectations and ensure implementations converge to them. After ICANN 51 in Los Angeles, Dave Crocker and I started working on rules for this issue, and we found it to be a messier problem than anticipated. People have different views about the "best state" of the world. Some say that the local-part should always be on the left, which creates a confusing UX for RTL users but makes the rule easy to understand. Alternatively, the arrangement could be context-dependent, but that reduces the usability of the string as an identifier and doesn't really solve the problem of confusability. There's also a whole practical question of: can we implement this? The prevalence of the Unicode Bidirectional Algorithm means that, unless the rule conforms to that algorithm, new rules would create a wholenew type of universal acceptance issue, as some systems would process the string per the algorithm, and others would process it per the rule. This is such a messy issue that I think we should keep it on the UASG backburner and/or delegate it to a group dedicated to anti-abuse, like the m3aawg. Brent London brentlondon@google.com<mailto:brentlondon@google.com> +1 650-214-5206<tel:%2B1%20650-214-5206> On Tue, Feb 24, 2015 at 3:01 PM, Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> wrote: Thanks, Brent, and I agree with Mark. Dušan On 24.2.2015 23:56, Mark Svancarek wrote: Yes, this is my concern. I think we have an opportunity to set well-defined expectations and ensure implementations converge to them. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Brent London Sent: Tuesday, February 24, 2015 2:52 PM To: Dusan Stojicevic Cc: ua-discuss@icann.org<mailto:ua-discuss@icann.org> Subject: Re: [UA-discuss] Regarding "RTL" 1) Where are e-mail solution providers gathering to discuss this? Does a forum already exist? if not, should the UASG create one? I think the appropriate forum for this would be m3aawg<https://www.maawg.org/>, although I'm unsure of whether it's actually been raised there yet. 2) Brent: How has Gmail approached this? Ignored the dots in the username side of the address? Gmail uses banner notifications to warn users when there's something problematic about a message, e.g., a suspicious From heade! r. See the first expandable section of this<https://support.google.com/mail/answer/1366858?hl=en> article for more info. Gmail ignores dots in the usernames of gmail.com<http://gmail.com/> addresses, which is doable because Gmail controls the gmail.com<http://gmail.com/> namespace. So hello.world@gmail.com<mailto:hello.world@gmail.com> goes to the same user ashelloworld@gmail.com<mailto:helloworld@gmail.com>. We can't, however, do that for other domains. For example, helloworld@outlook.com<mailto:helloworld@outlook.com> and hello.world@outlook.com<mailto:hello.world@outlook.com> are different users. 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. I think the circumstances are different in the RTL world. Fully right-to-left email addresses (with a RTL local-part) are pretty rare, so while there may be precedent, I don't think the behavior is well-defined. Brent London brentlondon@google.com<mailto:brentlondon@google.com> +1 650-214-5206<tel:650-214-5206> On Tue, Feb 24, 2015 at 12:16 AM, Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> wrote: 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<mailto: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<http://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> [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<mailto: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<tel: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/> ... [Message clipped] ---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon@googlemail.com<mailto:mailer-daemon@googlemail.com>> To: dusan@dukes.in.rs<mailto:dusan@dukes.in.rs> Cc: Date: Tue, 24 Feb 2015 08:04:19 +0000 Subject: Delivery Status Notification (Failure) Delivery to the following recipient failed permanently: com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic> Technical details of permanent failure: DNS Error: Address resolution of dusan.stojicevic. failed: Domain name not found ----- Original message ----- X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net<http://1e100.net/>; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oV7WQ8lryXPSsTVyIzYLp3QZdFh+3U95bpv4Okv/xjI=; b=QqLxV2xWblSmXtEvb8ak92Y3nnpQMC6pqDr5pp817ubddgmuUJqPdviXYpj0UTqa+V X8+F7jISs2TUpugEXyFYwG9OVo9AbD5tbgvYd+L+sZhEicjmJ1VkK10yCcj2g/4Lll1F NQjLy+uL7xhiXudx3DRVN3FebiZ9MT2mf8NWNHfJzodeTiQqfTZ39spVDzuZJUoID3WR j4wSf1iVpBKximpwxU/PXSPF1exepSDJBGNSk/XX6DCKEpl3AmemheU/52Bs1xO5Cf/i uEt66tW5W5ufTLKtRaOH/BnPFHTUtpnT26txciwpZI8zuGPm0GNefFFhbOwQjggFxLrf 93hA== X-Gm-Message-State: ALoCoQlQhBKx8PrtsJjuCaKmlNYZK/+74aUgVNjwV2wkNFRmTp/ZveDMMVEMS/l7lo4b9aGuvha/ X-Received: by 10.180.77.166 with SMTP id t6mr28567023wiw.28.1424765057763; Tue, 24 Feb 2015 00:04:17 -0800 (PST) Return-Path: <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> Received: from [127.0.0.1] (178-221-219-238.dynamic.isp.telekom.rs<http://178-221-219-238.dynamic.isp.telekom.rs/>. [178.221.219.238]) by mx.google.com<http://mx.google.com/> with ESMTPSA id s5sm23757985wia.1.2015.02.24.00.04.15 for <com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic>> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 00:04:16 -0800 (PST) Message-ID: <54EC3080.1080807@dukes.in.rs<mailto:54EC3080.1080807@dukes.in.rs>> Date: Tue, 24 Feb 2015 09:04:16 +0100 From: Dusan Stojicevic <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: com.gmail@dusan.stojicevic<mailto:com.gmail@dusan.stojicevic> Subject: proba Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150223-1, 02/23/2015), Outbound message X-Antivirus-Status: Clean --- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. http://www.avast.com<http://www.avast.com/> ________________________________ [http://static.avast.com/emails/avast-mail-stamp.png]<http://www.avast.com/> Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. www.avast.com<http://www.avast.com/>
Not for the ASCII IRI. -Alireza On Feb 20, 2015, at 10:35 PM, Mark Svancarek <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://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://اا1اا.بب2بب.ةة3ةة http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://a1a.اا2اا.بب3بب.d4d http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب http://اا1اا.b2b.c3c.بب4بب
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. Instead 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 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”) 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>
participants (9)
-
Alireza Saleh -
Alireza Saleh -
Brent London -
Don Hollander -
Dusan Stojicevic -
Edmon Chung -
Mark Svancarek -
Ram Mohan -
Sarmad Hussain