Re: more SASLprep/protocol problems

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

I think here are opposing objectives.   One fraction of the
community is attempting to improve interoperability between
independently developed implementations.  One faction is
attempting to support legacy systems.

Legacy systems, by their very nature, are dependently developed.
For example, in the "campus" scenario, there is an assumption
that of consistency of input devices, operating system platform,
application code, etc., to ensure that user input of a textual
string results in the desired octet string.

In independently developed systems, there is the assumption that
there may be no consistency between input devices, operating
system platforms.  Using a preparation algorithm is sound way
of addressing these problems.  As the server doesn't generally
have knowledge of user input devices and operating system
platforms used, preparation by the client is a sound approach.
(Note: It is possible to split the preparation between the client
and the server, PLAIN does this (client handles transcoding
to Unicode and UTF-8 encoding, server handles SASLprep).  With
LDAP, this is not a good option as the server has no way to
determine whether the password is textual or not.)

The specification is primarily written to promote interoperability
of independently developed implementations.  What dependently
developed implementations decide to do (or not do) is, to a
large degree, beyond the scope of the standard.  This is
not meant that we should abandon "legacy" issues, but to note why
we there is a "SHOULD".  A "SHOULD" allows implementations to
go against the recommendation where appropriate.  Maybe what
we need to be a bit more explicit about where going against the
SHOULD might be appropriate.

How's this?

     The simple form of an AuthenticationChoice specifies a simple
     password to be used for authentication.  To improve matching
     of textual passwords, clients SHOULD prepare textual passwords
     for transfer by transcoding to [Unicode], applying [SASLprep],
     and encoding as UTF-8.  Clients MAY prepare textual passwords
     using other algorithms (including null preparation) to support,
     for instance, legacy systems.  Non-textual passwords MUST NOT
     be mutated.

- Kurt