--On Tuesday, September 15, 2009 14:43 -0500 Nicolas Williams
<Nicolas(_dot_)Williams(_at_)sun(_dot_)com> wrote:
...
[OT for the draft-ietf-sasl-scram thread, but possibly of
interest to the IETF list.]
NFSv4 left normalization form unspecified for filenames. We
ended up implementing normalization-insensitive and
normalization-preserving behavior in ZFS in Solaris. The
...
The lesson is, IMO, that in the general case I think we can
get way with not specifying normalization forms for _query_
strings, but not for _storage_ strings.
FWIW, I have gradually come to believe that
normalization-insensitive comparisons (i.e., strings compare
equal if their normalized forms are equal) are almost always a
better idea that remapping strings by normalization, especially
when the normalization method involved is NFKC or NFKD. The
same comment, discussed at some length in The Unicode Standard,
applies to case comparisons, especially if people believe that
toCaseFold is necessary... reasonable comparison operation,
pretty bad mapping one.
As has been suggested in other notes, normalization of storage
strings is just an optimization of that comparison principle.
But, as has also been pointed out, that principle is useless for
Scram, where the hash must be computed client-side across the
same string the server is going to use (or has used) to compute
its hash. It is equally useless for IDNA, at least until and
unless we "teach" the DNS about normalization-insensitive
comparisons of non-ASCII strings.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf