RTL labels and numbers?

Abdulrahman I. ALGhadir aghadir at citc.gov.sa
Wed Oct 14 06:45:20 CEST 2009


Well yes it is confusing and yes there are other confusing problems
which the protocol simply assign it to registry what I say it is unfair
to prevent all domains 

Which they start with digits to be as choice for user if this problem
moved to registry level a registry can simply do:

1)      Act same as what the protocol do now (preventing all domains
which start with digits).

2)       Register domains which start with digits and lock the same
domain which end with digits and the opposite.

And any further problems which may result from using 2) can be solved as
the registry wants.

Plus if the protocol allowed this maybe bidi algorithm will support
domains who knows.

 

Thank you,

From: Vint Cerf [mailto:vint at google.com] 
Sent: 13/Oct/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/470f19d7/attachment.htm 


More information about the Idna-update mailing list