From 954811eb0d4f643c04466b0007506759e10b4a9e Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Mon, 28 May 2012 17:06:32 +0100 Subject: [PATCH] Significant rework - layout should be a little clearer and protocol more current. Still needs lots of wordsmithing and TBD-completion. --- xep-0289.xml | 482 ++++++++++++++++++++++++--------------------------- 1 file changed, 229 insertions(+), 253 deletions(-) diff --git a/xep-0289.xml b/xep-0289.xml index deb02dcb..a46b34fa 100644 --- a/xep-0289.xml +++ b/xep-0289.xml @@ -24,7 +24,7 @@ &ksmithisode; 0.2 - 2012-03-15 + 2012-05-29 kis

Reworking for new protocol and clarity of purpose.

 @@ -50,6 +50,8 @@
  • FMUC set - the union of all MUC rooms that federate together
  • FMUC node - a single MUC room that is a member of an FMUC set
  • FMUC room - a room represented by an FMUC set
    • +
  • Master-Master mode - two FMUC nodes operating such that both will continue to work when a network fails between them. This mode has the properties of reduced network traffic and of not having a guarantee of consistent message ordering between nodes
    • +
  • Master-Slave mode - two FMUC nodes operating where one, the master, will continue working during a network outage while the slave will cease to work while it cannot communicate with the master. This mode has increased network traffic and a consistent message delivery order across both nodes.

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

    @@ -76,8 +78,8 @@
  • rooms.wonderland.lit - MUC service on wonderland.lit.
  • alice@wonderland.lit - User on wonderland.lit
  • hatter@wonderland.lit - User on wonderland.lit
    • -
  • rabbithole@rooms.wonderland.lit - MUC room / FMUC node.
    • - +
  • rabbithole@rooms.wonderland.lit - MUC room / FMUC node.
    • +
  • denmark.lit - service, likely connected to wonderland.lit over constrained link
  • talk.denmark.lit - MUC service on denmark.lit.
  • hamlet@denmark.lit - User on denmark.lit
    • @@ -88,288 +90,255 @@ - - -

    kev@remote.example.com/Swift joining jabberchat@talk.example.com through a pre-known mirror.remote.example.com service. At this point mirror.remote.example.com knows nothing of the jabberchat@talk.example.com MUC, and no existing proxying is in place beyond mirror.remote.example.com being willing to proxy for kev@remote.example.com

    + +

    Here hamlet@denmark.lit is going to join the (currently empty) elsinor@talk.denmark.lit room. This room is configured as an FMUC node, federating with the rabbithole@rooms.wonderland.lit node, which current has one occupant - alice@wonderland.lit. The method of configuration that elsinor should federate with rabbithole is considered out of scope for this document - it is suggested that it be including in the standard MUC room configuration form. Note that this configuration only needs to be one way (that is: there is no protocol reason why rabbithole needs to know that elsinor will be federating with it in advance) - this allows for the ad-hoc addition of additional nodes to the FMUC room.

    +

    First hamlet@denmark.lit issues a normal MUC join request to elsinor@talk.denmark.lit

    - - + + ]]> -

    mirror.example.com then un-escapes 'jabberchat\40talk.example.com', and joins jabberchat@talk.example.com (the master), saying it's a room mirror.

    +

    Elsinor then attempts to join with the FMUC node rabbithole@rooms.wonderland.lit.

    - - + + + + + + ]]> -

    jabberchat@talk.example.com recognises that the mirror service is now mirrorring it, and performs the usual ACL checks as if kev@example.com/Swift had joined directly, sending presence to all occupants as normal. For all in-room routing, the slave is now treated as an occupant, and the slave is expected to do fan-out to its users as it is itself a MUC.

    +

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

    - - - - - + -

    The slave then fans-out.

    +

    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.

    +

    As part of the initial join of one node to another, the node being joined will send the current topic to the node doing the joining. The node receiving this (the joining node) SHOULD replace its own subject with the received one.

    +

    The joining node may add an element to the initial presence to the node being joined limiting the amount of history to be sent in the normal manner, as in XEP-0045.

    - - - - - -]]> -     - -

    If the master doesn't allow the user to join, they send the standard MUC error to the slave. Note that for stanzas sent to a user on the slave (such as this join error), it sends to the full MUC JID of the user on the slave, not to the slave room as it does with most other stanzas.

    - - - - - - - -]]> - -

    The proxy then delivers this to the user

    - - - - - - - -]]> -     - - -

    Now when a user joins the master directly it will do usual presence distribution to occupants (remembering the slave is an occupant). Status codes are omitted from this example, see &xep0045; for those.

    - - - - -]]> - - - - + + + + - - - + + + + + + + + This is an old message from the history + + + + + + This is another old message from the history + + + + + + This is the subject + + ]]> - - - - + +

    Upon receiving the occupants, history and subject from the other node the joining FMUC node will process these in the normal way, treating the received presence as joins, adding the history to the room's history (re-ordering by delay?) and changing the subject. The joining FMUC node MUST NOT send the traffic generated by these data back to the joined room, but only deliver them to local participants (and in the case of chained FMUC nodes, any nodes joined to it). It also MUST NOT pass the fmuc payloads through to local clients.

    + + + + + + + + + + + + + This is an old message from the history + + + + + This is another old message from the history + + + + + This is the subject + + +]]> +     + +

    Then hamlet@denmark.lit sends a message to the FMUC room, which is sent from the elsinor node to the rabbithole node and then broadcast to the local occupants of each room according to the standard XEP-0045 rules (rabbithole distributes to alice, elsinor distributes to hamlet). This example is for master-master mode, so rabbithole does not echo the message back to elsinore and elsinore does not need to wait for receipt of this stanza from rabbithole before distributing the stanza locally.

    + + + Hi Alice + + + + Hi Alice + + + + Hi Alice + + + + + Hi Alice + + +]]> + +

    alice@wonderland.lit then replies to this message, causing a similar distribution.

    + + + Hi Hamlet + + + + Hi Hamlet + + + + Hi Hamlet + + + + + Hi Hamlet + + +]]> + +     + +

    Another user joining or parting a room will be "fanned-out" in much the same way - the node to which they're joined will send out their presence to all the locally joined users and to the other FMUC nodes to which it's connected, and those nodes will then do the same - noting that in master-master mode they won't distribute the stanza back to the node from which they received it.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This is the subject + + + + + + + + + + + + + + + + +]]> + +     + +

    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.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> -     - - -

    The flow for a user leaving the proxy room is much the same as joining the proxy room:

    - -]]> - -]]> - - - - - - - - - - - - -]]> - - - - - - - -]]> + +

    When an FMUC node receives notice that one of their users has been kicked by a moderator on another node it SHOULD kick the user and fan-out the consequent presence stanzas to other nodes.

    +

    Role change should be distributed across nodes and fanned out to users, but only cosmetically (e.g. an owner on another node cannot effect changes to the affiliation lists on this node).

    + +     -

    When the master MUC receives a parting presence from the only user of the proxy, the proxy itself also leaves the room. This means that as long as no users of the proxy are in the room, it is causing no traffic on the s2s link.

    -     - - - -

    Distribution of presence for users parting when connected directly to the MUC is identical to distribution of presence for users joining directly to the MUC.

    -     - - -

    Distribution of presence for users changing status is the same as that for joining and parting.

    -     - - -     - - - -

    Normal fan-out like presence

    - - [[Unclassified]] It's getting warm in here. - -]]> - - [[Unclassified]] It's getting warm in here. - -]]> -

    If the proxy is not using fire and forget mode (see below), it MUST NOT fan out this message to local users until it receives the message copy from the MUC.

    - - [[Unclassified]] It's getting warm in here. - - - - [[Unclassified]] It's getting warm in here. - -]]> -

    When receiving the message copy, the proxy MUST then distribute to proxied occupants.

    - - [[Unclassified]] It's getting warm in here. - -]]> -     - -

    When dealing with very constrained s2s links, the extra round-trip involved with the MUC sending the message back to the proxy may be unacceptable. In this case, the proxy MAY include the <nomirror> element. If the MUC receives a message from a proxy with <nomirror>, it MUST NOT resend this message to the proxy during its usual fan-out, but MUST send it to other occupants as usual. If sending a message with <nomirror>, the proxy MUST perform fan-out as if the MUC had sent the message back to it.

    -

    Note that this use introduces unfortunate side-effects, such as messages appearing out of order, depending on whether connected directly to the MUC, or through a proxy. Also, messages rejected by the MUC may already have been delivered to users on a proxy. As such, a proxy SHOULD only use <nomirror> in environments where these side-effects are understood.

    - - [[Unclassified]] It's getting warm in here. - -]]> - - [[Unclassified]] It's getting warm in here. - - -]]> -

    If the proxy is using fire and forget mode, it MUST fan out this message to local users now, instead of waiting until it receives the message copy from the MUC.

    - - [[Unclassified]] It's getting warm in here. - -]]> -

    Because this is fire and forget mode, the MUC now MUST NOT send the message back to the proxy, but MUST send to the other occupants.

    - - [[Unclassified]] It's getting warm in here. - -]]> -     - -     - - -

    To perform administration of the MUC, connect directly to the MUC and follow the standard process.

    -     -     -

    This allows a MUC mirror to proxy for another JID, so should only be deployed in scenarios where either the proxy service is trusted, or it is known that the users of the proxy service are in the same security domain as the proxy service.

    +

    This allows an FMUC node to proxy for another JID, so should only be deployed in scenarios where either the FMUC nodes are trusted, or it is known that the users of an FMUC node are in the same security domain as the FMUC node itself.

     + +

    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.

    +

    None.