<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Mon, Aug 10, 2009 at 20:59, Harald Alvestrand <span dir="ltr"><<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Mark Davis ⌛ wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> An RTL label is a label that contains at least one character of type R or AL.<br>
<br>
I believe you should also add "AN". There are cases where it affects ordering.<br>
</blockquote></div>
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.</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> 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.<br>
<br>
Unless you anticipate future revisions of the protocol document in this direction, the "can also" should be changed to "could also have been".<br>
</blockquote></div>
The current status is, I believe, that some are specified in -tables, which I call "protocol level". Should there be an explicit reference?</blockquote><div><br>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.<br>
<ul><li>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).<br></li><li>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).</li>
<li>If you are referring to what could have been done, then "could also have been" would be appropriate.</li></ul>Because I can't tell what you want to say, I don't know which of these you would mean.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><font color="#888888">
<br>
Harald<br>
<br>
</font></blockquote></div><br>