Mark Davis ⌛
mark at macchiato.com
Tue Aug 11 06:12:07 CEST 2009
On Mon, Aug 10, 2009 at 20:59, Harald Alvestrand <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
> 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.
>> > 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update