Right, and this will be captured in rfc3920bis. /psa
JD Conley wrote: > One important thing I forgot to mention. > > > > There are actually two paths the exchange might take. The SASL PLAIN > payload may be included in the <mechanism> element by the client as an > initial response (and this is the recommended method). However, it is > not required. So if you’re building a server you need to also handle an > empty <mechanism> element, send back an empty <challenge>, and expect a > <response> with the payload. > > > > -JD > > > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *JD Conley > *Sent:* Monday, July 31, 2006 8:55 PM > *To:* Jabber software development list > *Subject:* RE: [jdev] Re: sasl plain > > > > Yeah, that’s it. You can test client implementations against our public > server at soapbox.net if you want. > > > > -JD > > > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Tong > *Sent:* Monday, July 31, 2006 8:34 PM > *To:* [email protected] > *Subject:* [jdev] Re: sasl plain > > > > Ok, I think > http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-09.txt should > be the one. > > On 7/31/06, *Tong* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Does anybody know where I can find more information about the PLAIN > mechanism for SASL? I went through XMPP Core and the SASL > (http://xml.resource.org/public/rfc/html/rfc2222.html), but still can't > find exactly what the sequence of exchanges between the client and > server should be. What I'm looking for is the exact sequence of messages > between the client and server after the client selects the PLAIN > mechanism. Any pointer is appreciated. > > >
smime.p7s
Description: S/MIME Cryptographic Signature
