Re: [precis] Review of draft-melnikov-precis-saslprepbis-03

[Alexey Melnikov <[e-mail]>]

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)"
>> <[e-mail]> 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...