Re: [precis] Enforcement as an Idempotent operation

[William Fisher <[e-mail]>]

I agree with the "implementation note" strategy. In all my testing,
only the "Nickname" profile can fail to be idempotent for some inputs.
I have not found any inputs that fail the idempotent test using the
Username or OpaqueString profiles.  I believe "Nickname" has problems
because it uses NFKC.  I would add an implementation note/warning to
the Nickname profile.

Thanks,
Bill


On Tue, Mar 21, 2017 at 6:30 PM, Peter Saint-Andre <[e-mail]> wrote:
> 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
>