mixing different direction labels within same domain

[Harald Alvestrand]

On 08/10/2011 10:29 AM, Abdulrahman I. ALGhadir wrote:
>
> Well in this case the protocol didn't give any standard solution way 
> to handle this problem rather letting it to be treated as vendor wish 
> (shouldn't the rfc enacts in making standards) or at least to 
> acknowledge this issue and to push it to another level e.g.  Unicode 
> URI rendering?
>

The group discussed the problem of detecting the presence of domain 
names in free text, and the consequences of having domain names display 
differently when apps treated them as domain names and when apps treated 
them as free text.

The conclusion was that detecting domain names in free text is just 
about impossible, and that consistent behaviour is important to users; 
thus, the WG did not recommend any special treatment for domain names, 
choosing rather to live with the results of the existing BIDI algorithm.

> *From:*idna-update-bounces at alvestrand.no 
> [mailto:idna-update-bounces at alvestrand.no] *On Behalf Of *Harald 
> Alvestrand
> *Sent:* 7/Aug/2011 11:55 PM
> *To:* Abdulrahman I. ALGhadir
> *Cc:* idna-update at alvestrand.no
> *Subject:* Re: mixing different direction labels within same domain
>
> On 06/21/11 07:55, Abdulrahman I. ALGhadir wrote:
>
> Dear all,
>
> I am just wondering whenever it is permitted or not to have this case:
>
> <r2l chars><num1>.<num2>.<etc ..>
>
> This particular case has all labels legal, but the overall display 
> name will display very oddly (as noted). The oddity is caused by our 
> inability to mandate whole-domain tests, as described in the RFC.
>
> It is logical for the administrator of <etc ..> to forbid registration 
> of leading-numeric labels if it anticipates R2L labels at the next 
> level down, and it is logical for application writers to simply reject 
> such names because they are going to confuse the users (much in the 
> spirit of Firefox' refusal to do mixed-script names), but the RFC does 
> not require them to do so.
>
>
> As you know in case r2l labels the display will be like this
>
> <etc..>.<num1>.<num2><r2l chars>
>
> I think the display will depend on the direction of <etc> and whether 
> it is in an RTL context or an LTR context, but I'm still not confident 
> of my ability to execute the BIDI algorithm in my head.
>
> As you see both of them have different display order which isn't  the 
> same as network order.
>
> And I know it is mentioned in the RFC
>
>     Several stronger statements were considered and rejected, because
>     they seem to be*impossible to fulfill within the constraints of the*
> *    Unicode bidirectional algorithm*.
>
> And one of the statement is
>
> oThe sequence of labels should be consistent with network order.
>
> This proved impossible -- a domain name consisting of the labels
>
> in network order) L1.R2.R3.L4 will be displayed as L1.R3.R2.L4 in
>
> an LTR context.  (In an RTL context, it will be displayed as
>
> L4.R3.R2.L1)
>
>   
>
> And I have tried two implemented tools (well I don't know if they 
> follow the RFC fully or not).
>
> http://unicode.org/cldr/utility/idna.jsp?a=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9#notes
>
> http://mct.verisign-grs.com/conversiontool/convertServlet?input=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9&type=UTF8 
> <http://mct.verisign-grs.com/conversiontool/convertServlet?input=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9&type=UTF8>
>
> Abdulrahman,
>
>   
>   
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no  <mailto:Idna-update at alvestrand.no>
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20110906/a2443a69/attachment.html>