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 ([EMAIL PROTECTED])?
- 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: [EMAIL PROTECTED]
jid: [EMAIL PROTECTED]
Could you also please add romain:
mail: [EMAIL PROTECTED]
jid: [EMAIL PROTECTED]
--
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.
