[Standards] Proposed XMPP Extension: Private Multi-User Conferencing

[Bruce Campbell]

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 
into).

-- 
   Bruce Campbell.