[Standards-JIG] JEP-0030 - Disco to resources

Vinod Panicker vinod.p at gmail.com
Wed Apr 19 15:48:03 UTC 2006


On 4/19/06, Ralph Meijer <jabber.org at ralphm.ik.nu> wrote:
> On Wed, Apr 19, 2006 at 06:00:22PM +0530, Vinod Panicker wrote:
> > On 4/19/06, Ralph Meijer <jabber.org at ralphm.ik.nu> wrote:
> > > On Wed, Apr 19, 2006 at 10:06:49AM +0530, Vinod Panicker wrote:
> > > > [..]
> > > >
> > > > Can anyone please point me to an instance where "connected" resources
> > > > are being used for a practical purpose?
> > >
> > > I hope your question does not mean 'what is the point of having
> > > clients that don't send presence'?
> >
> > Not at all.  Just trying to understand use cases for having connected
> > and active states.
>
> Will, for example I use a non-presence sending bot for conveying my
> currently playing song using User Tune. This bot is constantly connected
> but not 'available'.

I was talking about connected and active, not connected and available.

> > > That said, having disco#info on a bare (IM account) JID to return
> > > resources that have not sent presence, will actually leak presence
> > > information.
> >
> > Right. That means that modifying JEP-0030 to say that disco should be
> > sent to only available resources would neither cause harm nor any dead
> > kittens?
>
> Why? I don't see a problem with people sending disco to
> connected-but-not-available resources. If you already know it exists (by
> having received a message from it, for example) there is no harm in
> this. My point was that it shouldn't show up in the list of items that
> are returned when doing disco#items to the bare JID.

Inferred from the various texts in the RFCs, connected and active
resources cannot receive messages, cannot receive directed iq's and
nor can they receive presence.  I'll quote all of them and the reason
for inference if you wish.  I'm far too tired to compile the list now
:(

Regards,
Vinod.



More information about the Standards mailing list