From 55ff37a7d956cd662ecf5977f92b4468a0af2e7f Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Tue, 12 Jun 2012 15:33:35 +0100 Subject: [PATCH] Further FMUC updates --- xep-0289.xml | 40 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 36 insertions(+), 4 deletions(-) diff --git a/xep-0289.xml b/xep-0289.xml index 00140d89..5f501dfc 100644 --- a/xep-0289.xml +++ b/xep-0289.xml @@ -48,10 +48,12 @@

As MUCs are generally self-contained entities with a single address, federating them requires the introduction of some new terminology:

For illustration: if room1@rooms.server1.lit and room2@rooms.server2.lit federate with each other, then room1@rooms.server1.lit is an FMUC node, as is room2@rooms.server2.lit. Both nodes are in the FMUC set (along with any other node rooms that mutually federate) while the conceptual single room created by joining the FMUC set together is the FMUC room (and this FMUC room does not have a single definitive identifier).

@@ -112,9 +114,14 @@ ]]> -

Now rabbithole may reject the join, if elsinor is not permitted to federate

+

Now rabbithole may reject the join, if elsinor is not permitted to federate. To do this it sends a 'presence' reply from its bare JID to the bare JID of the joining node with an 'fmuc' payload containing a 'reject' element and MAY include a human-readable explanation as the text content of the 'reject' element.

+ + No cross-domain federation. + + ]]>

Or it may accept the federation request and reply with the list of current occupants and message context in the same order as specified in XEP-0045. Note that the fmuc element is always added containing the JID of the user (possibly passed down from other FMUC nodes, or indeed from the joining node for the presence of the user used for the initial join), while the XEP-0045 rules apply for whether to include the jid in the muc#user element.

@@ -290,7 +297,6 @@

When a user leaves a room the presence is distributed in the same way.

-

Note: when the last user on an FMUC node that has been joined to another (this is the "joining node" not the "joined-to node") leaves the room the joining node has no more users in the joined-to node and the joining node will be considered to have left the FMUC set. Further activity on the joined-to node will not be sent to the joining node unless a user joins the joining node causing it to re-join. I am aware that this is a horrible description - I intend to fix it to be comprehendable.

@@ -321,6 +327,15 @@ +]]> +

When the last user on a joining FMUC node leaves the room the joining node has no more users in the joined node and the joining node will be considered to have left the FMUC set. Further activity in the FMUC set not be sent to the joining node (unless it subsequently rejoins the set).

+

The joined room confirms that the joining room has left the set by sending a presence stanza from the bare JID of the joined room to the bare JID of the joining room with an FMUC payload containing an element 'left'.

+ + + + + ]]> @@ -333,6 +348,24 @@ + +

When sending a private message to an occupant of another node, each node that receives it is responsible for routing it to the appropriate node (or the occupant, if local).

+ + Hi, I want to say something in private + + + + + Hi, I want to say something in private + + + + Hi, I want to say something in private + + +]]> + @@ -357,7 +390,6 @@

How to get the join-target to tell the joining room how much history to send during a resync.

How to perform a resync (Part and then full rejoin)

Illustrate master-slave mode - this is simply that the sending room waits for the echo back from the room to which it's joined before distributing messages locally.

-

Describe private messages (simply relayed)

Describe collisions. Send fmuc payload saying there's a collision back to the node, Node with local user can then send an error message about the collision and kick them.