The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
RFC 4616

Note: This ballot was opened for revision 09 and is now closed.

(Sam Hartman) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-03-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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".

(Lisa Dusseault) No Objection

Comment (2006-03-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Lars Eggert) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2006-03-28)
No email
send info
  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.

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) (was Discuss) No Objection

Magnus Westerlund No Objection