RTL labels and numbers?

[Abdulrahman I. ALGhadir]

well I am with you in this part there will be problems in some cases but
this isn't weird because as we know that 
the protocol is using the current bidi algorithm which it doesn't
identify domains and render them as they. so this
kind of problems are excepted to happen. and I still  think leaving this
problem to registry might give us a better
chance in solving it in future rather than just disallowing it in the
protocol level.

and the draft did mention this:

"Another set of issues concerns the proper display of IDNs with a
   mixture of LTR and RTL labels, or only RTL labels.

   It is unrealistic to expect that applications will display domain
   names using embedded formatting codes between their labels (for one
   thing, no reliable algorithms for identifying domain names in running
   text exist); thus, the display order will be determined by the BIDI
   algorithm.  Thus, a sequence (in network order) of R1.R2.ltr will be
   displayed in the order 2R.1R.ltr in an LTR context, which might
   surprise someone expecting to see labels displayed in hierarchical
   order.  People used to working with text that mixes LTR and RTL
   strings might not be so surprised by this.  Again, this memo does not
   attempt to suggest a solution to this problem."

 

Thank you,

 

From: Matitiahu Allouche [mailto:matial at il.ibm.com] 
Sent: 13/Oct/2009 3:29 PM
To: Abdulrahman I. ALGhadir
Cc: idna-update at alvestrand.no; idna-update-bounces at alvestrand.no
Subject: Re: RTL labels and numbers?

 


Abdulrahman I. ALGhadir wrote: 
<quote> 
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? 
<end of quote> 

There is another problem with "3COM" (where COM are RTL letters): if
preceded by a LTR label and displayed in an RTL context, the result will
be very confusing.  For instance, the string (in network order) 
      support.3COM.net 
will be displayed as 
      net.MOCsupport.3


Shalom (Regards),  Mati
          Bidi Architect
          Globalization Center Of Competency - Bidirectional Scripts
          IBM Israel
          Phone: +972 2 5888802    Fax: +972 2 5870333    Mobile: +972
52 2554160




From: 

"Abdulrahman I. ALGhadir" <aghadir at citc.gov.sa> 

To: 

<idna-update at alvestrand.no> 

Date: 

13/10/2009 10:16 

Subject: 

RTL labels and numbers? 

Sent by: 

idna-update-bounces at alvestrand.no

 

________________________________




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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091014/482dab0f/attachment-0001.htm