mixing different direction labels within same domain

Abdulrahman I. ALGhadir aghadir at citc.gov.sa
Wed Aug 10 10:29:29 CEST 2011


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?


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

  o  The 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


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/20110810/cc1ae673/attachment.html>


More information about the Idna-update mailing list