RTL labels and numbers?

[Vint Cerf]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091013/93e7c31a/attachment.htm