Re: more SASLprep/protocol problems

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

RFC 2277 says:
   All protocols MUST identify, for all character data,
   which charset is in use.

That is, we cannot allow clients to transfer character data in
the protocol without providing the server a protocol mechanism
for reliably determining what charset is use.  My previous
suggestion was flawed in that it allowed character data to
be transferred without identifying which charset is in use.

For this reason, I revise my suggestion:
        The simple form of an AuthenticationChoice specifies a
        simple password to be used for authentication.  Passwords
        consisting of character data (text passwords) SHALL be
       transferred as [UTF-8] encoded [Unicode].  Prior to transfer,
       clients SHOULD prepare text passwords by applying the
       [SASLprep] profile of the [Stringprep] algorithm.  Passwords
        consisting of other data (such as random octets) MUST NOT
        be altered.

Keen eyes will see that I've dropped the "MAY prepare textual
passwords using algorithms".  This was done for the following
reasons.

First, it's implicit in the SHOULD.  As RFC 2119 says, there may
exist valid reasons in particular circumstances to ignore this
SHOULD, but the full implications must be understood and
carefully weighted before choosing a different course.  This
allows alternative approaches.

Secondly, RFC 2119 says of implementations supporting an OPTIONAL
feature MUST be prepared to interoperate with implementations which
don't.   If one client prepares text passwords as RECOMMENDED and
another doesn't, the user will likely only be able to use one
client or the other but not both.

Also, we need to ensure that interoperable implementations of
features, even OPTIONAL features, can be independently developed.
Two clients which both use "null" preparation may fail to
interoperate with the server due to platform differences.
For example, if one client send the text as UTF-16 and
another send same text as UTF-32, authentication will fail
one or both of these clients (assuming the server implements
password matching as specified).

Kurt