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

[Pete Resnick <[e-mail]>]

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. 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*. 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.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]