CVS gsasl/doc

[gsasl-commit]

Update of /home/cvs/gsasl/doc
In directory dopio:/tmp/cvs-serv8064

Modified Files:
        gsasl.texi 
Log Message:
Fix.


--- /home/cvs/gsasl/doc/gsasl.texi      2004/12/15 01:20:57     1.104
+++ /home/cvs/gsasl/doc/gsasl.texi      2004/12/15 18:10:53     1.105
@@ -1898,23 +1898,26 @@
 a guide for other implementors that worry about the same issues.
 
 @menu
-* Server-side use of SASLPrep in CRAM-MD5::
+* Use of SASLPrep in CRAM-MD5::
 * Use of SASLprep in LOGIN::
 @end menu
 
address@hidden Server-side use of SASLPrep in CRAM-MD5
address@hidden Server-side use of SASLPrep in CRAM-MD5
address@hidden Use of SASLPrep in CRAM-MD5
address@hidden Use of SASLPrep in CRAM-MD5
 
-The specification, as of draft-ietf-sasl-crammd5-02, is silent on
-whether a SASL server implementation applying SASLPrep on a password
-received from an external, non-SASL specific database (i.e., the
-passwords are not stored in SASLPrep form in the database), should set
-or clear the AllowUnassigned bit.  The motivation for the AU-bit in
-StringPrep/SASLPrep is for stored vs query strings.  It could be
+The specification, as of @file{draft-ietf-sasl-crammd5-04.txt}, is
+silent on whether a SASL server implementation applying SASLPrep on a
+password received from an external, non-SASL specific database (i.e.,
+the passwords are not stored in SASLPrep form in the database), should
+set or clear the AllowUnassigned bit.  The motivation for the AU-bit
+in StringPrep/SASLPrep is for stored vs query strings.  It could be
 argued that in this situation the server can treat the external
 password either as a stored string (from a database) or as a query
 (the server uses the string as a query into the fixed HMAC-MD5 hash).
 
+The specification is also unclear on whether clients should set or
+clear the AllowUnassigned flag.
+
 In the server, GNU SASL apply SASLPrep to the password with the
 AllowUnassigned bit cleared.