moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 07:08:51 -05:00
Code Issues Releases Wiki Activity

Multiple XEPs: Cross-document editorial adjustments for inclusive language.

Browse Source 
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.
This commit is contained in:
Matthew Wild 2021-03-04 15:32:04 +00:00 committed by Jonas Schäfer
parent 784177b64f
commit 373b9de7b6
26 changed files with 355 additions and 198 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
xep-0009.xml
View File

@ -29,6 +29,12 @@
<email>dj.adams@pobox.com</email>
<jid>dj@gnu.mine.nu</jid>
</author>
<revision>
<version>2.2.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>2.2</version>
<date>2011-11-10</date>
@ -151,7 +157,7 @@
]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<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>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>

8
xep-0011.xml
View File

@ -24,6 +24,12 @@
&jer;
&xvirge;
&temas;
<revision>
<version>1.3.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<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 @@
&lt;/query&gt;
&lt;/iq&gt;
</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>
<section1 topic='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>

12
xep-0045.xml
View File

@ -45,6 +45,12 @@
</schemaloc>
<registry/>
&stpeter;
<revision>
<version>1.34.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.34.0</version>
<date>2020-10-28</date>
@ -603,7 +609,7 @@
<di><dt>IRC</dt><dd>Internet Relay Chat.</dd></di>
<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 @@
<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>
<section3 topic='Privileges' anchor='affil-priv'>
@ -3447,7 +3453,7 @@
</section2>
<section2 topic='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>
<example caption='Admin Requests Member List'><![CDATA[

8
xep-0060.xml
View File

@ -49,6 +49,12 @@
&pgmillard;
&stpeter;
&ralphm;
<revision>
<version>1.19.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<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?
</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>
</section4>
<section4 topic='Presence Subscription Required' anchor='subscriber-subscribe-error-presence'>
<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 &notauthorized; error, which SHOULD also include a pubsub-specific error condition of &lt;presence-subscription-required/&gt;.</p>

10
xep-0062.xml
View File

@ -29,6 +29,12 @@
<email>rob@cataclysm.cx</email>
<jid>rob@cataclysm.cx</jid>
</author>
<revision>
<version>0.2.2</version>
<date>2021-03-04</date>
<initials>mw</initials>
<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 @@
<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>

8
xep-0065.xml
View File

@ -29,6 +29,12 @@
&linuxwolf;
&stpeter;
&infiniti;
<revision>
<version>1.8.2</version>
<date>2021-03-04</date>
<initials>mw</initials>
<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)
<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>
<section2 topic='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>
<section2 topic='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>

8
xep-0073.xml
View File

@ -29,6 +29,12 @@
</supersededby>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.2.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<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 @@
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>
<section1 topic='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>

10
xep-0130.xml
View File

@ -50,6 +50,12 @@
<jid>mtroyer@corp.jabber.com</jid>
</author>
&val;
<revision>
<version>1.4.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<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 @@
<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>
<section3 topic="ServiceProvider's WaitingListService Retrieves Current WaitingList" anchor='protocol-service-retrieve'>
<example caption="ServiceProvider Discovers InteropPartner's WaitingListService by Sending Agent Information Request to InteropPartner"><![CDATA[
@ -917,7 +923,7 @@
</ol>
</section1>
<section1 topic="Security Considerations" anchor='security'>
<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>
</section1>

10
xep-0136.xml
View File

@ -45,6 +45,12 @@
<surname>Leboulanger</surname>
<email>asterix@lagaule.org</email>
</author>
<revision>
<version>1.3.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<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 @@
<section1 topic='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 &lt;modified/&gt; element. The list of collections that have been modified since a given time is requested by sending a &lt;modified/&gt; 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 &lt;changed/&gt; element (with version zero for created collections), and a collection that has been removed is specified with a &lt;removed/&gt; element.</p>
<p>When requesting the list of modified collections, the client MUST embed appropriate <cite>Result Set Management</cite> data in the &lt;modified/&gt; element. The &lt;modified/&gt; 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>
<example caption='Requesting a page of modifications'><![CDATA[
@ -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 <link url='#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 <link url='#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>
<section1 topic='Determining Server Support' anchor='disco'>

8
xep-0154.xml
View File

@ -27,6 +27,12 @@
<supersededby/>
<shortname>TO-BE-ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.6.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.6</version>
<date>2008-04-18</date>
@ -376,7 +382,7 @@
<profile xmlns='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>
<example caption='Server returns service unavailable error'><![CDATA[
<iq type='error'
from='hamlet@denmark.lit'

8
xep-0157.xml
View File

@ -28,6 +28,12 @@
<email>jajcus@jajcus.net</email>
<jid>jajcus@jabber.bnet.pl</jid>
</author>
<revision>
<version>1.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>1.1.0</version>
<date>2020-05-25</date>
@ -96,7 +102,7 @@
</revision>
</header>
<section1 topic='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>
<section1 topic='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>

8
xep-0169.xml
View File

@ -29,6 +29,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.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>1.1</version>
<date>2009-12-24</date>
@ -128,7 +134,7 @@
<items node='http://jabber.org/protocol/geoloc'>
<item id='current'>
<geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
<room>master bedroom</room>
<room>primary bedroom</room>
</geoloc>
</item>
</items>

8
xep-0176.xml
View File

@ -33,6 +33,12 @@
&hildjj;
&seanegan;
&robmcqueen;
<revision>
<version>1.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>1.1</version>
<date>2020-11-27</date>
@ -924,7 +930,7 @@ Romeo Gateway Juliet
<ol>
<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>
<section2 topic='Encryption of Media' anchor='security-media'>

8
xep-0205.xml
View File

@ -21,6 +21,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.0.2</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.0.1</version>
<date>2018-11-21</date>
@ -77,7 +83,7 @@
<li>Triggering lockouts and quota exhaustion (e.g., quotas associated with the bandwidth limits common in numerous XMPP server implementations.</li>
<li>Hijacking the TCP connection of a client or server (see &tcprobust;).</li>
<li>Attacking the Domain Name System (DNS) infrastructure on which XMPP typically depends.</li>
<li>Poisoning blacklists.</li>
<li>Poisoning blocklists.</li>
<li>Amplifying network traffic (this could be done through reflectors such as &xep0045; and &xep0060; services).</li>
</ol>
</section1>

8
xep-0275.xml
View File

@ -21,6 +21,12 @@
<supersededby/>
<shortname>reputation</shortname>
&stpeter;
<revision>
<version>0.2.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.2</version>
<date>2012-06-06</date>
@ -42,7 +48,7 @@
</header>
<section1 topic='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>
</section1>
<section1 topic='Terminology' anchor='terminology'>

10
xep-0278.xml
View File

@ -34,6 +34,12 @@
<email>thiago@xmppjingle.com</email>
<jid>barata7@gmail.com</jid>
</author>
<revision>
<version>0.4.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.4.0</version>
<date>2018-10-01</date>
@ -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>
<section2 topic="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
</p>
</section2>
<section2 topic="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>
</p>

192
xep-0282.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>DMUC2: Distributed MUC</title>
<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 @@
<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 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p class='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>
<code><![CDATA[
BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ----> Wumpus
killrc.oulubox.irc ----> Phaedrus
@ -62,7 +68,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
<section1 topic='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>The existence of the replica 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>
@ -75,11 +81,11 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
<section2 topic='General Terms' anchor='terms-general'>
<dl>
<di>
<dt>Master</dt>
<dt>Primary</dt>
<dd></dd>
</di>
<di>
<dt>Slave</dt>
<dt>Replica</dt>
<dd></dd>
</di>
<di>
@ -145,68 +151,68 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
<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>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>
</section2>
</section1>
<section1 topic='MASTER/SLAVE Protocol' anchor='masterslave'>
<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>
<section1 topic='PRIMARY/REPLICA Protocol' anchor='primaryreplica'>
<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>
<!--
<section2 topic='Narrative Protocol Description'>
<p>some blabla</p>
</section2>
-->
<section2 topic='Slave Requirements'>
<p>The slave</p>
<section2 topic='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>
<section2 topic='Creating a Slave'>
<section2 topic='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>
<section2 topic='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>
<example caption="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>
<example caption="Primary Sends Room Roster to Replica"><![CDATA[
<presence
from='wallops@channel.avalon.irc/Wumpus'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='owner' role='moderator'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/Valdis'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='participant'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/Phaedrus'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='participant'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/WiZ'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='admin' role='moderator'/>
</x>
</presence>
<presence
from='wallops@channel.avalon.irc/Troy'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='participant' role='moderator'/>
</x>
@ -216,44 +222,44 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
-->
</section2>
<section2 topic='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>
<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>
<section2 topic='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>
<example caption="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>
<example caption="Primary informs Replica of New Occupant"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
<enter jid='rubenro@vesa.yeggmaex.irc/shaver'/>
<history maxstanzas='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>
<section2 topic='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>
<example caption="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>
<example caption="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'>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
<leave jid='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>
<section2 topic='Presence Update'>
<p>Presence updates are distributed by the master to all slaves.</p>
<example caption="Master sends presence update"><![CDATA[
<p>Presence updates are distributed by the primary to all replicas.</p>
<example caption="Primary sends presence update"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@killrc.oulubox.irc'>
to='replica@killrc.oulubox.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='rubenro@vesa.yeggmaex.irc/shaver'
@ -263,7 +269,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</presence>
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@eris.dclxvii.irc'>
to='replica@eris.dclxvii.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='rubenro@vesa.yeggmaex.irc/shaver'
@ -273,20 +279,20 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</presence>
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
...
</presence>]]></example>
<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>
<section2 topic='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>
<section2 topic='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>Beispiele: message submit, presence update, privatchat innerhalb raum, vcard avatar get</p>
-->
<example caption="Slave Relays a Message to the Master"><![CDATA[
<example caption="Replica Relays a Message to the Primary"><![CDATA[
<message
from='rubenro@vesa.yeggmaex.irc/shaver'
to='wallops@channel.avalon.irc'
@ -302,11 +308,11 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
-->
</section2>
<section2 topic='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>
<example caption="Message from Master to all Slaves"><![CDATA[
<p>When relaying a message, the primary SHOULD add a urn:xmpp:delay element inside dmuc element so that the replica can provide proper timestamps to new users. The primary then sends a copy of the stanza to each replica.</p>
<example caption="Message from Primary to all Replicas"><![CDATA[
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@killrc.oulubox.irc'
to='replica@killrc.oulubox.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
@ -317,7 +323,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</message>
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@eris.dclxvii.irc'
to='replica@eris.dclxvii.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
@ -328,7 +334,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</message>
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'
to='replica@vesa.yeggmaex.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
@ -337,36 +343,36 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
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>
<p>After saving the stanza for the purpose of keeping a room history, the replica SHOULD remove the urn:xmpp:tmp:dmuc:0 element and send the stanza to each local user.</p>
</section2>
<section2 topic='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>
<section2 topic='Primary-Replica Keepalive'>
<p>To ensure a working connecting, the primary SHOULD send an XMPP Ping stanza to each replica if there has been no traffic for a certain amount of time.</p>
<p>Likewise, each replica should ping the primary if there has been no traffic for more than the usual amount of time.</p>
</section2>
<section2 topic='Netsplit' anchor='netsplit'>
<section3 topic='Netsplit Detection' anchor='netsplit-detect'>
<p>A 'lost connection' can be detected by either slave or master when a stanza sent to the master or a slave respectively bounced.</p>
<section4 topic='At the Master'>
<p>If the master receives a stanza with type=error from the slave JID, it MUST:</p>
<p>A 'lost connection' can be detected by either replica or primary when a stanza sent to the primary or a replica respectively bounced.</p>
<section4 topic='At the Primary'>
<p>If the primary receives a stanza with type=error from the replica JID, it MUST:</p>
<ul>
<li>mark the slave as 'split', making sure that any further broadcasts are not sent to the affected slave</li>
<li>start sending pings to the slave with a higher frequency to get a timely notification if the slave reappears</li>
<li>resync when the slave reappears as described below</li>
<li>mark the replica as 'split', making sure that any further broadcasts are not sent to the affected replica</li>
<li>start sending pings to the replica with a higher frequency to get a timely notification if the replica reappears</li>
<li>resync when the replica reappears as described below</li>
</ul>
<p>In addition, the master MAY send a presence update for each user on the affected slave, marking them as away.</p>
<p>In addition, the primary MAY send a presence update for each user on the affected replica, marking them as away.</p>
</section4>
<section4 topic='At the Slave'>
<p>If the slave receives a stanza with type=error from the master's JID, it MUST:</p>
<section4 topic='At the Replica'>
<p>If the replica receives a stanza with type=error from the primary's JID, it MUST:</p>
<ul>
<li>stop submitting messages to the master</li>
<li>stop submitting messages to the primary</li>
<li>react to people sending presence updates or leaving the room and broadcast those changes to local users</li>
</ul>
<p>In addition, the slave MAY (and be careful when using this):</p>
<p>In addition, the replica MAY (and be careful when using this):</p>
<ul>
<li>enable local participants to continue their in-room conversation with other local participants</li>
<li>enable local participants to continue 1-1 messaging in the context of a room (such as private chat or vcard retrieval)</li>
<li>enable local users to enter the room (DANGER!!!)</li>
<li>enable moderators (as designated by the master) to kick participants</li>
<li>enable moderators (as designated by the primary) to kick participants</li>
<li>mark non-local users as away</li>
</ul>
</section4>
@ -377,7 +383,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</section2>
</section1>
<section1 topic='Use-Cases' anchor='Uses-Cases'>
<p>This section narratively describes the master-slave protocol in context with client interactions.</p>
<p>This section narratively describes the primary-replica protocol in context with client interactions.</p>
<section2 topic='Entering a Room' anchor='enter'>
<p>The user seeks to enter the wallops chatroom with the room nickname BigCheese:</p>
<example caption="User Seeks to Enter Room"><![CDATA[
@ -386,11 +392,11 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
to='wallops@channel.avalon.irc/BigCheese'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>]]></example>
<p>The master sends the presence update to each slave to inform the current occupants of BigCheese's arrival:</p>
<example caption="Master Sends Presence Update to all Slaves"><![CDATA[
<p>The primary sends the presence update to each replica to inform the current occupants of BigCheese's arrival:</p>
<example caption="Primary Sends Presence Update to all Replicas"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@killrc.oulubox.irc'>
to='replica@killrc.oulubox.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='rubenro@vesa.yeggmaex.irc/shaver'
@ -400,7 +406,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</presence>
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@eris.dclxvii.irc'>
to='replica@eris.dclxvii.irc'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='rubenro@vesa.yeggmaex.irc/shaver'
@ -410,11 +416,11 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</presence>
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
...
</presence>]]></example>
<p>Each slave then distributes this presence update:</p>
<example caption="Slaves Distribute Presence Update to Users - killrc Slave"><![CDATA[
<p>Each replica then distributes this presence update:</p>
<example caption="Replicas Distribute Presence Update to Users - killrc Replica"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='argl@killrc.oulubox.irc/laptop'>
@ -435,7 +441,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
to='phaedrus@killrc.oulubox.irc/phone'>
...
</presence>]]></example>
<example caption="Slaves Distribute Presence Update to Users - eris Slave"><![CDATA[
<example caption="Replicas Distribute Presence Update to Users - eris Replica"><![CDATA[
<presence
from='wallops@channel.avalon.irc/WiZ'
to='squit@eris.dclxvii.irc/jupiter'>
@ -456,24 +462,24 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</x>
...
</presence>]]></example>
<example caption="Slaves Distribute Presence Update to Users - vesa Slave"><![CDATA[
<example caption="Replicas Distribute Presence Update to Users - vesa Replica"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='rubenro@vesa.yeggmaex.irc/shaver'>
...
</presence>]]></example>
<p>The master then informs the slave of the entered user about a new occupant:</p>
<example caption="Master Informs Slave of New Occupant"><![CDATA[
<p>The primary then informs the replica of the entered user about a new occupant:</p>
<example caption="Primary Informs Replica of New Occupant"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'>
to='replica@vesa.yeggmaex.irc'>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
<enter jid='rubenro@vesa.yeggmaex.irc/shaver'/>
</x>
...
</presence>]]></example>
<p>The slave sends presence from existing occupants to new occupant:</p>
<example caption='Slave Sends Presence from Existing Occupants to New Occupant'><![CDATA[
<p>The replica sends presence from existing occupants to new occupant:</p>
<example caption='Replica Sends Presence from Existing Occupants to New Occupant'><![CDATA[
<presence
from='wallops@channel.avalon.irc/Wumpus'
to='rubenro@vesa.yeggmaex.irc/shaver'>
@ -517,14 +523,14 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</x>
</presence>]]></example>
<p>and concludes the room roster by sending the new occupant's presence to the new occupant:</p>
<example caption="Slave Sends New Occupant's Presence to New Occupant"><![CDATA[
<example caption="Replica Sends New Occupant's Presence to New Occupant"><![CDATA[
<presence
from='wallops@channel.avalon.irc/BigCheese'
to='rubenro@vesa.yeggmaex.irc/shaver'
...
</presence>]]></example>
<p>After that, the slave will send the discussion history to the new occupant:</p>
<example caption='Slave Sends Discussion History to New Occupant'><![CDATA[
<p>After that, the replica will send the discussion history to the new occupant:</p>
<example caption='Replica Sends Discussion History to New Occupant'><![CDATA[
<message from='wallops@channel.avalon.irc/Trillian'
to='rubenro@vesa.yeggmaex.irc/shaver'
type='groupchat'>
@ -567,11 +573,11 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
</message>]]></example>
<p>The master will broadcast this message to all slaves:</p>
<example caption="Master Distributes Message to all Slaves"><![CDATA[
<p>The primary will broadcast this message to all replicas:</p>
<example caption="Primary Distributes Message to all Replicas"><![CDATA[
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@killrc.oulubox.irc'
to='replica@killrc.oulubox.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
@ -582,7 +588,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</message>
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@eris.dclxvii.irc'
to='replica@eris.dclxvii.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
@ -593,7 +599,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
</message>
<message
from='wallops@channel.avalon.irc/BigCheese'
to='slave@vesa.yeggmaex.irc'
to='replica@vesa.yeggmaex.irc'
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
<x xmlns='urn:xmpp:tmp:dmuc:0'>
@ -602,8 +608,8 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
stamp='1990-10-13T23:58:37Z'/>
</x>
</message>]]></example>
<p>And each slave distributes to local occupants</p>
<example caption="Slave Distributes Message to Occupants - killrc Slave"><![CDATA[
<p>And each replica distributes to local occupants</p>
<example caption="Replica Distributes Message to Occupants - killrc Replica"><![CDATA[
<message
from='wallops@channel.avalon.irc/BigCheese'
to='argl@killrc.oulubox.irc/laptop'
@ -622,7 +628,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
</message>]]></example>
<example caption="Slave Distributes Message to Occupants - eris Slave"><![CDATA[
<example caption="Replica Distributes Message to Occupants - eris Replica"><![CDATA[
<message
from='wallops@channel.avalon.irc/BigCheese'
to='squit@eris.dclxvii.irc/jupiter'
@ -635,7 +641,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
type='groupchat'>
<body>Phaedrus, we're all having a truly rotten time.</body>
</message>]]></example>
<example caption="Slave Distributes Message to Occupants - vesa Slave"><![CDATA[
<example caption="Replica Distributes Message to Occupants - vesa Replica"><![CDATA[
<message
from='wallops@channel.avalon.irc/BigCheese'
to='rubenro@vesa.yeggmaex.irc/shaver'

8
xep-0284.xml
View File

@ -33,6 +33,12 @@
<surname>Pusateri</surname>
<email>pusateri@bangj.com</email>
</author>
<revision>
<version>0.1.3</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.2</version>
<date>2019-11-23</date>
@ -167,7 +173,7 @@
<section1 topic='Introduction' anchor='intro'>
<p>This specification defines a protocol for collaboratively editing XML data. Essentially, this protocol provides a simple way of synchronizing an unordered set of records across several endpoints. Additionally, this protocol defines a mapping between such a set of records and the Document Object Model (DOM).</p>
<p>A special feature of this protocol compared to most other collaborative editing tools is that no master or server entity is required. A &xep0045; component or specialized editing component can be used for sessions that have a large number of participants, that need to be persistent, or that require more granular access control. However, the client implementation is minimally different whether such a specialized component is used or whether the session is one-to-one or multi-user.</p>
<p>A special feature of this protocol compared to most other collaborative editing tools is that no central or server entity is required. A &xep0045; component or specialized editing component can be used for sessions that have a large number of participants, that need to be persistent, or that require more granular access control. However, the client implementation is minimally different whether such a specialized component is used or whether the session is one-to-one or multi-user.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>

22
xep-0289.xml
View File

@ -24,6 +24,12 @@
<supersededby/>
<shortname>FMUC</shortname>
&ksmithisode;
<revision>
<version>0.2.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.2</version>
<date>2012-05-29</date>
@ -52,8 +58,8 @@
<li>FMUC set - the union of all MUC rooms that federate together</li>
<li>FMUC node - a single MUC room that is a member of an FMUC set (abbreviated to "node")</li>
<li>FMUC room - a room represented by an FMUC set</li>
<li>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</li>
<li>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.</li>
<li>Primary-Primary 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</li>
<li>Primary-Replica mode - two FMUC nodes operating where one, the primary, will continue working during a network outage while the replica will cease to work while it cannot communicate with the primary. This mode has increased network traffic and a consistent message delivery order across both nodes.</li>
<li>Joining FMUC node - a node that initiates an FMUC connection to another node (abbreviated to "joining node").</li>
<li>Joined FMUC node - a node that accepts an FMUC connection from another node (abbreviated to "joined node"). Note that when nodes are connected in a tree-like structure a node in one of the middle layers will be both a joining node in the context of its connection to the room above it and also a joined node in the context of those nodes below that join to it.</li>
</ul>
@ -64,9 +70,9 @@
<section1 topic='Requirements' anchor='reqs'>
<ul>
<li>If appropriately configured, avoid bandwidth use that isn't strictly necessary for message exchange.</li>
<li>Allow conversation in a federated MUC to continue when one of the federated nodes is unavailable (e.g. due to network failure preventing S2S links forming), such that the nodes operate in a 'peer to peer' or 'multi-master' mode.</li>
<li>If configured, allow a master/slave configuration such that a disconnected node is no longer usable for local chat</li>
<li><em>Acceptable compromise</em> When operating in multi-master mode the message ordering may not be consistent between FMUC nodes.</li>
<li>Allow conversation in a federated MUC to continue when one of the federated nodes is unavailable (e.g. due to network failure preventing S2S links forming), such that the nodes operate in a 'peer to peer' or 'multi-primary' mode.</li>
<li>If configured, allow a primary/replica configuration such that a disconnected node is no longer usable for local chat</li>
<li><em>Acceptable compromise</em> When operating in multi-primary mode the message ordering may not be consistent between FMUC nodes.</li>
</ul>
</section1>
@ -195,7 +201,7 @@
]]></example>
</section2>
<section2 topic="Sending messages" anchor="messages">
<p>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.</p>
<p>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 primary-primary 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.</p>
<example caption='User on FMUC Node sends a message'><![CDATA[
<message from='hamlet@denmark.lit/priam-ubuntu-vm' to='elsinore@talk.denmark.lit' type='groupchat'>
@ -241,7 +247,7 @@
</section2>
<section2 topic="Subsequent activity" anchor="activity">
<p>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.</p>
<p>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 primary-primary mode they won't distribute the stanza back to the node from which they received it.</p>
<example caption='Additional user joins FMUC room'><![CDATA[
<presence from="hatter@wonderland.lit/priam-ubuntu-vm" to="rabbithole@rooms.wonderland.lit/Hatter">
<x xmlns="http://jabber.org/protocol/muc"/>
@ -387,7 +393,7 @@
<section1 topic='TBD' anchor='tbd'>
<p>How to get the join-target to tell the joining room how much history to send during a resync.</p>
<p>How to perform a resync (Part and then full rejoin)</p>
<p>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.</p>
<p>Illustrate primary-replica 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.</p>
<p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

63
xep-0324.xml
View File

@ -31,6 +31,12 @@
<supersededby/>
<shortname>sensor-network-provisioning</shortname>
&peterwaher;
<revision>
<version>0.5.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.5</version>
<date>2017-05-20</date>
@ -707,7 +713,8 @@
<example caption='Readout request using multiple tokens'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='
primary@example.org/amr'
to='device@example.org'
id='7'>
<req xmlns='urn:xmpp:iot:sensordata' momentary='true' serviceToken='SERVICETOKEN1 SERVICETOKEN2' userToken='USERTOKEN1' seqnr='4'/>
@ -717,19 +724,19 @@
from='device@example.org/device'
to='provisioning.example.org'
id='8'>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' serviceToken='SERVICETOKEN1 SERVICETOKEN2' userToken='USERTOKEN1' momentary='true'/>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' serviceToken='SERVICETOKEN1 SERVICETOKEN2' userToken='USERTOKEN1' momentary='true'/>
</iq>
<iq type='result'
from='provisioning.example.org'
to='device@example.org/device'
id='8'>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' momentary='true' result='true'/>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' momentary='true' result='true'/>
</iq>
<iq type='result'
from='device@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='7'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='4'/>
</iq>]]>
@ -864,7 +871,7 @@
<example caption='Rejecting read-outs'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='device@example.org'
id='11'>
<req xmlns='urn:xmpp:iot:sensordata' momentary='true' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1' seqnr='1'/>
@ -874,19 +881,19 @@
from='device@example.org/device'
to='provisioning.example.org'
id='12'>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1' momentary='true'/>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1' momentary='true'/>
</iq>
<iq type='result'
from='provisioning.example.org'
to='device@example.org/device'
id='12'>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' momentary='true' result='false'/>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' momentary='true' result='false'/>
</iq>
<iq type='error'
from='device@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='11'>
<rejected xmlns='urn:xmpp:iot:sensordata' seqnr='1'>
<error>Access denied.</error>
@ -917,7 +924,7 @@
<example caption='Restricting nodes during read-out'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='device@example.org'
id='13'>
<req xmlns='urn:xmpp:iot:sensordata' momentary='true' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1' seqnr='2'>
@ -930,7 +937,7 @@
from='device@example.org/device'
to='provisioning.example.org'
id='14'>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' momentary='true' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' momentary='true' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'>
<node nodeId='Device02'/>
<node nodeId='Device03'/>
</canRead>
@ -940,14 +947,14 @@
from='provisioning.example.org'
to='device@example.org/device'
id='14'>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' momentary='true' result='true'>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' momentary='true' result='true'>
<node nodeId='Device02'/>
</canReadResponse>
</iq>
<iq type='result'
from='device@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='13'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='2'/>
</iq>]]>
@ -977,7 +984,7 @@
<example caption='Restricting fields during read-out'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='device@example.org'
id='15'>
<req xmlns='urn:xmpp:iot:sensordata' momentary='true' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1' seqnr='3'/>
@ -987,14 +994,14 @@
from='device@example.org/device'
to='provisioning.example.org'
id='16'>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' momentary='true' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'/>
<canRead xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' momentary='true' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'/>
</iq>
<iq type='result'
from='provisioning.example.org'
to='device@example.org/device'
id='16'>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' momentary='true' result='true'>
<canReadResponse xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' momentary='true' result='true'>
<field name='Energy'/>
<field name='Power'/>
</canReadResponse>
@ -1002,7 +1009,7 @@
<iq type='result'
from='device@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='15'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='3'/>
</iq>]]>
@ -1033,7 +1040,7 @@
<example caption='Rejecting control action'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='device@example.org'
id='17'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -1045,7 +1052,7 @@
from='device@example.org/device'
to='provisioning.example.org'
id='18'>
<canControl xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'>
<canControl xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'>
<parameter name='Output'/>
</canControl>
</iq>
@ -1054,12 +1061,12 @@
from='provisioning.example.org'
to='device@example.org/device'
id='18'>
<canControlResponse xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' result='false'/>
<canControlResponse xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' result='false'/>
</iq>
<iq type='error'
from='device@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='17'>
<setResponse xmlns='urn:xmpp:iot:control' responseCode='InsufficientPrivileges'/>
</iq>]]>
@ -1085,7 +1092,7 @@
<example caption='Restricting nodes during control'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='concentrator@example.org'
id='19'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -1101,7 +1108,7 @@
from='concentrator@example.org/plc'
to='provisioning.example.org'
id='20'>
<canControl xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'>
<canControl xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' serviceToken='SERVICETOKEN1' userToken='USERTOKEN1'>
<node nodeId='DigitalOutput1'/>
<node nodeId='DigitalOutput2'/>
<node nodeId='DigitalOutput3'/>
@ -1114,7 +1121,7 @@
from='provisioning.example.org'
to='concentrator@example.org/plc'
id='20'>
<canControlResponse xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' result='true'>
<canControlResponse xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' result='true'>
<node nodeId='DigitalOutput2'/>
<node nodeId='DigitalOutput3'/>
</canControlResponse>
@ -1122,7 +1129,7 @@
<iq type='result'
from='concentrator@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='19'>
<setResponse xmlns='urn:xmpp:iot:control' responseCode='OK'>
<node nodeId='DigitalOutput2'/>
@ -1160,7 +1167,7 @@
<example caption='Restricting parameters during control'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='plc@example.org'
id='21'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -1179,7 +1186,7 @@
from='plc@example.org/plc'
to='provisioning.example.org'
id='22'>
<canControl xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' serviceToken='SERVICETOKEN1' userToken='user0001'>
<canControl xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' serviceToken='SERVICETOKEN1' userToken='user0001'>
<parameter name='DigitalOutput1'/>
<parameter name='DigitalOutput2'/>
<parameter name='DigitalOutput3'/>
@ -1195,7 +1202,7 @@
from='provisioning.example.org'
to='plc@example.org/plc'
id='22'>
<canControlResponse xmlns='urn:xmpp:iot:provisioning' jid='master@example.org' result='true'>
<canControlResponse xmlns='urn:xmpp:iot:provisioning' jid='primary@example.org' result='true'>
<parameter name='DigitalOutput1'/>
<parameter name='DigitalOutput2'/>
<parameter name='DigitalOutput3'/>
@ -1205,7 +1212,7 @@
<iq type='result'
from='plc@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='21'>
<setResponse xmlns='urn:xmpp:iot:control' responseCode='OK'>
<parameter name='DigitalOutput1'/>

82
xep-0325.xml
View File

@ -35,6 +35,12 @@
<supersededby/>
<shortname>sensor-network-control</shortname>
&peterwaher;
<revision>
<version>0.5.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.5</version>
<date>2017-05-20</date>
@ -348,7 +354,7 @@
</p>
<example caption='Message stanza for setting a value'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='digital.output@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<boolean name='Output' value='true'/>
@ -367,7 +373,7 @@
<example caption='IQ stanza for setting a value'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='digital.output@example.org'
id='1'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -377,7 +383,7 @@
<iq type='result'
from='digital.output@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='1'>
<setResponse xmlns='urn:xmpp:iot:control'/>
</iq>]]>
@ -399,7 +405,7 @@
<example caption='Control failure response'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='analog.output@example.org'
id='2'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -409,7 +415,7 @@
<iq type='error'
from='analog.output@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='2'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -433,7 +439,7 @@
</p>
<example caption='Setting a single boolean-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='digital.output@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<boolean name='Output' value='true'/>
@ -448,7 +454,7 @@
</p>
<example caption='Setting a single 32-bit integer-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='analog.output@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<int name='Output' value='50000'/>
@ -464,7 +470,7 @@
</p>
<example caption='Setting a single 64-bit integer-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='megaprecision.analog.output@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<long name='Output' value='500000000000000'/>
@ -479,7 +485,7 @@
</p>
<example caption='Setting a single string-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='text.display@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<string name='Row1' value='Temperature: 21.4 °C'/>
@ -494,7 +500,7 @@
</p>
<example caption='Setting a single double-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='analog.output2@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<double name='4-20mA' value='8.192'/>
@ -509,7 +515,7 @@
</p>
<example caption='Setting a single date-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='alarm@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<date name='TariffStartDate' value='2013-05-01'/>
@ -524,7 +530,7 @@
</p>
<example caption='Setting a single time-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='alarm@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<time name='Alarm Time' value='08:00:00'/>
@ -539,7 +545,7 @@
</p>
<example caption='Setting a single date &amp; time-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='alarm@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<dateTime name='Alarm Time' value='2013-04-02T08:00:00'/>
@ -554,7 +560,7 @@
</p>
<example caption='Setting a single duration-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='alarm@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<duration name='Alarm Duration' value='PT3M30S'/>
@ -569,7 +575,7 @@
</p>
<example caption='Setting a single color-valued control parameter'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='spotlight@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<color name='Color' value='3399FF'/>
@ -584,7 +590,7 @@
</p>
<example caption='Setting multiple control parameters at once'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='dimmer@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<int name='FadeTimeMilliseconds' value='500'/>
@ -614,7 +620,7 @@
<example caption='Getting a control form'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='dimmer@example.org'
id='3'>
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'/>
@ -622,7 +628,7 @@
<iq type='result'
from='dimmer@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='3'>
<x type='form'
xmlns='jabber:x:data'
@ -694,7 +700,7 @@
<example caption='Getting a control form, Failure'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='dimmer@example.org'
id='4'>
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'/>
@ -702,7 +708,7 @@
<iq type='error'
from='dimmer@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='4'>
<error type='cancel'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -722,7 +728,7 @@
<example caption='Setting a (partial) control form'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='dimmer@example.org'
id='5'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -742,7 +748,7 @@
<iq type='result'
from='dimmer@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='5'>
<setResponse xmlns='urn:xmpp:iot:control' />
</iq>]]>
@ -760,7 +766,7 @@
<example caption='Setting a (partial) control form, Failure'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='dimmer@example.org'
id='6'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -780,7 +786,7 @@
<iq type='error'
from='dimmer@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='6'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -802,7 +808,7 @@
</p>
<example caption='Sending a control command to a node behind a concentrator'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='concentrator@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<node nodeId='DigitalOutput1'/>
@ -818,7 +824,7 @@
</p>
<example caption='Sending a control command to multiple nodes'>
<![CDATA[
<message from='master@example.org/amr'
<message from='primary@example.org/amr'
to='concentrator@example.org'>
<set xmlns='urn:xmpp:iot:control'>
<node nodeId='DigitalOutput1'/>
@ -840,7 +846,7 @@
<example caption='Sending a control command to multiple nodes, Failure'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='concentrator@example.org'
id='7'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -858,7 +864,7 @@
<iq type='error'
from='concentrator@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='7'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -875,7 +881,7 @@
<example caption='Getting a control form from multiple nodes'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='concentrator@example.org'
id='8'>
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -888,7 +894,7 @@
<iq type='result'
from='concentrator@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='8'>
<x type='form'
xmlns='jabber:x:data'
@ -923,7 +929,7 @@
<example caption='Getting a control form from multiple nodes, Failure'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='concentrator@example.org'
id='9'>
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -936,7 +942,7 @@
<iq type='error'
from='concentrator@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='9'>
<error type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -955,7 +961,7 @@
<example caption='Setting a (partial) control form to multiple nodes'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='concentrator@example.org'
id='10'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -976,7 +982,7 @@
<iq type='result'
from='concentrator@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='10'>
<setResponse xmlns='urn:xmpp:iot:control' />
</iq>]]>
@ -990,7 +996,7 @@
<example caption='Setting a (partial) control form to multiple nodes'>
<![CDATA[
<iq type='set'
from='master@example.org/amr'
from='primary@example.org/amr'
to='concentrator@example.org'
id='11'>
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
@ -1015,7 +1021,7 @@
<iq type='error'
from='concentrator@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='11'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -1516,7 +1522,7 @@
<example caption='Grouping control parameters'>
<![CDATA[
<iq type='get'
from='master@example.org/amr'
from='primary@example.org/amr'
to='spotlight@example.org'
id='12'>
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'/>
@ -1524,7 +1530,7 @@
<iq type='result'
from='spotlight@example.org'
to='master@example.org/amr'
to='primary@example.org/amr'
id='12'>
<x type='form'
xmlns='jabber:x:data'

8
xep-0353.xml
View File

@ -23,6 +23,12 @@
<shortname>jingle-message</shortname>
&fippo;
&stpeter;
<revision>
<version>0.3.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.3</version>
<date>2017-09-11</date>
@ -270,7 +276,7 @@
<p>Thanks to Lance Stout for his feedback.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of proceed messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by whitelisting requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending proceed messages does not occur by default.</p>
<p>Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of proceed messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending proceed messages does not occur by default.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>

8
xep-0355.xml
View File

@ -28,6 +28,12 @@
<email>goffi@goffi.org</email>
<jid>goffi@jabber.fr</jid>
</author>
<revision>
<version>0.4.2</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.4.1</version>
<date>2018-11-03</date>
@ -608,7 +614,7 @@
<li>Managing entity can manage sensitive data, <em>admin</em> delegation should be granted carefuly, only if you absolutely trust the entity.</li>
<li>A server MAY choose to filter allowed namespaces. In this case, it MUST always set the allowed type of filtered namespaces to <strong>0</strong>.</li>
<li>In case of filtering, a whitelist system is more secure and SHOULD be prefered to a blacklist (idealy, configuration would allow no filtering, whitelist filtering and blacklist filtering).</li>
<li>In case of filtering, an allowlist system is more secure and SHOULD be prefered to a blocklist (idealy, configuration would allow no filtering, allowlist filtering and blocklist filtering).</li>
</ol>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

8
xep-0371.xml
View File

@ -27,6 +27,12 @@
<supersededby/>
<shortname>jingle-ice</shortname>
&stpeter;
<revision>
<version>0.3.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.3</version>
<date>2020-05-14</date>
@ -907,7 +913,7 @@ Romeo Gateway Juliet
<ol>
<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>
<section2 topic='Encryption of Media' anchor='security-media'>

10
xep-0379.xml
View File

@ -28,6 +28,12 @@
<email>georg@op-co.de</email>
<jid>georg@yax.im</jid>
</author>
<revision>
<version>0.3.3</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.3.2</version>
<date>2020-01-14</date>
@ -240,7 +246,7 @@ https://juicyxmpp.example/i/#romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;
<presence to='romeo@montague.net' type='subscribed' />
]]></example>
<p>If Juliet's server does not indicate pre-approval support, her client
SHOULD store Romeo's JID in a local auto-approval whitelist, together
SHOULD store Romeo's JID in a local auto-approval list, together
with an appropriate expiration time.
</p>
</section2>
@ -273,7 +279,7 @@ https://juicyxmpp.example/i/#romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;
<presence from='romeo@montague.net' to='juliet@capulet.net' type='subscribe' />
]]></example>
<p>Juliet's client MUST ensure that the sender JID is contained in the
auto-approval whitelist before automatically approving the request.
auto-approval list before automatically approving the request.
Otherwise, it has to fallback to the normal subscription approval
process.</p>

12
xep-0420.xml
View File

@ -30,6 +30,12 @@
<supersededby/>
<shortname>SCE</shortname>
&paulschaub;
<revision>
<version>0.3.2</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.3.1</version>
<date>2020-11-03</date>
@ -329,7 +335,7 @@
<section1 topic='Receiving an encrypted stanza' anchor='receiving'>
<p>The recipient of the message decrypts the content of the &envelope; element to retrieve the &content; element. Depending on the affix profiles specified by the used encryption protocol, the affix elements are verified to prevent certain attacks from taking place.</p>
<p>Next the extension elements of the &content; elements &payload; element are checked against the whitelist/blacklist and any disallowed elements are discarded.</p>
<p>Next the extension elements of the &content; elements &payload; element are checked against the permitted list and any disallowed elements are discarded.</p>
<p>As a last step, the original unencrypted stanza is recreated by replacing the &envelope; element of the stanza with the contents of the &payload; element.</p>
</section1>
@ -339,7 +345,7 @@
Allowing for those elements to be included in, and parsed from the encrypted payload would allow a malicious client to perform a number of attacks.</p>
<p>Contrary to this, other elements are considered sensitive and MUST NOT be available in plaintext outside the &content; element.</p>
<p>It is hard to come up with a complete list of exceptional elements at this point, as there is no practical implementation experience.</p>
<p>Below is a non-exhaustive list of elements that are definitely blacklisted inside the &content; element and whitelisted as direct child elements of the message.</p>
<p>Below is a non-exhaustive list of elements that are definitely forbidden inside the &content; element and permitted as direct child elements of the message.</p>
<table caption='Examples for exceptional elements that MUST NOT be included in, or read from the &content; element and MUST instead be sent traditionally as direct child elements of the stanza.'>
<tr>
<th>Element</th>
@ -395,7 +401,7 @@
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>TODO: Maybe the Registrar should handle a blacklist of elements that are allowed as child elements of the &content; element?</p>
<p>TODO: Maybe the Registrar should handle a list of elements that are forbidden as child elements of the &content; element?</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>