Multiple XEPs: Cross-document editorial adjustments for inclusive language.
Further reading and some rationale for these changes can be found at:
https://tools.ietf.org/html/draft-knodel-terminology-04
All changes are intended to be editorial in nature, not break existing
wire protocols, and not alter the meanings of any text.
<p>An entity that supports Jabber-RPC SHOULD establish a "whitelist" of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.</p>
<p>An entity that supports Jabber-RPC SHOULD establish a permitted list of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.</p>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.3</version>
<date>2009-06-03</date>
@ -419,7 +425,7 @@
@@ -419,7 +425,7 @@
</query>
</iq>
</example>
<p>To determine any further details from this list, each child would have to be browsed. The elements within the icq service are only hints to a client for building user interface elements. The icq.jabber.org service would still need to be browsed in order to determine any relationships or additional namespaces. This top-level list is the master "services" list available from the server, and should be used for any default functionality when available. This list could also serve as the "home page" for a page-based browsing user interface.</p>
<p>To determine any further details from this list, each child would have to be browsed. The elements within the icq service are only hints to a client for building user interface elements. The icq.jabber.org service would still need to be browsed in order to determine any relationships or additional namespaces. This top-level list is the primary "services" list available from the server, and should be used for any default functionality when available. This list could also serve as the "home page" for a page-based browsing user interface.</p>
</section1>
<section1topic='Implementation Notes'>
<p>A client should not just blindly request browse information every time the user requests it, rather, a client should cache the browse results based on JabberID. Any display or use of the browse data should then be returned from the cache. This model is similiar to that of presence.</p>
<di><dt>Kick</dt><dd>To temporarily remove a participant or visitor from a room; the user is allowed to re-enter the room at any time. A kicked user has a role of "none".</dd></di>
<di><dt>Logging</dt><dd>Storage of discussions that occur within a room for public retrieval outside the context of the room.</dd></di>
<di><dt>Member</dt><dd>A user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".</dd></di>
<di><dt>Member</dt><dd>A user who is on the "permitted" list for a members-only room or who is registered with an open room. A member has an affiliation of "member".</dd></di>
<di><dt>Moderator</dt><dd>A room role that is usually associated with room admins but that can be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".</dd></di>
<di><dt>MUC</dt><dd>The multi-user chat protocol for text-based conferencing specified in this document.</dd></di>
<di><dt>Multi-Session Nick</dt><dd>If allowed by the service, a user can associate more than one full JID with the same occupant JID (e.g., the user juliet@capulet.lit is allowed to log in simultaneously as the nick "JuliC" in the characters@chat.shakespeare.lit chatroom from both juliet@capulet.lit/balcony and juliet@capulet.lit/chamber). Multi-session nicks are not currently defined in this document.</dd></di>
@ -918,7 +924,7 @@
@@ -918,7 +924,7 @@
<p>Support for the owner affiliation is REQUIRED. Support for the admin, member, and outcast affiliations is RECOMMENDED. (The "None" affiliation is the absence of an affiliation.)</p>
<p>These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID, not the nick as with roles.</p>
<p>If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits (i.e., a service does not maintain a "none list" across visits).</p>
<p>The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to register with an open room and thus be lastingly associated with that room in some way (one result might be that the service could reserve the user's nickname in the room).</p>
<p>The member affiliation provides a way for a room owner or admin to specify a "permitted" list of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to register with an open room and thus be lastingly associated with that room in some way (one result might be that the service could reserve the user's nickname in the room).</p>
<p>An outcast is a user who has been banned from a room and who is not allowed to enter the room.</p>
<p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants (if the room is configured to broadcast presence from entities with a given role).</p>
<section3topic='Privileges'anchor='affil-priv'>
@ -3447,7 +3453,7 @@
@@ -3447,7 +3453,7 @@
</section2>
<section2topic='Modifying the Member List'anchor='modifymember'>
<p>In the context of a members-only room, the member list is essentially a "whitelist" of people who are allowed to enter the room. Anyone who is not a member is effectively banned from entering the room, even if their affiliation is not "outcast".</p>
<p>In the context of a members-only room, the member list is essentially a list of people who are allowed to enter the room. Anyone who is not a member is effectively banned from entering the room, even if their affiliation is not "outcast".</p>
<p>In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users can appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.</p>
<p>It is RECOMMENDED that only room admins have the privilege to modify the member list in members-only rooms. To do so, the admin first requests the member list by querying the room for all users with an affiliation of "member":</p>
<examplecaption='Admin Requests Member List'><![CDATA[
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.19.0</version>
<date>2020-08-16</date>
@ -1379,7 +1385,7 @@ And by opposing end them?
@@ -1379,7 +1385,7 @@ And by opposing end them?
</error>
</iq>
]]></example>
<p>Note: An implementation MAY enable the service administrator to configure a list of entities that are excluded from this check; those entities may be considered "trusted proxies" that are allowed to subscribe on behalf of other entities. In the same way, implementations MAY enable blacklisting of entities that are not allowed to perform specific operations (such as subscribing or creating nodes).</p>
<p>Note: An implementation MAY enable the service administrator to configure a list of entities that are excluded from this check; those entities may be considered "trusted proxies" that are allowed to subscribe on behalf of other entities. In the same way, implementations MAY enable listing of entities that are not allowed to perform specific operations (such as subscribing or creating nodes).</p>
<p>For nodes with an access model of "presence", if the requesting entity is not subscribed to the owner's presence then the pubsub service MUST respond with a ¬authorized; error, which SHOULD also include a pubsub-specific error condition of <presence-subscription-required/>.</p>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
@ -58,9 +64,9 @@
@@ -58,9 +64,9 @@
<li>Bugs in the service often caused the Jabber server to crash.</li>
</ul>
<p>The most common use for this service was to provide server-side blacklists. Unforuntately, mod_filter was overpowered even by this relatively simple form of packet filtering (matching the sending JID and dropping the packet if necessary), so this need has been neatly filled by &xep0016;.</p>
<p>The most common use for this service was to provide server-side blocklists. Unforuntately, mod_filter was overpowered even by this relatively simple form of packet filtering (matching the sending JID and dropping the packet if necessary), so this need has been neatly filled by &xep0016;.</p>
<p>However, packet filtering (as opposed to the subset of JID blacklisting) is still of use, for the following tasks:</p>
<p>However, packet filtering (as opposed to the subset of JID blocking) is still of use, for the following tasks:</p>
<ul>
<li>Setting up automatic responses to messages (e.g., "vacation" messages).</li>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.8.1</version>
<date>2015-09-17</date>
@ -831,7 +837,7 @@ DATA = (payload)
@@ -831,7 +837,7 @@ DATA = (payload)
<p>In the absence of end-to-end encryption of the negotiation stanzas between the Requester and the Target, a passive attacker (eavesdropper) could authenticate to the bytestream before the Target, thus preventing the Target from connecting and also hijacking the data sent from the Requester.</p>
</section2>
<section2topic='Denial of Service'anchor='security-dos'>
<p>A SOCKS5 Bytestreams Proxy can be subject to denial of service attacks (e.g., generating a large number of session requests that are never activated). Proxy deployments are advised to monitor usage from particular entities and blacklist them if their usage is excessive.</p>
<p>A SOCKS5 Bytestreams Proxy can be subject to denial of service attacks (e.g., generating a large number of session requests that are never activated). Proxy deployments are advised to monitor usage from particular entities and block them if their usage is excessive.</p>
</section2>
<section2topic='Use of SHA-1'anchor='security-sha1'>
<p>The use of the SHA-1 algorithm to hash the SID, Requester's JID, and Target's JID is not security-critical. Therefore, the known weaknesses of SHA-1 are not of significant concern in this protocol.</p>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.2</version>
<date>2007-10-30</date>
@ -115,7 +121,7 @@
@@ -115,7 +121,7 @@
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
</section1>
<section1topic='Requirements and Approach'anchor='reqs'>
<p>Defining a protocol suite provides a high-level "bucket" into which we can place specific functionality areas for development and compliance testing. A baseline is provided by RFCs 3920 and 3921, which define XML streams, JID processing, channel encryption, authentication, the three primary XML stanza types (&MESSAGE;, &PRESENCE;, and &IQ;), namespace handling, presence subscriptions, roster management, and privacy lists (whitelisting/blacklisting). However, basic Jabber instant messaging and presence applications should support several additional protocols that were not included in the XMPP specifications for either of the following reasons:</p>
<p>Defining a protocol suite provides a high-level "bucket" into which we can place specific functionality areas for development and compliance testing. A baseline is provided by RFCs 3920 and 3921, which define XML streams, JID processing, channel encryption, authentication, the three primary XML stanza types (&MESSAGE;, &PRESENCE;, and &IQ;), namespace handling, presence subscriptions, roster management, and privacy lists (permit/deny lists). However, basic Jabber instant messaging and presence applications should support several additional protocols that were not included in the XMPP specifications for either of the following reasons:</p>
<ul>
<li>They were not required to meet the requirements of &rfc2779; (e.g, service discovery)</li>
<li>They were and remain in common use within the Jabber community but did not meet the more stringent requirements of the IETF (e.g., old-style, non-SASL authentication)</li>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.4</version>
<date>2012-04-18</date>
@ -702,7 +708,7 @@
@@ -702,7 +708,7 @@
<p>
<em>This section of the document describes the inter-domain protocol for communication between WaitingListServices. The protocol defined in this section MUST be implemented by ServiceProviders.</em>
</p>
<p>A ServiceProvider's WaitingListService MUST be configured with a "whitelist" of InteropPartner's WaitingListServices with which it communicates. Therefore service discovery SHOULD NOT be necessary. However, if necessary it MAY use either the <cite>Agent Information</cite> protocol or the <cite>Service Discovery</cite> protocol as described in the following examples.</p>
<p>A ServiceProvider's WaitingListService MUST be configured with a list of permitted InteropPartner's WaitingListServices with which it communicates. Therefore service discovery SHOULD NOT be necessary. However, if necessary it MAY use either the <cite>Agent Information</cite> protocol or the <cite>Service Discovery</cite> protocol as described in the following examples.</p>
<p>Note: The InteropPartner's WaitingListService is not required to be hosted by InteropPartner, and could be hosted by a third party (e.g., a neutral phone number translation service). In this case, InteropPartner would simply advertise 'waitlist.third-party.com' as its WaitingListService.</p>
<section3topic="ServiceProvider's WaitingListService Retrieves Current WaitingList"anchor='protocol-service-retrieve'>
<examplecaption="ServiceProvider Discovers InteropPartner's WaitingListService by Sending Agent Information Request to InteropPartner"><![CDATA[
<p>A ServiceProvider's WaitingListService MUST be configured with a "whitelist" of InteropPartners with which it communicates. The WaitingListService SHOULD NOT communicate with any InteropPartners that are not on the whitelist.</p>
<p>A ServiceProvider's WaitingListService MUST be configured with a list of permitted InteropPartners with which it communicates. The WaitingListService SHOULD NOT communicate with any InteropPartners that are not on the list.</p>
<p>Requesting JIDs via WaitingLists is not bidirectional; i.e., a service MUST NOT allow an IM User to discover a Contact's non-XMPP URI based on the Contact's JID.</p>
<p>A service MAY require a Contact to approve the disclosure of the Contact's JID, either as a global preference or for each request; however, this is a local policy matter.</p>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.3</version>
<date>2017-11-15</date>
@ -1130,7 +1136,7 @@
@@ -1130,7 +1136,7 @@
<section1topic='Replication'anchor='replication'>
<p>This section describes how a client can replicate an archive locally. <note>Clients that run in constrained environments may not be able to implement replication if they are prevented from accessing (sufficient) local storage.</note> The existence of a local copy of the archive enables clients to search the content of all messages (including collections saved by another client machine). <note>Since collections SHOULD be stored on the server in a form that it cannot decrypt, server-side searching of the content of messages is beyond the scope of this protocol.</note></p>
<p>The client can "synchronize" its local copy of the archive with the "master" archive on the server at any time. The first step is to request the list of collections that the server has modified (created, changed, or removed) in its master archive since the last update to the client's copy of the archive.</p>
<p>The client can "synchronize" its local copy of the archive with the "primary" archive on the server at any time. The first step is to request the list of collections that the server has modified (created, changed, or removed) in its primary archive since the last update to the client's copy of the archive.</p>
<p>Replication uses the <modified/> element. The list of collections that have been modified since a given time is requested by sending a <modified/> element to the server. The server then returns the list of collections that have been created, changed, or removed. A collection that has been created or changed is specified with a <changed/> element (with version zero for created collections), and a collection that has been removed is specified with a <removed/> element.</p>
<p>When requesting the list of modified collections, the client MUST embed appropriate <cite>Result Set Management</cite> data in the <modified/> element. The <modified/> element MUST include a 'start' attribute that specifies a UTC datetime (see <cite>XEP-0082</cite>) that it has previously received from the server or that it has determined locally (e.g., when synchronizing for the first time the client SHOULD choose a suitable time for the first page request, such as 1970-01-01T00:00:00Z).</p>
<examplecaption='Requesting a page of modifications'><![CDATA[
@ -1174,7 +1180,7 @@
@@ -1174,7 +1180,7 @@
</modified>
</iq>
]]></example>
<p>After receiving each result set page the client SHOULD delete from its local archive any collections that have been removed from the master archive. The client should also retrieve from the server the content of each collection that has been modified (see <linkurl='#retrieve'>Retrieving a Collection</link>) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).</p>
<p>After receiving each result set page the client SHOULD delete from its local archive any collections that have been removed from the primary archive. The client should also retrieve from the server the content of each collection that has been modified (see <linkurl='#retrieve'>Retrieving a Collection</link>) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).</p>
</section1>
<section1topic='Determining Server Support'anchor='disco'>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2008-04-18</date>
@ -376,7 +382,7 @@
@@ -376,7 +382,7 @@
<profilexmlns='urn:xmpp:tmp:profile'/>
</iq>
]]></example>
<p>If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a whitelist of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:</p>
<p>If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a list of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:</p>
<examplecaption='Server returns service unavailable error'><![CDATA[
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.1.0</version>
<date>2020-05-25</date>
@ -96,7 +102,7 @@
@@ -96,7 +102,7 @@
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as hostmaster@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in &rfc3920;). This document remedies that oversight, and the email recommendation specified here has been incorporated into &rfc6120;.</p>
<p>&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as security@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in &rfc3920;). This document remedies that oversight, and the email recommendation specified here has been incorporated into &rfc6120;.</p>
</section1>
<section1topic='Email Address'anchor='email'>
<p>Consistent with <cite>RFC 2142</cite>, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service.</p>
<li>The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).</li>
<li>The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in <cite>RFC 3921</cite>.</li>
<li>The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.</li>
<li>The user has explicitly added the contact to a list of entities who are allowed to access the user's personally-identifying information.</li>
</ol>
</section2>
<section2topic='Encryption of Media'anchor='security-media'>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2012-06-06</date>
@ -42,7 +48,7 @@
@@ -42,7 +48,7 @@
</header>
<section1topic='Introduction'anchor='intro'>
<p>Reputation systems are used in many online communities to increase trust and to encourage communication, commerce, and other forms of interaction. The public XMPP network might benefit from instituting a reputation system for servers, for end users, or both. The benefits might include faster blacklisting of rogue servers and other bad actors, differential quality of service based on reputation, delayed entry to &xep0045; rooms for low-reputation users, integration with &xep0016;, and the like.</p>
<p>Reputation systems are used in many online communities to increase trust and to encourage communication, commerce, and other forms of interaction. The public XMPP network might benefit from instituting a reputation system for servers, for end users, or both. The benefits might include faster blocking of rogue servers and other bad actors, differential quality of service based on reputation, delayed entry to &xep0045; rooms for low-reputation users, integration with &xep0016;, and the like.</p>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.4.0</version>
<date>2018-10-01</date>
@ -180,7 +186,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
@@ -180,7 +186,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<p><em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em></p>
</section2>
<section2topic="Jingle Client Consuming the Relay Service"anchor="clientconsumingrelay">
<p>A Jingle Client with Internet connectivity wheter with direct access to a public IP or not, can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
<p>A Jingle Client with Internet connectivity wheter with direct access to a public IP or not, can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, allow/deny lists, domain, etc...</p>
<p>
<em>Note: It is NOT mandatory to became a Jingle Relay Node it is OPTIONAL and SHOULD be done ONLY under user awareness and concentiment.</em>
</p>
@ -456,7 +462,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
@@ -456,7 +462,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</p>
</section2>
<section2topic="XMPP Client or Component in a Public IP"anchor="clientonpublicip">
<p>A XMPP Client or Component with direct access to a public IP can potentially provide the UDP Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
<p>A XMPP Client or Component with direct access to a public IP can potentially provide the UDP Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, allow/deny lists, domain, etc...</p>
<p>
<em>Note: It is NOT mandatory to became a Jingle Relay Node. This is OPTIONAL and SHOULD be done with user awareness and concentiment.</em>
<abstract>Multi-User Chats, distributed over several nodes in the XMPP network, using a master/slave architecture</abstract>
<abstract>Multi-User Chats, distributed over several nodes in the XMPP network, using a primary/replica architecture</abstract>
&LEGALNOTICE;
<number>0282</number>
<status>Deferred</status>
@ -31,6 +31,12 @@
@@ -31,6 +31,12 @@
<surname>Hancke</surname>
<jid>fippo@ve.symlynx.com</jid>
</author>
<revision>
<version>0.1.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2010-06-11</date>
@ -46,7 +52,7 @@
@@ -46,7 +52,7 @@
</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>The architecture is that of a single root node, called PRIMARY and several repeater nodes, each called REPLICA. Every stanza is submitted via the replicas to the primary, control is centralized there. The primary then sends a copy of the stanza to each of the replicas where it is processed and then distributed to each of the replica's leaf nodes, local users at this point. During redistribution, the replica shall not change the stanza's 'from' attribute, which is only possible if the replica 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 primary's server and each of the replica servers.</p>
<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>In our example we are presuming that three replicas from three hosts have registered with the primary for traffic redistribution. They are doing so using replica@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>
<p>This section describes the protocol between the primary and the replicas, the interaction between each replica 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>
<section2topic='Replica Requirements'>
<p>The replica</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 be able to intercept any stanzas sent to the primary's jid,</li>
<li>must be able to verify if a local user has sent directed presence to the primary's 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>
<li>must store room history (if desired by primary)</li>
</ul>
</section2>
<section2topic='Creating a Slave'>
<section2topic='Creating a Replica'>
<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>
<p>PARANOIA: why should the replica let the primary create the replica 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[
<p>After the creation of a new replica, the primary must send the room roster (which at that time only consists of remote participants) to the replica:</p>
<examplecaption="Primary Sends Room Roster to Replica"><![CDATA[
<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>
<p>After the creation of a new replica, the primary MAY also send the discussion history to the replica. The replica shall store this and deliver it to entering participants.</p>
<p>from=primaryjid to=replicajid?</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[
<p>If a new occupant requests to enter the room, the primary first sends a presence update to all participants to inform them of the presence of the new user. Then, the primary sends the affected replica a stanza requesting it to add the user to the distribution list</p>
<examplecaption="Primary informs Replica of New Occupant"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'>
to='replica@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>
<p>The replica MUST verify that the user has sent directed presence to the primary's JID before. This helps to ensure that the user intended to enter the room. If this is ture, the replica 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[
<p>If an occupant sends an unavailable presence to the room, the primary sends the affected replica a stanza requesting it to remove the user from the distribution list.</p>
<examplecaption="Primary informs Replica of Occupant's Departure"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'
to='replica@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>
<p>The replica removes user and forwards the stanza to user.</p>
<p>The primary then sends a presence update to all replicas 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>
<p>Note that the primary MUST NOT send the full jid of the user to any replicas without members that are moderators.</p>
<p>When rebroadcasting this stanza to its local occupants, the replica MUST remove the participants full JID subject to the rules of XEP-0045. In addition, the replica 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>
<section2topic='Replica Forwards Stanza to Primary'>
<p>The replica may relay messages from local users to the primary. 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>
<p>Die Regel ist relativ einfach... from=fulljid to=primaryjid/undevtlresource</p>
<p>fulljid deshalb, damit der primary nicht checken muss ob der jeweilige user auf dem replica ist und ausserdem der jeweilige user nicht zwangsläufig im Raum sein muss...</p>
<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"><
Matthew Wild
2 years ago
committed by