[jdev] Possible inconsistency with roster pushes

Vinod Panicker vinod.p at gmail.com
Wed Oct 31 04:24:03 CDT 2007

On 10/30/07, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Vinod Panicker wrote:
> > On 10/29/07, Tomasz Sterna <tomek at xiaoka.com> 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.


More information about the JDev mailing list