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

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

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.

> I am not
> about to hold up the document because of this, but if we can come up
> with text that does not recommend 5893, it would make me very happy.

Agreed on the goal, I think.

Peter

-- 
Peter Saint-Andre
https://andyet.com/