On 10/30/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Vinod Panicker wrote: > > On 10/29/07, Tomasz Sterna <[EMAIL PROTECTED]> wrote: > >> Dnia 29-10-2007, Pn o godzinie 12:17 +0100, Michal 'vorner' Vaner pisze: > >>> No, it doesn't. Look at mcabber. You can be unavailable and still keep > >>> the connection. You can even send messages from unavailable resource. > >> You're right. > >> I definitely need to sleep more. > >> > >> But I would rather call it "bound" not "active". There may be no > >> activity on bound connection. :-) > > > > The definition as per RFC is "active", hence I stated that. I doubt > > there's a need to define yet another state :-) > > > > But really, a resource can ping-pong between active and available > > states by sending presence stanzas of available and unavailable > > respectively. > > > > Instead of changing a particular implementation that does what seems > > "right" and sends roster pushes to "active" resources instead of the > > "available" ones, I'd like this to be part of the new spec - with > > appropriate consensus, of course. > > What is the use case driving your desire to make this change? BTW, the > spec (both RFC 3921 and rfc3921bis) says this is a SHOULD (not MUST). If > you want to send roster pushes to active resources that have requested > the roster, feel free to do so on an experimental basis and report back > with your findings. I happen to think that the vast majority of clients > don't hang around in the active-but-not-available state, so I doubt that > there is a lot to be gained here. But again if you have some powerful > use cases, please do share them.
I had provided a basic use case in my original post and also a edge case that results in a wrong user experience. If the RFC is not mandating that the resources have to be in the available state, then I can change my implementation. Regards, Vinod.
