[standards-jig] Invisibility Support in Jabber

Iain Shigeoka iain.shigeoka at messaginglogic.com
Wed Aug 14 02:39:01 UTC 2002

On 8/12/02 1:14 PM, "Joe Hildebrand" <jhildebrand at jabber.com> wrote:

> Iain Shigeoka <iain.shigeoka at messaginglogic.com> writes:
>> I reviewed my docs and it looks like it won't help out as much as
>> I'd hoped without major changes to the way rosters are handled.  WV
>> allows multiple contact lists (rosters) for a particular user and
>> separates the idea of subscriptions from rosters which makes it a
>> bit easier to manage.  I think for now your proposal is the simpler
>> and more practical way to do this.
> I wonder how this is different from roster groups today, other than
> the fact that WV has a default group?  Yes, you can't retrieve a group
> at a time, but other than bandwidth, the functionality is basically
> there.

It is not much different technically.  However, in Jabber rosters are sort
of separate worlds from messaging.  You can't address a roster [1], only
resources or users.  Rosters are more of a service accessed via a special iq
extension completely separating it from the rest of the messaging system.
This makes it hard to do anything to a particular roster, like send them
presence or messages without iterating through your rosters then manually
generating the packets.

WV makes rosters first class resources [2].  You can send messages to
rosters or anything other action you can do with a node.  This makes
broadcast messages dead simple in WV because you just send things to the
contact list id and it gets propagated by the server properly to the contact
list members.  Obviously there is power in this approach beyond invisibility

Technically, this could be easily added to Jabber by just setting aside
specific resource names for rosters and having the server act accordingly.
I think from a messaging model standpoint though it is quite a change
because it moves rosters from a server-side service into a messaging entity
and further strains the confusion currently surrounding rosters which are
already spread across presence (subscriptions) and iq (roster).  Adding
messaging basically makes rosters the only feature of Jabber that would be
accessed by every major jabber core protocol!

I'm not sure if it is a potential major source of trouble or me just making
a mountain out of a mole hill.  From a clean design standpoint, I think
roster should probably have its own root level tag <roster> and keep
presence pure presence (move subscriptions into <roster> and all the iq
roster stuff into <roster>)...  That of course is really drastic and
probably something for JNG... Something I hate to keep saying. :)


[1] Jabber lacks a standard JID for contact lists... Er... Rosters
[2] There are standard WV IDs for contact lists wv:iain/friends at server.com

More information about the Standards mailing list