[Standards] Proposed XMPP Extension: Communities

[Yann Biancheri]

Hello,

We finally get time to review the xep and we have some few comments  
on it.

In the Use cases section:
2.1 Registering With a Community)
Once registration to the room is complete according to XEP-0045, I  
think the room will send a presence subscription request to the user.  
It's worth mentioning.

2.2 Being Invited to Join a Community) Example 9.
It's not clear to me how the client can differentiate a community  
invite to an user subscription request. User can for sure make some  
discovery on this JID but it implies to do so for every subscription  
request. Adding caps or a special x element would give the user some  
indication. Caps seems to be the 'XMPP way' to do it.

2.3 Sharing Presence With the Community)
Xep mentions: "A client MAY also subscribe to the presence of the  
community, but a bidirectional subscription is not necessary to  
enable the community functionality." I'm a bit unsure on how this  
should work with this use cases.
When user logins, he has a sub=from to the community. Despite this,  
community will send a directed presence to the user when he connects.  
This seems a bit awkward but I'm ok with it, but I have some few  
questions:
How should the MUC behaves when presence sub=both. Should the MUC  
service (communities.shakespeare.lit) answers to presence probe for  
the MUC room (characters at communities.shakespeare.lit)?
- If yes then room will have to behave in a different way depending  
of the sub status as when sub=both presence will be sent in answer to  
presence probe and if sub=from it'll be sent as an answer to the  
presence from the user. It doesn't seem desirable to me.
- If no then why what's the use of allowing sub=both, seems to create  
more confusions than solving issues.

In addition, if the room accepts subscription from users it'll then  
have to store this sub state somewhere. This MUC room roster might be  
a duplicate of the room member list depending on the community  
configuration. We'll then have to store some informations twice (MUC  
room roster and MUC room member list). To prevent this we can define  
some mappings between memberlist and muc room roster but it'll had  
complexity and won't serve any use cases. Simplest seems to allow  
only sub=from. Room shouldn't allow sub=both.



I think it'll be good to add two use cases to the XEP, specifically  
how and when room should unsubscribe to presence:
- Unregister to a community
- Being kicked from the community

Concerning authors, here are my valid contact informations:
mail: ybiancheri at wimba.com
jid: yann.biancheri at gmail.com

Could you also please add romain:
mail: rvincens at wimba.com
jid: romain.vincens at gmail.com

--
Yann Biancheri


On Aug 29, 2007, at 9:21 PM, XMPP Extensions Editor wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Communities
>
> Abstract: This document specifies an XMPP protocol extension for  
> centrally-managed contact lists that can be shared among all the  
> members of a particular community of interest.
>
> URL: http://www.xmpp.org/extensions/inbox/communities.html
>
> The XMPP Council will decide at its next meeting whether to accept  
> this proposal as an official XEP.
>