On 17/09/2012 21:03, Peter Saint-Andre wrote:
On 9/17/12 12:21 PM, Alexey Melnikov wrote:
On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)"
<[email protected]> wrote:
[I agree with the other points that Matt raised. Thanks for the review!]
* 3.2 (Passwords - Preparation) :: I do wonder about the
rationale for step 2) (map all non-ASCII space to ASCII space).
I myself have not run into conditions where this would matter,
but I mostly deal with US-based consumers with passwords almost
exclusively in the ASCII range. On the surface, it seems a bit
contradictory in principle to the "no bidi rule" rationale that
is included. I'm not advocating for retention or removal of step
2), but rather for providing a rationale (one way or the other).
This rule was always in SASLPrep, so this is trying to preserve
some sort of backward compatibility. Whether it is a good enough
reason to keep the rule - I don't know.
This rule applied to stringprep via Appendix B.1 in RFC 3454:
http://tools.ietf.org/html/rfc3454#appendix-B.1
In the interest of full disclosure, the code points involved were:
U+00AD SOFT HYPHEN
U+034F COMBINING GRAPHEME JOINER
U+1806 MONGOLIAN TODO SOFT HYPHEN
U+180B MONGOLIAN FREE VARIATION SELECTOR ONE
U+180C MONGOLIAN FREE VARIATION SELECTOR TWO
U+180D MONGOLIAN FREE VARIATION SELECTOR THREE
U+200B ZERO WIDTH SPACE
U+200C ZERO WIDTH NON-JOINER
U+200D ZERO WIDTH JOINER
U+2060 WORD JOINER
U+FE00 VARIATION SELECTOR-1
[...other variation selectors here...]
U+FE0F VARIATION SELECTOR-13
U+FEFF ZERO WIDTH NO-BREAK SPACE
As far as I can see, we have two alternatives for SASLprep-bis:
1. Continue to map those code points to nothing.
Did you mean "continue to map them to U+0020"?
2. Disallow those code points by subclassing the FreeClass.
I don't have a strong feeling either way, although mapping to nothing
has always struck me as a wimpy approach and I'd probably prefer to
explicitly disallow unwanted code points...
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
