Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20)

[Peter Saint-Andre - &yet <[e-mail]>]

On 2/9/15 11:16 AM, Peter Saint-Andre - &yet wrote:
> On 2/9/15 10:20 AM, Pete Resnick wrote:
>> Crap. Somehow I missed this discussion back in December, and didn't
>> notice it before I sent out Last Call. When I went to put in my new
>> ballot, I saw the change.
>>
>> On 12/7/14 9:49 PM, Peter Saint-Andre - &yet wrote:
>>>>> 5.2.5.  Directionality Rule
>>>>>
>>>>>
>>>>> The directionality rule of a profile specifies how to treat
>>>>> strings containing left-to-right (LTR) and right-to-left (RTL)
>>>>> characters (see Unicode Standard Annex #9 [ UAX9 ]).  A profile
>>>>> usually specifies a directionality rule that restricts strings to
>>>>> be entirely LTR
>>>>> strings or entirely RTL strings and defines the allowable
>>>>> sequences of characters in LTR and RTL strings.  Possible rules
>>>>> include, but are not limited to, (a) considering any string that
>>>>> contains a right- to-left code point to be a right-to-left string,
>>>>> or (b) applying the "Bidi Rule" from [ RFC5893 ].
>>>>
>>>> One can not restrict to only LTR or RTL as some code points are
>>>> neutral regarding directionality.
>>>>
>>>> See RFC5893. This was one of the mistakes in IDNA2003.
>>>
>>> I think you're right that the foregoing text is not quite correct.
>>>
>>> And in any case, as John Klensin reiterated at the mic in a recent
>>> PRECIS WG session, if we define something other than the Bidi Rule
>>> then we'll likely get it wrong. I think that text predates John's
>>> comments and hasn't been updated..
>>
>> While I agree that the text that I had proposed earlier is not correct
>> as it stands for the reason Patrik identifies, setting it back to:
>>
>>     The directionality rule of a profile specifies how to treat strings
>>     that contain right-to-left (RTL) characters (see Unicode Standard
>>     Annex #9 [UAX9]).  In general this document recommends applying the
>>     "Bidi Rule" from [RFC5893] to strings that contain RTL characters.
>>
>> (i.e., what was there before the AD Evaluation) was not correct. There
>> was, I thought, agreement on the problem I was pointing out, and text
>> inserted to address it. Encouraging the use of 5893 is a bad thing
>> outside of the DNS.
>
> I think John Klensin made a good point at the mic at a semi-recent
> meeting (London?) that, if we try to define a new bidirectionality rule,
> we are likely to do it wrong.
>
>> As we discussed at the time, the only reason that
>> the 5893 Bidi Rule is so restrictive is because the (a) IDNA is already
>> extremely restrictive in the characters it allows and (b) for DNS
>> purposes, they wanted to make the display of labels around "."s more
>> sane. Recommending 5893 it in other contexts is far too restrictive. Let
>> me make another attempt to correct the above text without getting the
>> bit about "only LTR or RTL" wrong:
>>
>>     The directionality rule of a profile specifies how to treat strings
>>     containing combinations of characters with different directionality
>>     (e.g., left-to-right (LTR) characters, right-to-left (RTL)
>>     characters, and/or neutral directionality characters; see Unicode
>>     Standard Annex #9 [ UAX9 ]).  A profile usually specifies a
>>     directionality rule that restricts strings to contain combinations of
>>     either entirely LTR and neutral characters or entirely RTL and
>>     neutral characters. A directionality rule can also define the
>>     allowable sequences of characters in such strings.  The "Bidi Rule"
>>     from [RFC5893] is a particularly restrictive example of such a
>>     directionality rule.
>>
>> I am not wedded to the above, but what I would hate to see was this
>> document go out the door with 5893 as the *recommendation*.
>
> What I would hate to see is leaving directionality handling up to the
> profiles without much guidance about what to do.

Further thoughts...

If I read your proposed text correctly, you are saying three things:

1. A profile needs to define which directionality rule applies.

2. A profile can define its own directionality rule.

3. A profile can/might/may/should use the following rule:

A string MUST contain LTR characters and neutral characters only or 
contain RTL characters and neutral characters only, but MUST NOT contain 
both LTR and RTL characters.

(Does that rule have a name?)

4. The directionality rule defined by a particular profile may specify 
further restrictions, or may use a more restrictive rule (such as the 
Bidi Rule).

I agree with (1). I think (2) is a bad idea for the reasons John 
explained. I think (3) is an acceptable rule and I think we might want 
to give profiles a choice between that and the Bidi Rule (thus 
discouraging new directionality rules). I think (4) is a bad idea if it 
assumes (2).

Peter