The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
draft-ietf-sasl-plain-09

From Gen-ART review by Eric Gray. A few sentences seem to need clarification.

----

In the second paragraph on page 4, I am having some trouble
parsing the text "The SASLprep preparation algorithm is not 
mandatory to allow, when appropriate, the server to employ 
other preparation algorithms (including none)."

What I think this means is "To allow the server to employ
other preparation algorithms (when appropriate, including
none), the SASLprep preparation algorithm is not mandatory."
Alternatively, a construction identical in meaning would be
"The SASLprep preparation algorithm is not mandatory.  This
allows, when appropriate, the server to employ other 
preparation algorithms (including none)."

Is this interpretation correct?

Another potential (mis?) interpretation of this statement is 
"It is not mandatory, in the SASLprep preparation algorithm,
to allow the server to employ other preparation algorithms
(when appropriate, including none)."

The latter interpretation is a stretch as well as not being
self-consistent, but it is a possible interpretation...
============================================================

I am not certain what the first two paragraphs on page 6 are
trying to say.

"It is noted that the DerivateAuthzid and Authorize functions 
(whether implemented as one function or two, whether designed 
in a manner in which these functions or the mechanism 
implementation can be reused elsewhere) require knowledge and 
understanding of mechanism and the application-level protocol 
specification and/or implementation details to implement

"It is also noted that the Authorize function outcome is clearly
dependent on details of the local authorization model and policy.
Both functions may be dependent on other factors as well."


After struggling with it for a while, I think it means - 

'Implementation of portions of the functionality shown in the
above pseudo-code (e.g. - DerivateAuthzid and Authorize) will
require understanding of specific mechanisms, application level
protocols and implementation details.  Also, the functionality
associated, in the pseudo code example, with the "Authorize"
function depends on local authorization and policy details.
Represented functionality may also depend on other factors.'

Is this correct?

I had trouble with the wording because:

1) I have no idea what value to associate with "noting" these 
   things as opposed to simply saying them.  Is there any?
2) I had to look a couple of times to realize that the intent
   of the parenthesized text in the first paragraph seems to
   be to avoid giving any sort of "definitive weight" to the
   example represented by the pseudo code (in other words, I
   had to read it twice to realize that I never had to read
   it at all).
3) I had some touble parsing the last two lines of the first
   paragraph. 
============================================================

The following text in section 5 - 

"The second example shows how the PLAIN mechanism might be 
used to assume the identity of another user.  In this example, 
the server rejects the request."

The first sentence implies success, the second failure.

I assume the second is correct.  In that case, shouldn't the
first sentence refer to an "attempt to assume ..."?

There is some shock value in the current wording, because I
thought it was getting ready to tell me how to do something
I should not be able to do.
===========================================================

NITs:
====

Section 1 - 6th paragaph "a strong data security service"
as opposed to "an strong ..."

Page 4, third paragraph - "unassigned code points are allowed 
to appear in" as opposed to "... allowed appear in".

The changes from RFC2595 section explicitly notes that CR and LF are now legal as authzid characters.  As I understand it, since this document updates RFC2595, an application protocol specification would have to write a new profile to use this, and could then exclude CR and LF characters if those cause any problems in the application layer.  Sam and I discussed the possibility of adding this kind of explanation to this document, which I feel would be useful.

  The Security Considerations say:
  >
  > "stringprep" and Unicode [StringPrep] security considerations
  > also apply, as do [UTF-8] security considerations.
  >
  I think it would be better if this were a separate paragraph.  Also,
  it will be easier to read if it was reworded slightly:
  >
  > Unicode and "stringprep" [StringPrep] security considerations
  > also apply, as do [UTF-8] security considerations.