Michal vorner Vaner
michal.vaner at kdemail.net
Thu Sep 28 22:01:38 UTC 2006
On Thu, Sep 28, 2006 at 02:34:06PM -0600, 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.
I guess it will end up at this anyway, as today clients do not know
about re-authorizing so server will have to "force" them by
reconnecting. And new clients will not see (I guess) too much interest
in implementing this. Not much gain, if you are disconnected and
I must admit it would be hard to accomplish with an architecture I'm
trying right now, connection by external program that connects, makes
TLS and SASL, possibly bind resource and start the session and then just
stops caring about the data it sends/receives and just pipes them to
stdou/from stdin. I know it is implementation problem, but some kind of
re-authorization does not much fit fit with the idea of re-established
streams to me.
I would have an idea of some kind of <not-authorized/> with some more
description and some (short) time, until the server sends unavailable
presence to pretend to others the client did not disconnect if the
client reconnects. This will work with all actual clients as well, if
they have some kind of auto-reconnect.
> Keeping things the way they are now has the advantage of being simple...
When a fly lands on the ceiling, does it do a half roll or a half loop?
Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards