BIDI spec

Harald Alvestrand harald at alvestrand.no
Tue Aug 11 06:26:12 CEST 2009


Mark Davis ⌛ wrote:
>
> Mark
>
>
> On Mon, Aug 10, 2009 at 20:59, Harald Alvestrand <harald at alvestrand.no 
> <mailto:harald at alvestrand.no>> wrote:
>
>     Mark Davis ⌛ wrote:
>
>         > An RTL label is a label that contains at least one character
>         of type R or AL.
>
>         I believe you should also add "AN". There are cases where it
>         affects ordering.
>
>     It does, but weirdly. The rules currently outlaw anythng but R and
>     AL in the first position, so it seems to simplify things to leave
>     the status of an AN-only label undefined.
>
>
> What I mean is that if you had AN + L in a label (not nec in that 
> order), you wouldn't even count it as a BIDI domain name, and thus 
> none of the bidi doc would apply (according to the text). Yet such 
> labels would be legal according to protocol, and I think they can 
> cause reordering, and could thus cause the kind of visual confusion 
> that BIDI is supposed to prevent.
Good point. I'll modify.
>  
>
>
>
>         > Rules can also be specified at the protocol level, but while
>         the example above involves right-to-left characters, this is
>         not inherently a BIDI problem.
>
>         Unless you anticipate future revisions of the protocol
>         document in this direction, the "can also" should be changed
>         to "could also have been".
>
>     The current status is, I believe, that some are specified in
>     -tables, which I call "protocol level". Should there be an
>     explicit reference?
>
>
> I think the issue is that the word "can" was appropriate for when this 
> was a proposal, but the situation is different in heading for release; 
> the "can" should be changed according to what you mean.
>
>     * If you are referring to the situation as of when these are all
>       released, then the rules either  "are specified" or they are not
>       (in which case the statement removed).
>     * If you are referring to a future time, then the "can" becomes
>       "could" (or for clarity, adding "in a future version" or some
>       such language).
>     * If you are referring to what could have been done, then  "could
>       also have been" would be appropriate.
>
> Because I can't tell what you want to say, I don't know which of these 
> you would mean.
There's no guarantee of synchronity in further updates, so the situation 
isn't really all that different (BIDI doesn't place any constraint on 
future -tables), but I'll change to "are".



More information about the Idna-update mailing list