RTL labels and numbers?

[Vint Cerf]

Raed,

doesn't your solution require inter-label examination? We debated that  
and concluded that the complexity was too high to implement. The DNAME  
problem also creates the potential for surprises in spite of inter- 
label testing.  So even though your examples are clear (well there are  
some problems - see below), if the solution requires inter-label  
checking, we've seriously debated that and concluded not to require it.

Maybe I am not understanding your examples as well as I should.


did you mean to say:

1 - Mixing between scripts in one domain name label1 from a script  
that has RTL chars while label2 from another script that has LTR chars  
(e.g. xyz.ABC.xyz where xyz are LTR chars and ABC are RTL chars)


vint

On Oct 14, 2009, at 2:12 AM, Raed Al-Fayez wrote:

> Dear All,
>
> It is clear to us the risks with the labels which starts with digits  
> and have RTL characters. But here I want to tackle the issue from a  
> different angle:
>
> By denying all domains that start with a number we are preventing  
> lots of valid option to the Arabic users (or anyone who use RTL  
> language)!
>
> I think we can optimize the protocol to only deny the cases that  
> might make problems that might happen.
>
> For example these domain names does not have any problems in the  
> display:
> AAA.3BBB.CCC   (Where A, B and C are RTL chars)
> A3A.3BB3CCC    (Where A, B and C are RTL chars)
>
> The problem mainly occur some domain names if:
> 1-      Mixing between scripts in one domain name lable1 from a  
> script that have RTL chars while lable2 from another script that  
> have RTL chars (e.g. xyz.ABC.xyz where xyz are LRT chars and ABC are  
> RTL chars)
> 2-      If a label begins with a number while the previous label  
> ends with a number (e.g. AA2.3BB.CC where ABC are RTL chars)
> Other than these two rare cases I think there are no display problem  
> (at least from the Arabic-Script point of view).
>
> I think there are many solution that can solve this problem..A quick  
> one that pops in my mind (which can be implemented at the protocol  
> level) is let the protocol check the labels that contains RTL chars  
> and only deny the above two cases and allow other valid domains.
>
> I hope the group try to help more in this issue …
>
> Thanks ..
>
>
> With best regards,
>
> Raed I. Al-Fayez
> ------------------------------------------
> Senior IT Projects Specialist, M.Sc, PMP
> Saudi Network Information Center (SaudiNIC)
> Communication and Information Technology Commission (CITC)
> Tel: + 966-1-2639235   - Fax: + 966-1-2639393
> http://www.nic.net.sa
>
> From: idna-update-bounces at alvestrand.no [mailto:idna-update-bounces at alvestrand.no 
> ] On Behalf Of Vint Cerf
> Sent: Tuesday, 13 October 2009 4:06 PM
> To: Abdulrahman I. ALGhadir
> Cc: idna-update at alvestrand.no
> Subject: Re: RTL labels and numbers?
>
> for the most part, the IDNA2008 specification does place a great  
> deal of responsibility on
> the registry but for some cases, it was considered important to bar  
> particularly confusing
> situations at the protocol level. This was debated substantially  
> during the course of the
> development of IDNA2008.
>
>
> On Oct 13, 2009, at 4:15 AM, Abdulrahman I. ALGhadir wrote:
>
>
> Hello,
> Well while I was reading draft-ietf-idnabis-bidi-06.txt I found this:
>
> “4.3.  Strings with numbers
>
>    By requiring that the first or last character of a string be  
> category
>    R or AL, RFC 3454 prohibited a string containing right-to-left
>    characters from ending with a number.
>
>    Consider the strings ALEF 5 (HEBREW LETTER ALEF + DIGIT FIVE) and 5
>    ALEF.  Displayed in an LTR context, the first one will be displayed
>    from left to right as 5 ALEF (with the 5 being considered right-to-
>    left because of the leading ALEF), while 5 ALEF will be displayed  
> in
>    exactly the same order (5 taking the direction from context).
>    Clearly, only one of those should be permitted as a registered  
> label,
>    but barring them both seems unnecessary.”
>
> Why permitting done on the protocol level ? shouldn’t this be done  
> at registry level?
>
> Ex. If someone wants to register 3COM (COM is a RTL word) registry  
> will register 3COM for him/her and  will lock COM3.
> At least this will give users the choice for picking not forcing  
> them on one type?
>
> Thank you,
>
>
> -----------------------------------------------------------------------------------
> Disclaimer:
> This message and its attachment, if any, are confidential and may  
> contain legally
> privileged information. If you are not the intended recipient,  
> please contact the
> sender immediately and delete this message and its attachment, if  
> any, from your
> system. You should not copy this message or disclose its contents to  
> any other
> person or use it for any purpose. Statements and opinions expressed  
> in this e-mail
> are those of the sender, and do not necessarily reflect those of the  
> Communications
> and Information Technology Commission (CITC). CITC accepts no  
> liability for damage
> caused by this email.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
> -----------------------------------------------------------------------------------
> Disclaimer:
> This message and its attachment, if any, are confidential and may  
> contain legally
> privileged information. If you are not the intended recipient,  
> please contact the
> sender immediately and delete this message and its attachment, if  
> any, from your
> system. You should not copy this message or disclose its contents to  
> any other
> person or use it for any purpose. Statements and opinions expressed  
> in this e-mail
> are those of the sender, and do not necessarily reflect those of the  
> Communications
> and Information Technology Commission (CITC). CITC accepts no  
> liability for damage
> caused by this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091014/2abc43e2/attachment-0001.htm