[Standards] Proposed XMPP Extension: Private Multi-User Conferencing
b+jabber at bruce-2007.zerlargal.org
Tue May 15 19:06:49 UTC 2007
On Tue, 15 May 2007, Andreas Monitzer wrote:
> On May 15, 2007, at 19:44, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> Title: Private Multi-User Conferencing
>> Abstract: Jabber client pretends to be a Multi-User Conference server
> This XEP sounds very interesting to me...
> Could you include a description on how to handle multiple PMUC rooms? It's
> mentioned in the sentence "The central client, should it actually receive
> such stanzas, MUST forward such stanzas onward as described above without
> penalty to the sending client, UNLESS it is managing multiple private
> conferences.", but that's it.
Its mentioned in passing in two notes prior to this, around mentions of
the 'roomsubmit' resource.
Essentially the document is a slight stretch of MUC to allow the address
used to send messages to the room be a full JID, instead of a bare JID.
Apart from ensuring that the messages to the apparent 'room' are sent to
the instance of the client actually handling the room, it also lets the
central/hosting client have multiple PMUC rooms by binding a seperate
Resource (eg, crone1 at shakespeare.lit/roomsubmit,
crone1 at shakespeare.lit/randomstring) for each PMUC room.
> I don't quite understand how receiving clients should be able to
> differentiate multiple PMUCs, since the messages would all originate from
> <PMUC-hoster's jid>/<sending nick>
The differentiation in this case would rely on the <sending nick> being
unique across all PMUC rooms hosted by a single client.
Eg (using names from the document), if hag66 at shakespeare.lit/pda is in two
PMUC rooms managed by the same central/hosting client,
(crone1 at shakespeare.lit/cauldron and crone1 at shakespeare.lit/forest), the
only way for hag66 to distinguish between the two rooms is by two
different participant lists:
crone1 at shakespeare.lit/cauldron has
crone1 at shakespeare.lit/firstwitch (crone1)
crone1 at shakespeare.lit/secondwitch (wiccarocks)
crone1 at shakespeare.lit/thirdwitch (hag66)
crone1 at shakespeare.lit/forest has
crone1 at shakespeare.lit/1stwitch (crone1)
crone1 at shakespeare.lit/2ndwitch (wiccarocks)
crone1 at shakespeare.lit/3rdwitch (hag66)
In writing this, I'd assumed that if a single client handled multiple PMUC
room, there would be no overlap between the participant lists, except for
possibly the central/hosting client (which has other means of
differentiation at its disposal, such as which window the User typed
More information about the Standards