[JDEV] possible defect in RosterList behavior

Tue Feb 13 16:44:27 CST 2001

Keith,

Thanks for the follow up.

I understand your justification and mostly agree with it. The only minor
issue I would point out is that it is possible (in a single client
environment) for the client to know the roster list without requesting it.
Out client maintains its own list which is populated by watching the roster
items downstream after it issues roster updates. (It holds updates as
pending until confirmation is received from the server.) Following this
strategy, the client should never have to request the whole list.

That said, I do see benefit for other clients in the behavior you have
spec'ed. We will continue to use our workaround which is to request the
roster list even though we don't use it.

thanks again,

-J

-----Original Message-----
From: Keith Minkler [mailto:kminkler at jabber.com]
Sent: Tuesday, February 13, 2001 2:13 PM
To: jdev at jabber.org
Subject: Re: [JDEV] possible defect in RosterList behavior

Jay,

    This behavior is definitly by design.  The Roster updates come in the
form of roster "pushes".  You must first request the roster, so that you
have a working copy of the roster, in order to recieve any changes.  since
pushes only represent a *change* to the roster, that is of no use to a
client, unless they have the full roster to change.  

    This behavior is also due to the fact that if a simple client (i.e. one
that does not even have a roster) does not request the roster from the
server, that means that they do not wish to have any thing to do with the
roster.. therefore, the server should not be sending it roster updates, as
the simple client does not even display the roster. (i.e. when another
client changes the roster, it gets sent to all connected clients that have
requested roster updates).

    NOTE also, that a similar effect is true for subscription(s10n)
notices.. you will not get any s10n requests if you have not sent you
presence, due to the same logic.. If a simple client, or an "invisible"
client does not send their presence, then they want nothing to do with
presence based notifications at all.

    It will be possible in the future for clients to also tell the server
what kinds of messages they wish to handle.. i.e. a client can notify the
server that they can *ONLY* handle headlines, all other messages will be
routed to another client, or stored offline.

    Hope this helps,
        Keith Minkler

On Tue, Feb 13, 2001 at 02:03:03PM -0800, Jay Chalfant wrote:
> I noticed today that I won't get any roster item updates from Jabber
server
> until I request the entire roster list. Specifically, unless I first do a 
> 
> <iq id="doroster_4" type="get">
>   <query xmlns="jabber:iq:roster" /> 
> </iq>
> 
> I won't get roster updates as I make changes to the roster. I don't see
any
> documentation that justifies this behavior so I assume it is a defect. I
> believe it should be considered a defect because the protocol should not
> require a client to retrieve the roster list every time it connects just
to
> be able to use the roster list. (We have a specific justification for not
> receiving the roster list on every request.)
> 
> Here is a sample sequence (ignore the xml annotation):
> 
> - <jabberproxy_add_buddy>
> - <SEND>
>   <presence type="subscribe"
to="jchalfan at aimtrans.internal.outbackinc.com"
> /> 
>   </SEND>
> - <SEND>
> - <iq id="982087708" type="set">
> - <query xmlns="jabber:iq:roster">
>   <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="_jchalfan"
/> 
>   </query>
>   </iq>
>   </SEND>
> - <RECV>
>   <iq id="982087708" type="result" from="a at billabong/I at P"
> to="a at billabong/I at P" /> 
>   </RECV>
> - <RECV>
> - <presence to="a at billabong"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Idle 0 Minutes</status> 
>   </presence>
>   </RECV>
>   </jabberproxy_add_buddy>
> 
> This sequence occured in a session in which I had not requested the whole
> roster list. If I do request the roster list first, I get what I consider
is
> a "normal" protocol behavior which includes the 4 (!) roster updates and
the
> reverse subscribe request as shown below.
> 
> - <winjab_add_buddy>
> - <SENT>
> - <iq id="JCOM_34" type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan">
>   <group /> 
>   </item>
>   </query>
>   </iq>
>   </SENT>
> - <SENT>
> - <presence to="jchalfan at aimtrans.internal.outbackinc.com"
type="subscribe">
>   <status>Normal Subscription Request</status> 
>   </presence>
>   </SENT>
> - <RECV>
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="none">
>   <group /> 
>   </item>
>   </query>
>   </iq>
>   </RECV>
> - <RECV>
>   <iq id="JCOM_34" type="result" from="a at billabong/a_310"
> to="a at billabong/a_310" /> 
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="none" ask="subscribe">
>   <group /> 
>   </item>
>   </query>
>   </iq>
> - <presence to="a at billabong" type="subscribed"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Normal Subscription Request</status> 
>   </presence>
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="to">
>   <group /> 
>   </item>
>   </query>
>   </iq>
> - <presence to="a at billabong" type="subscribe"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Normal Subscription Request</status> 
>   </presence>
> - <presence to="a at billabong"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Idle 0 Minutes</status> 
>   </presence>
>   </RECV>
> - <SENT>
>   <presence to="jchalfan at aimtrans.internal.outbackinc.com"
type="subscribed"
> /> 
>   </SENT>
> - <RECV>
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="both">
>   <group /> 
>   </item>
>   </query>
>   </iq>
>   </RECV>
>   </winjab_add_buddy>
> 
> Can someone please clarify if this is a bug or a "feature".
> 
> thanks,
> 
> -J
> 
> 
> 
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev