RTL labels and numbers?
Vint Cerf
vint at google.com
Wed Oct 14 14:57:53 CEST 2009
There was endless discussion on this particular question (inter-label
rules) and the group consensus was that this added too much
complexity. The existence of DNAMES that you cannot test before
registration was a major argument against using inter-label methods to
qualify a label's validity.
vint
On Oct 14, 2009, at 7:45 AM, Raed Al-Fayez wrote:
> Dear Vint,
>
> Sorry for the Typo … yes you are correct the intended example are:
>
> 1 - Mixing between scripts in one domain name where label1 from a
> script that has RTL chars while label2 from another script that has
> LTR chars/digits (e.g. xyz.ABC.xyz where xyz are LTR 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)
>
> I agree that the suggested solution may requires “inter-label
> examination” but again that was a solution that came to my mind and
> think there might be other ways to solve the issue.
>
> Even if what I have suggested was the only solution that can solve
> the problem I hope the group will reconsider their direction since
> it will free lots of false positive related to this issue.
>
> What I want to say that we should do our best to minimize the number
> of prevented domains that are not part of this problem.
>
>
> 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: Vint Cerf [mailto:vint at google.com]
> Sent: Wednesday, 14 October 2009 10:59 AM
> To: Raed Al-Fayez
> Cc: Abdulrahman I. ALGhadir; idna-update at alvestrand.no
> Subject: Re: RTL labels and numbers?
>
> 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.
>
> -----------------------------------------------------------------------------------
> 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/5bf3f646/attachment-0001.htm
More information about the Idna-update
mailing list