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

Michel Suignard michel at suignard.com
Sun Feb 14 19:04:11 CET 2010


If anything, the next revision of iri may move the bidi section in a  
separate document. Bidi considerations in a rendered iri is a complex  
subject. Finally, note the current iri rfc bidi rules are 'should',  
because an iri may never be rendered (think of name space as urn).
Overall it is a good time to engage in these discussion because the  
iri spec will be revised soon
Michel

Sent from my iPhone

On Feb 13, 2010, at 7:06 PM, "Shawn Steele"  
<Shawn.Steele at microsoft.com> wrote:

> 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
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update


More information about the Idna-update mailing list