<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2010-03-15</date>
<initials>cvl/ph</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<pclass='box'><em>This document is one of several proposals for distributing XMPP chat rooms across multiple chat services. It is expected that the various approaches will be refined and harmonized before a final protocol is developed.</em></p>
<p>The architecture is that of a single root node, called MASTER and several repeater nodes, each called SLAVE. Every stanza is submitted via the slaves to the master, control is centralized there. The master then sends a copy of the stanza to each of the slaves where it is processed and then distributed to each of the slave's leaf nodes, local users at this point. During redistribution, the slave shall not change the stanza's 'from' attribute, which is only possible if the slave is in the same security domain as the user. The result of that is a decreased number of messages on the server-to-server links between the master's server and each of the slave servers.</p>
<p>Note that this only applies to stanzas that are directed to all occupants, such as the change of availability status and messages whose 'type' attribute is set to 'groupchat'.</p>
<p>While 1-1 stanzas such as in-room private messages or vcard-temp requests may also travel along that path they are currently unaffected by this.</p>
</section1>
<section1topic='Requirements'anchor='reqs'>
<p>This specification addresses the following requirements:</p>
<ul>
<li>The existence of the slave shall be transparent for the user.</li>
<li>Enable detection of connection loss.</li>
<li>Enable occupants to remain in instance of the conference if connectivity is lost to other instances.</li>
<li>Enable occupants to leave a chatroom while connectivity is lost.</li>
<li>Enable syncing of history and room rosters on reconnect.</li>
<li>Improve distribution of 'broadcast' stanzas'.</li>
<p>Most of the examples in this document use the scenario of the 1990 war that split the <cite>Internet Relay Chat</cite> into several incompatible networks. The battlefield is represented here by the "wallops@channel.avalon.irc" chatroom. The characters are as follows:</p>
<tablecaption='Dramatis Personae'>
<tr>
<th>Room Nickname</th>
<th>Full JID</th>
<th>Role</th>
</tr>
<tr>
<td>Wumpus</td>
<td>argl@killrc.oulubox.irc/laptop</td>
<td>Moderator</td>
</tr>
<tr>
<td>Valdis</td>
<td>valdis@killrc.oulubox.irc/desktop</td>
<td>Participant</td>
</tr>
<tr>
<td>Phaedrus</td>
<td>phaedrus@killrc.oulubox.irc/phone</td>
<td>Participant</td>
</tr>
<tr>
<td>WiZ</td>
<td>squit@eris.dclxvii.irc/jupiter</td>
<td>Moderator</td>
</tr>
<tr>
<td>Troy</td>
<td>troy@eris.dclxvii.irc/screwdriver</td>
<td>Moderator</td>
</tr>
<tr>
<td>BigCheese</td>
<td>rubenro@vesa.yeggmaex.irc/shaver</td>
<td>Participant</td>
</tr>
<tr>
<td>Efchen</td>
<td>msa@vesa.yeggmaex.irc/bicycle</td>
<td>Participant</td>
</tr>
</table>
<p>In our example we are presuming that three slaves from three hosts have registered with the master for traffic redistribution. They are doing so using slave@host jids, but they could be using any temporary jid the implementor finds useful to choose.</p>
<p>This section describes the protocol between the master and the slaves, the interaction between each slave and its users are described in the next section.</p>
<!--
<section2topic='Narrative Protocol Description'>
<p>some blabla</p>
</section2>
-->
<section2topic='Slave Requirements'>
<p>The slave</p>
<ul>
<li>must be able to intercept any stanzas sent to the masters jid,</li>
<li>must be able to verify if a local user has sent directed presence to the masters jid,</li>
<li>must store room roster,</li>
<li>must store local room roster</li>
<li>must store room history (if desired by master)</li>
</ul>
</section2>
<section2topic='Creating a Slave'>
<p>to follow</p>
<p>Might include things like negotiation of keepalive frequency and amount of room might be useful to set some things like keepalive frequency, keeping/storing room history etc.</p>
<!--
<p>maxstanzas / maxbytes attribute</p>
<p>PARANOIA: why should the slave let the master create the slave and send room roster and history?</p>
-->
</section2>
<section2topic='Initial Room Roster'>
<p>After the creation of a new slave, the master must send the room roster (which at that time only consists of remote participants) to the slave:</p>
<examplecaption="Master Sends Room Roster to Slave"><![CDATA[
<presence
from='wallops@channel.avalon.irc/Wumpus'
to='slave@vesa.yeggmaex.irc'>
<xxmlns='http://jabber.org/protocol/muc#user'>
<itemaffiliation='owner'role='moderator'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/Valdis'
to='slave@vesa.yeggmaex.irc'>
<xxmlns='http://jabber.org/protocol/muc#user'>
<itemaffiliation='none'role='participant'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/Phaedrus'
to='slave@vesa.yeggmaex.irc'>
<xxmlns='http://jabber.org/protocol/muc#user'>
<itemaffiliation='none'role='participant'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/WiZ'
to='slave@vesa.yeggmaex.irc'>
<xxmlns='http://jabber.org/protocol/muc#user'>
<itemaffiliation='admin'role='moderator'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/Troy'
to='slave@vesa.yeggmaex.irc'>
<xxmlns='http://jabber.org/protocol/muc#user'>
<itemaffiliation='participant'role='moderator'/>
</x>
</presence>]]></example>
<!--
<p>Tricky: if this does not contain the full jid, the (initial) presence information sent to moderators that join later will not be possible... mh!</p>
-->
</section2>
<section2topic='Initial Room History'>
<p>After the creation of a new slave, the master MAY also send the discussion history to the slave. The slave shall store this and deliver it to entering participants.</p>
<p>from=masterjid to=slavejid?</p>
</section2>
<section2topic='ENTER'>
<p>If a new occupant requests to enter the room, the master first sends a presence update to all participants to inform them of the presence of the new user. Then, the master sends the affected slave a stanza requesting it to add the user to the distribution list</p>
<examplecaption="Master informs Slave of New Occupant"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'>
<xxmlns='urn:xmpp:tmp:dmuc:0'>
<enterjid='rubenro@vesa.yeggmaex.irc/shaver'/>
<historymaxstanzas='20'/>
</x>
...
</presence>]]></example>
<p>The slave MUST verify that the user has sent directed presence to the masters JID before. This helps to ensure that the user intended to enter the room. If this is ture, the slave shall add the user to the distribution list and send the room roster, occupants own presence in room and discussion history to the full jid of the added user.</p>
</section2>
<section2topic='LEAVE'>
<p>If an occupant sends an unavailable presence to the room, the master sends the affected slave a stanza requesting it to remove the user from the distribution list.</p>
<examplecaption="Master informs Slave of Occupant's Departure"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'
type='unavailable'>
<xxmlns='urn:xmpp:tmp:dmuc:0'>
<leavejid='rubenro@vesa.yeggmaex.irc/shaver'/>
</x>
...
</presence>]]></example>
<p>The slave removes user and forwards the stanza to user.</p>
<p>The master then sends a presence update to all slaves to announce the occupants departure.</p>
</section2>
<section2topic='Presence Update'>
<p>Presence updates are distributed by the master to all slaves.</p>
<p>Note that the master MUST NOT send the full jid of the user to any slaves without members that are moderators.</p>
<p>When rebroadcasting this stanza to its local occupants, the slave MUST remove the participants full JID subject to the rules of XEP-0045. In addition, the slave stores the resulting changes to the room roster, so that it can send the correct state to entering users.</p>
</section2>
<section2topic='Slave Forwards Stanza to Master'>
<p>The slave may relay messages from local users to the master. When doing so, it MUST NOT modify the stanzas 'from' attribute but MUST retain the original address of the sender.</p>
<!--
<p>Die Regel ist relativ einfach... from=fulljid to=masterjid/undevtlresource</p>
<p>fulljid deshalb, damit der master nicht checken muss ob der jeweilige user auf dem slave ist und ausserdem der jeweilige user nicht zwangsläufig im Raum sein muss...</p>
<examplecaption="Slave Relays a Message to the Master"><![CDATA[
<message
from='rubenro@vesa.yeggmaex.irc/shaver'
to='wallops@channel.avalon.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
</message>]]></example>
<!--
<p>Some rules:</p>
<ul>
<li>The stanzas 'from' attribute MUST be retained.</li>
<li>Stanzas from participants and non-participants must be routed</li>
</ul>
-->
</section2>
<section2topic='Message Broadcast'>
<p>When relaying a message, the master SHOULD add a urn:xmpp:delay element inside dmuc element so that the slave can provide proper timestamps to new users. The master then sends a copy of the stanza to each slave.</p>
<examplecaption="Message from Master to all Slaves"><![CDATA[
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@killrc.oulubox.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<xxmlns='urn:xmpp:tmp:dmuc:0'>
<delayxmlns='urn:xmpp:delay'
from='wallops@channel.avalon.irc/BigCheese'
stamp='1990-10-13T23:58:37Z'/>
</x>
</message>
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@eris.dclxvii.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<xxmlns='urn:xmpp:tmp:dmuc:0'>
<delayxmlns='urn:xmpp:delay'
from='wallops@channel.avalon.irc/BigCheese'
stamp='1990-10-13T23:58:37Z'/>
</x>
</message>
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<xxmlns='urn:xmpp:tmp:dmuc:0'>
<delayxmlns='urn:xmpp:delay'
from='wallops@channel.avalon.irc/BigCheese'
stamp='1990-10-13T23:58:37Z'/>
</x>
</message>]]></example>
<p>After saving the stanza for the purpose of keeping a room history, the slave SHOULD remove the urn:xmpp:tmp:dmuc:0 element and send the stanza to each local user.</p>
</section2>
<section2topic='Master-Slave Keepalive'>
<p>To ensure a working connecting, the master SHOULD send an XMPP Ping stanza to each slave if there has been no traffic for a certain amount of time.</p>
<p>Likewise, each slave should ping the master if there has been no traffic for more than the usual amount of time.</p>
