sneakin at semanticgap.com
Thu Sep 28 21:09:58 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Peter Saint-Andre wrote:
> Section 3.8 of RFC 4422 states:
> Unless explicitly permitted in the protocol (as stated in the
> protocol's technical specification), only one successful SASL
> authentication exchange may occur in a protocol session.
> Given that XMPP connections can be long-lived (you could be connected
> for weeks or months!), it seems that we might want to define a way for
> the server (i.e., receiving entity) to request re-authentication by the
> initiating entity. (For example, perhaps the X.509 certificate you used
> while authenticating expires during your session.)
> On the other hand, I suppose the server could simply close the stream
> with a <not-authorized/> error, but that's not very friendly.
> Keeping things the way they are now has the advantage of being simple...
If you want to consider allowing re-authentication, then you should
stick with the way XML is used:
<!-- do SASL -->
<!-- bind resource & start session -->
<!-- jabber away -->
<!-- re-auth w/ SASL -->
<!-- you know the drill -->
Currently the "</stream:stream>" also kills the underlying TCP stream,
which also causes the stream to be invalid XML. This would be the way to
go for re-authentication. It could also allow you to back up and turn on
other features such as encryption or compression if you decide you want
that later on in the session.
The one consideration would be that characters that XML forbids would
need to be escaped and ideally wrapped in a CDATA section.
- - Nolan
SemanticGap: To act as one (TM) -- http://www.semanticgap.com/
Instant awareness & messaging * Online presence design
Cross platform and agile development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 207 bytes
Desc: not available
More information about the Standards