Protocol Action: 'Right-to-left scripts for IDNA' to Proposed Standard

[Shawn Steele]

It can be "solved" by rendering each label without reordering the abels.  That isn't the unicode bidi algorithm, but that's not needed for domain names.  The IRI spec has a section on BIDI, so we should make sure that's "right"

- shawn

Sent from my Windows Mobile® smartphone

-----Original Message-----
From: Abdulrahman I. ALGhadir <aghadir at citc.gov.sa>
Sent: Saturday, February 13, 2010 4:19 AM
To: Slim Amamou <slim at alixsys.com>
Cc: idna-update at alvestrand.no <idna-update at alvestrand.no>
Subject: RE: Protocol Action: 'Right-to-left scripts for IDNA' to Proposed      Standard


Quote:
>Here. I think we nailed it. The problem is that "logical order" for
>new notations, actually have to be defined. We have to define how
>logically should an IDN be displayed. We are sure that displaying
>L1.R2.R3.L4 as L1.R3.R2.L4 is not logical. But we have two logical
>alternatives to display it. Namely :  L1.R2.R3.L4 and L4.R3.R2.L1 and
>I'd prefer we agree on one rather than letting the two coexist. And
>the straight forward way to do it is to keep the one which corresponds
>to network order.

Just to clear it out.
the problem here isn't in the IDNA itself rather UAX#9 because IDNA disallowed all bidi markers which will solve  this sort of issues. And yet you can't enforce it in IDNA level because all applications will render it based on UAX#9 and will result the same order(which you think it is wrong?). The only way to solve it from IDNA level is to prevent all mixing of labels with different directions and yet I don't think this will be possible.


-----Original Message-----
From: slim.amamou at gmail.com [mailto:slim.amamou at gmail.com] On Behalf Of Slim Amamou
Sent: 13/Feb/2010 2:28 PM
To: Abdulrahman I. ALGhadir
Subject: Re: Protocol Action: 'Right-to-left scripts for IDNA' to Proposed Standard

On Sat, Feb 13, 2010 at 11:13 AM, Abdulrahman I. ALGhadir
<aghadir at citc.gov.sa> wrote:
> Quote:
>>That won't be too difficult. Two choices :
>>
>>  - Enforce LTR context (and thus network order) for the domain name
>>display. This is my preferred choice, since it preserves a unique
>>presentation for the domain name in every context and for all locales.
>>i.e. the domain name will look the same in china, morocco, england...
>
> Well you only pushed the problem into another form . at first the problem was getting a different order for display (which is a correct logical order) rather than network order.
> Now you are getting an order for display that meets the network order but not always logically ordered.

Here. I think we nailed it. The problem is that "logical order" for
new notations, actually have to be defined. We have to define how
logically should an IDN be displayed. We are sure that displaying
L1.R2.R3.L4 as L1.R3.R2.L4 is not logical. But we have two logical
alternatives to display it. Namely :  L1.R2.R3.L4 and L4.R3.R2.L1 and
I'd prefer we agree on one rather than letting the two coexist. And
the straight forward way to do it is to keep the one which corresponds
to network order.

--
Slim Amamou | سليم عمامو
http://alixsys.com

-----------------------------------------------------------------------------------
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