harald at alvestrand.no
Tue Aug 11 06:26:12 CEST 2009
Mark Davis ⌛ wrote:
> 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