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

[Abdulrahman I. ALGhadir]

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.

Quote:
>I don't think this problem could be solved by unicode. The reason is
>it's really tied to IDNs structure. IDN is a notation, like numbers
> (I'm choosing this example purposefully because numbers are presented
>LTR in a RTL context), and as such it has to have it's own coherency.
>So you can't solve the problem in a general way.

Well I don't think so it can be done in UAX#9 (well if URI has its own rules) the UAX#9 does know about the nature of characters (Neutral,RTL,LTR,week..) the context direction etc.. and thus there are possible ways to fix this issues in UAX#9 rather than IDNA itself.

Abdulrahman,

-----Original Message-----
From: slim.amamou at gmail.com [mailto:slim.amamou at gmail.com] On Behalf Of Slim Amamou
Sent: 13/Feb/2010 12:50 PM
To: Abdulrahman I. ALGhadir
Cc: idna-update at alvestrand.no; Shawn.Steele at microsoft.com
Subject: Re: Protocol Action: 'Right-to-left scripts for IDNA' to Proposed Standard

On Sat, Feb 13, 2010 at 5:44 AM, Abdulrahman I. ALGhadir
<aghadir at citc.gov.sa> wrote:
> Hey,
>
> Well as we know the IDNA protocol didn't adapt bidi algorithm (UAX #9) fully. They disallowed all bidi markers (LRM,RLM,...) which are they used to solve problems from this kind.
>
> So, what can be done?
> 1) adapt or create new algorithm in IDNA protocol to solve this issue (doubt it).

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

  - Define the behaviour of labels with respect to the period
separator for both LTR and RTL context.

ex.
The period MUST define a hierarchy relation between it's left label
and it's right label
in LTR  context the the hierarchy is such as right label is
hierarchically superior to left label
in RTL  context the the hierarchy is such as left label is
hierarchically superior to right label

> 2) make all hyper links to be treated in special way rather using UAX#9 (application wise possible).

This won't be too difficult since links, IRIs and domain names are
already parsed for purposes other than display.

> 3) enhance the existent bidi algorithm by adding new rules to support hyperlinks (possible).

I don't think this problem could be solved by unicode. The reason is
it's really tied to IDNs structure. IDN is a notation, like numbers
(I'm choosing this example purposefully because numbers are presented
LTR in a RTL context), and as such it has to have it's own coherency.
So you can't solve the problem in a general way.

This is actually a class of problems, let's call it "New notations",
which deals with the presentation of new notations introduced by new
and socially pervasive technologies (it's also the case of IRI for
example). IETF will have to tackle this problem one way or another.


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