[Standards] XEP-0045 to Final?

Peter Saint-Andre stpeter at stpeter.im
Wed Mar 5 10:35:51 UTC 2014


A: Because it messes up the order in which people normally read text.

Q: Why is top-posting so bad?

A: Top-posting.

Q: What is the most annoying behavior on email discussion lists?

On 3/5/14, 10:16 AM, Christian Schudt wrote:
> Hi,
> could you elaborate on this proposal a little bit, please?

Could you elaborate a bit on the use case and the need for it? I'm not 
saying it's bad or irrelevant, but XEP-0045 was not designed to solve 
every possible problem related to groupchat.

> The room creator/owner publishes a node to a pubsub service, which contains all room members and each invitee subscribes to this node (which is equal to the room JID?)?
> What about the case, when a member invites further members? He would have to modify to original node. I imagine that would be cumbersome to develop, when you have to sync MUC affiliations and PubSub affiliations (on top of the already complex pubsub management).
> It would be so much easier to just allow 7.11 Getting the Memberlist also for the Entity Use Cases, so that an entity could just query a room for it's members (without having joined the room):
> <iq from='crone1 at shakespeare.lit/desktop'
>      id='member3'
>      to='coven at chat.shakespeare.lit'
>      type='get'>
>    <query xmlns='http://jabber.org/protocol/muc#admin'>
>      <item affiliation='member'/>
>    </query>
> </iq>
> Maybe return a stanza error, if the requester is no member of the room.

That's what I would suggest.

Since that solves the problem, I'm wondering why you asked the question. 
:-) That is, is there some aspect of the problem that 
http://xmpp.org/extensions/xep-0045.html#disco-roomitems does not solve? 
(Section 7.11 is about occupants who are already in the room.)


> Christian
> Gesendet: Mittwoch, 05. März 2014 um 10:54 Uhr
> Von: "Winfried Tilanus" <winfried at tilanus.com>
> An: standards at xmpp.org
> Betreff: Re: [Standards] XEP-0045 to Final?
> On 01-03-14 18:04, Christian Schudt wrote:
> Hi,
>> I recently was confronted with the following requirement: Create a
>> (non-public members-only) room, grant membership to X contacts and
>> send an invitation to these X contacts.
>> Then after receiving the invitation, but BEFORE joining the room, the
>> invitee should discover the members in the room and decide (based on
>> this information) if he wants to join the room or if he should
>> decline the invitation.
> You may consider to use pubsub in cases like these.
> Winfried

More information about the Standards mailing list