[Standards] MUC rooms on roster.
elmex at x-paste.de
Fri Aug 3 09:10:28 UTC 2007
On Fri, Aug 03, 2007 at 10:13:20AM +0200, Tomasz Sterna wrote:
> I was talking with Grégoire Menuel (mu-conference developer) about
> implementing Peter's idea of MUC rooms as items on the roster.
> Basically the idea is to teach MUC component to answer to subscription
> So when you add room at conference.server/nick to the roster and send the
> subscribe request, MUC server replies subscribed+subscribe to you. When
> you accept, you have a room on the roster with subscription "both". Next
> time you broadcast your presence, you automatically join the room.
Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ?
That would still be useful to store non-autmatically-joined MUCs I guess?
Also that XEP offers also a way to auto-join MUCs.
> There is a problem on the client side though.
> How would client know, that the presence from room at conference/* are from
> room participants, not from many resources of room at conference user (not
> on roster, thus ignored).
That works (see below) but there is a more pressing problem here:
Example 17. Jabber User Seeks to Enter a Room (Multi-User Chat)
from='hag66 at shakespeare.lit/pda'
to='darkcave at macbeth.shakespeare.lit/thirdwitch'>
How does the client or the server know that he has to include such an
<x xmlns='http://jabber.org/protocol/muc'/> element in the presence?
If the client does send it's initial presence it of course won't include that
element. So either the client sends directed presence or the server knows
somehow what room at conference is, so it can include the <x> element.
Exploiting the fact that presences without <x> also work for joining a MUC
would at least break this SHOULD in XEP-0045:
MUC clients SHOULD signal their ability to speak the MUC protocol by
including in the initial presence stanza an empty <x/> element qualified by the
Also there is this issue:
Before attempting to enter the room, a MUC-compliant client SHOULD first
discover its reserved room nickname (if any) by following the protocol defined
in the Discovering Reserved Room Nickname section of this document.
The client has to do that before sending initial presence, right?
If those issues, and some I don't know yet, are cleared up the client
can easily recognize the presences from occupants by the <x> element:
Usually a participant presence looks like this:
from='darkcave at macbeth.shakespeare.lit/thirdwitch'
to='wiccarocks at shakespeare.lit/laptop'>
<item affiliation='member' role='participant'/>
Or the update looks like:
from='darkcave at macbeth.shakespeare.lit/secondwitch'
to='crone1 at shakespeare.lit/desktop'>
<status>gone where the goblins go</status>
jid='wiccarocks at shakespeare.lit/laptop'
With the <x xmlns="...muc#user"> element the client can figure out that this
is a presence that comes from a MUC.
More information about the Standards