Comments on draft-ietf-idnabis-bidi-04

[Harald Alvestrand]

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!
>
>