[Standards-JIG] NEW: JEP-0140 (Shared Groups)

Ian Paterson ian.paterson at clientside.co.uk
Thu Jul 29 13:22:20 UTC 2004


JEP-140 states "It is OPTIONAL for the NodeID to include the name of the
group". But, if it doesn't include the group name, then when an admin
removes a group member, how will the subscribers know which group the jid
was removed from?

It is easy to imagine common real-world scenarios where the jid should not
be removed from all groups.

Clients should not be expected to remember which group in its roster is
associated with each subscription.

Maqi wrote:
> "It is the receiving application's responsibility to add the
> newly-published roster item to the recipient's roster" - if the client
> really directly inserts contacts distributed via PubSub into the user's
> roster, this is a problem as any malicious server can insert arbitrary
> contacts then (as there's no way for a client to check whether the users
> is really subscribed to a pubsub node).

Good point. Do we need a new JEP that specifies how clients can maintain a
list of servers that their user trusts to *automatically* process pubsub
<event/> elements? (XMPP's privacy lists are not appropriate since the
privacy 'white' list would block all messages, not just those with <event/>

> (even prepopulated rosters can't be done with it).

How about a new 'PubSub Node Exchange' JEP that specifies how to send a
pubsub node to another entity (similar to the way JEP-93 Roster Exchange
allows a roster item to be sent to another entity)? Of course it would still
be the responsability of the receiving client to subscribe the user to the
node and request all active items.

> Plus it needs client support currently (which could be solved by
> using the Roster Exchange protocol for distribution of contacts
> which would also solve the security problems).

I agree it is a shame not to leverage the existing client support for Roster
Item Exchange. On the other hand, JEP-93 still needs a roster item removal
use case.

How does JEP-93 solve the security problems? It still enables any malicious
client to insert arbitrary contacts - in the same way as a malicious server
could use JEP-140 (assuming the receiving client allows it).

> All in all, I think this JEP doesn't cover a significant
> number of the typical shared groups use cases

As you pointed out, JEP-140 doesn't cover everything yet, but it already
solves several of the central-administration issues (e.g. persistent central
storage). It also has the significant advantage of being built on a
fundamental protocol building block (pubsub).

More information about the Standards mailing list