RTL labels and numbers?

[Raed Al-Fayez]

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 <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/97d83528/attachment-0001.htm