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