Comments on draft-ietf-idnabis-bidi-04
Harald Alvestrand
harald at alvestrand.no
Sat Aug 29 23:19:25 CEST 2009
Andrew Sullivan wrote:
> Dear colleagues,
>
> I have read draft-ietf-idnabis-bidi-04. Here are my comments.
>
> To begin with, I must emphasise that I have no particular expertise in
> any bidirectoinal context. I can read competently only in
> Indo-European languages, and an embarrassing subset of them at that.
> So there is a limit to how useful my feedback can be.
>
> In §1.2, we have
>
> While the document proposes completely new text, most reasonable
> labels that were allowed under the old criterion will also be allowed
> under the new criterion, so the operational impact of the rule change
> is limited.
>
> It would be nice here, I suggest, to offer some definition of what
> labels fall outside "most reasonable labels". The description sounds
> too much like, "The labels we picked when we wrote this," which is
> indubitably not the impression anyone intended.
>
I added some examples (mixtures of numerals, and AN inside LTR labels).
Hope it helsp.
> There are some terms defined in §1.4. I think it would be way helpful
> to a naive reader to be directed to defs at the beginning of this
> section first, and then to say "there are specific BIDI-only terms
> also defined here". So I'd move the reference that's at the end of
> this section to the beginning. I don't feel too strongly about
> this, however. (Also, as an aside, it would be helpful if defs
> pointed out more explicitly in its §2.3.3 that there are BIDI-only
> terms defined in the BIDI document and not in defs.)
>
I moved it to the beginning. I don't think there's anything
bidi-specific in -defs.
> The third paragraph now ends with a comma, so it looks like something
> was supposed to be added and wasn't. Or is this just a typo?
>
Typo, fixed.
> I find this peculiar:
>
> A "Bidi domain name" is a domain name that contains at least one RTL
> label.
>
> If a domain name is RTL.RTL.RTL, it qualifies under this definition,
> even though there is no bidirectionality (all labels have the same
> directionality). Explaining why this is still "bidi" would leave me
> less confused.
>
Added some text to say "adding a separate RTL-name category would just
make the spec more complicated".
> Rule 1 in §2 says, "The first character must be a character with BIDI
> property L, R or AL." I can't tell whether that must is a requirement
> or a statement of fact that is entailed by other IDNA rules. If it's
> a requirement, it presumably ought to be a 2119 MUST; even if not, it
> seems that we have to know what to do in case the first character
> doesn't match this rule. If it's an entailment, it'd help to make
> that plain, which could be done by restating it, "The first character
> will be a character with BIDI property L, R, or AL due to [reason
> reference]."
>
I'm not sure what an entailment is - but this is a rule. In order to
execute the text, you must look at the first character and check its
BIDI property. This document isn't using 2119 (wow); I used to have the
reference way back when, but it didn't seem to help any, so I removed it.
> In §3, the text
>
> One specific requirement was thought to be problematic, but turned
> out to be satisfied by a string that obeys the proposed rules:
>
> o The Character Grouping requirement should be satisfied when
> directional controls (LRE, RLE, RLO, LRO, PDF) are used in the
> same paragraph (outside of the labels). Because these controls
> affect presentation order in non-obvious ways, by affecting the
> "sor" and "eor" properties of the Unicode BIDI algorithm, the
> conditions above require extra testing in order to figure out
> whether or not they influence the display of the domain name.
> Testing found that for the strings allowed under the rule
> presented in this document, directional controls do not influence
> the display of the domain name.
>
> comes after the discussion of things considered and rejected. This
> leaves me confused about whether the text above is in fact a
> requirement or not. If it is a requirement, then I'd move this
> segment to the part before the rejected requirements.
>
Added a little more text to explain the status of the requirement - it's
a "nice to know".
> The above are all "nice to have" issues; I think they would make the
> resulting text easier to understand. In general, I think the document
> is ready to go. I've sent a couple nits to the editors directly.
>
> Best regards,
>
> A
>
Again, thanks for the review!
>
>
More information about the Idna-update
mailing list