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 <[email protected]> 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 > _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
