Let me try to shed some light on this. In the Unicode bidi subcommittee, there are four different items that have recently come up regarding BIDI.<br><br>The first is just some editorial clarifying text, and has already been discussed and approved by the UTC. This is not relevant to IDNA.<br>
<br>The others were too recent to have been considered by the UTC.<br><br>The second is regarding overriding mirroring for archaic scripts. This is not relevant to IDNA. <br><br>The third only applies to the embedding/overriding codes, which are not allowed in IDNs: RLE, LRE, RLO, LRO, and PDF. This is not relevant to IDNA. <i><br>
<br></i>The last is relevant, and came up most recently. It is the following:<br><br>There is reasonable disagreement about what the meaning of a particular rule (N1) is, with two possible interpretations. We know the intent of the author, but the intent of the author is outweighed by what the common practice is. That is, the UTC needs to be quite conservative about changes to BIDI, and existing practice is the major consideration. That requires determining, however, what the prevaling practice is, so we're investigating that now.<br>
<br>The practical impact for IDNA is, I think, the following.<br><br>1. As a part of investigating the common practice, we need to consider whether we need to add additional constraints to what Harald has devised. I see two possible approaches:<br>
<ol><li>We can wait until the investigation is competed, and accomodate the results;</li><li>Alternatively, we can add constraints (if need be) that accomplish the goal no matter which of the two interpretations of N1 is being used.</li>
</ol><br>2. We should add to the security considerations for bidi some indication of the fact that while the bidi constraints are intended to ensure "Character Grouping" and "Label Uniqueness" as much as possible, they may not do so for certain cases:<br>
<ol><li>If the label is adjacent to all-ASCII labels (the xxx.3com problem).</li><li>If the particular implementation of the bidi algorithm deviates from the standard.<br></li></ol>Mark<br><br><br><br>On Fri, Dec 12, 2008 at 09:21, Erik van der Poel <<a href="mailto:erikv@google.com">erikv@google.com</a>> wrote:<br>
> On Thu, Dec 11, 2008 at 11:26 PM, Alireza Saleh <<a href="mailto:saleh@nic.ir">saleh@nic.ir</a>> wrote:<br>>> The latest news we received in this case is that Mark is going to look<br>>> at it and will write a proposal and send it for public view.<br>
><br>> Mark has a lot on his plate.<br>><br>>> Correction of this bug may not affect the -bidi rules directly, but it<br>>> is related to the display of L AN characters in a paragraph.<br>><br>> I'm a bit concerned about this. We'd have to implement the new bidi<br>
> algorithm and then run programs like Harald's and mine to check.<br>><br>>> When I look at the recent improvements of<br>>> displaying AN,AL,R characters, I believe there will be no visual confusion<br>
>> when you have AN,AL,R characters in a LTR contexts such as domains.<br>><br>> Recent improvements? When did they occur? Has ICU been updated for those?<br>><br>>> Having the<br>>> backward incompatible issues such as what happens between IDNA2003 and<br>
>> IDNA2008 cannot be easily ignored because the real IDN domains are in the<br>>> market.<br>><br>> Yes.<br>><br>> Erik<br>><br><br>