Re: [precis] Enforcement as an Idempotent operation

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

On 2/26/17 5:48 PM, Peter Saint-Andre wrote:
> On 2/13/17 12:04 AM, William Fisher wrote:
>> On Sun, Feb 12, 2017 at 12:27 PM, Peter Saint-Andre <[e-mail]> wrote:
>>> Did you mean U+212A (KELVIN SIGN)? That decomposes to U+004B (LATIN CAPITAL
>>> LETTER K).
>>>
>>>> The full example is:
>>>> "\U0001f11aevin" => "(K)evin" => "(k)evin"
>>
>> I'm talking about 'PARENTHESIZED LATIN CAPITAL LETTER K' (U+1F11A).
>> Sorry it's not clear that the A is part of the unicode escape.
> 
> Thanks for the clarification.
> 
>> With casefold or tolower, the result is the same for these Nicknames:
>>
>> Not idempotent: "\U0001f11A" => "(K)" => "(k)"
>> Not idempotent: "\U0001f13A" => "K" => "k"
>> Not idempotent: "\u210c" => "H" => "h"
>> Not idempotent: "\u210d" => "H" => "h"
>> Not idempotent: "\u20a8" => "Rs" => "rs"
>>
>> When you apply the comparison steps from RFC 7700, Section 2.4, you
>> still get something that is upper case. If you apply the comparison
>> steps again, you now get lower case.
> 
> I see what you mean. I'm now leaning toward moving the case mapping rule
> after the normalization rule, but first I want to think about the
> implications for all of the PRECIS profiles (e.g., when using NFC vs.
> using NFKC). If we go down this road, we will also want to describe the
> reasoning in Section 5.2.3 of 7564bis.

Thinking about this further, I now lean against making this change in
the PRECIS processing rules, for several reasons:

1. Existing PRECIS implementations would need to be modified, resulting
in a behavioral difference between older and newer implementations (or
older and newer versions of the same implementation).

2. The order of operations in PRECIS was intended to be consistent with
IDNA2008 (in which case mapping is performed before normalization,
albeit in the application before the protocol is invoked), and with
IDNA2003 and Stringprep prior to IDNA2008 (note also that several PRECIS
profiles were designed as modernized replacements for Stringprep
profiles). Making PRECIS inconsistent with IDNA might make it harder to
reuse code and might lead to unexpected and undesirable consequences.

3. Idempotence, although a desirable quality, in my opinion falls into
the category of "nice but not necessary". (If we were designing PRECIS
anew, my opinion might be different.)

A safer approach would be to add an implementation note to the effect
that PRECIS processing might not be idempotent, and that implementations
might need to apply the rules more than once to the same string.

Peter