Cross-document editorial adjustments for inclusive language.
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.
+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.
This document requires no interaction with &IANA;.
diff --git a/xep-0011.xml b/xep-0011.xml index 87c536f3..e7d67537 100644 --- a/xep-0011.xml +++ b/xep-0011.xml @@ -24,6 +24,12 @@ &jer; &xvirge; &temas; +Cross-document editorial adjustments for inclusive language.
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.
+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.
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.
diff --git a/xep-0045.xml b/xep-0045.xml index f80f0d45..eff18e0f 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -45,6 +45,12 @@Cross-document editorial adjustments for inclusive language.
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.)
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.
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).
-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).
+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).
An outcast is a user who has been banned from a room and who is not allowed to enter the room.
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).
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".
+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".
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.
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":
Cross-document editorial adjustments for inclusive language.
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).
+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).
For nodes with an access model of "presence", if the requesting entity is not subscribed to the owner's presence then the pubsub service MUST respond with a ¬authorized; error, which SHOULD also include a pubsub-specific error condition of <presence-subscription-required/>.
diff --git a/xep-0062.xml b/xep-0062.xml index 3649aa66..90a1ef6f 100644 --- a/xep-0062.xml +++ b/xep-0062.xml @@ -29,6 +29,12 @@Cross-document editorial adjustments for inclusive language.
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;.
+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;.
-However, packet filtering (as opposed to the subset of JID blacklisting) is still of use, for the following tasks:
+However, packet filtering (as opposed to the subset of JID blocking) is still of use, for the following tasks:
Cross-document editorial adjustments for inclusive language.
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.
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.
+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.
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.
diff --git a/xep-0073.xml b/xep-0073.xml index 83867556..ffc58480 100644 --- a/xep-0073.xml +++ b/xep-0073.xml @@ -29,6 +29,12 @@Cross-document editorial adjustments for inclusive language.
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:
+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:
Cross-document editorial adjustments for inclusive language.
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.
-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 Agent Information protocol or the Service Discovery protocol as described in the following examples.
+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 Agent Information protocol or the Service Discovery protocol as described in the following examples.
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.
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.
+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.
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.
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.
Cross-document editorial adjustments for inclusive language.
This section describes how a client can replicate an archive locally.
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.
+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.
Replication uses the <modified/> element. The list of collections that have been modified since a given time is requested by sending a <modified/> element to the server. The server then returns the list of collections that have been created, changed, or removed. A collection that has been created or changed is specified with a <changed/> element (with version zero for created collections), and a collection that has been removed is specified with a <removed/> element.
When requesting the list of modified collections, the client MUST embed appropriate Result Set Management data in the <modified/> element. The <modified/> element MUST include a 'start' attribute that specifies a UTC datetime (see XEP-0082) 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).
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 Retrieving a Collection) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).
+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 Retrieving a Collection) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).
Cross-document editorial adjustments for inclusive language.
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:
+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:
Cross-document editorial adjustments for inclusive language.
&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;.
+&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;.
Consistent with RFC 2142, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service.
diff --git a/xep-0169.xml b/xep-0169.xml index 78f6fcf6..5d4683b1 100644 --- a/xep-0169.xml +++ b/xep-0169.xml @@ -29,6 +29,12 @@Cross-document editorial adjustments for inclusive language.
Cross-document editorial adjustments for inclusive language.
Cross-document editorial adjustments for inclusive language.
Cross-document editorial adjustments for inclusive language.
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.
+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.
Cross-document editorial adjustments for inclusive language.
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.
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...
+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...
Note: It is NOT mandatory to became a Jingle Relay Node it is OPTIONAL and SHOULD be done ONLY under user awareness and concentiment.
@@ -456,7 +462,7 @@ All signalling, request, response and publishing is done via XMPP, not requiringA 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...
+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...
Note: It is NOT mandatory to became a Jingle Relay Node. This is OPTIONAL and SHOULD be done with user awareness and concentiment.
diff --git a/xep-0282.xml b/xep-0282.xml index 9288c30c..3e82e41d 100644 --- a/xep-0282.xml +++ b/xep-0282.xml @@ -7,7 +7,7 @@Cross-document editorial adjustments for inclusive language.
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.
-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.
+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.
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 ---
This specification addresses the following requirements:
- - The existence of the slave shall be transparent for the user.
+ - The existence of the replica shall be transparent for the user.
- Enable detection of connection loss.
- Enable occupants to remain in instance of the conference if connectivity is lost to other instances.
- Enable occupants to leave a chatroom while connectivity is lost.
@@ -75,11 +81,11 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
- - Master
+ - Primary
- - Slave
+ - Replica
@@ -145,68 +151,68 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
Participant
- 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.
+ 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.
-
- 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.
+
+ 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.
-
- The slave
+
+ The replica
- - must be able to intercept any stanzas sent to the masters jid,
- - must be able to verify if a local user has sent directed presence to the masters jid,
+ - must be able to intercept any stanzas sent to the primary's jid,
+ - must be able to verify if a local user has sent directed presence to the primary's jid,
- must store room roster,
- must store local room roster
- - must store room history (if desired by master)
+ - must store room history (if desired by primary)
-
+
to follow
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.
- 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:
- 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:
+
+ to='replica@vesa.yeggmaex.irc'>
+ to='replica@vesa.yeggmaex.irc'>
+ to='replica@vesa.yeggmaex.irc'>
+ to='replica@vesa.yeggmaex.irc'>
+ to='replica@vesa.yeggmaex.irc'>
@@ -216,44 +222,44 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
-->
- 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.
- from=masterjid to=slavejid?
+ 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.
+ from=primaryjid to=replicajid?
- 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
- 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
+
+ to='replica@vesa.yeggmaex.irc'>
...
]]>
- 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.
+ 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.
- 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.
- 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.
+
...
]]>
- The slave removes user and forwards the stanza to user.
- The master then sends a presence update to all slaves to announce the occupants departure.
+ The replica removes user and forwards the stanza to user.
+ The primary then sends a presence update to all replicas to announce the occupants departure.
- Presence updates are distributed by the master to all slaves.
- Presence updates are distributed by the primary to all replicas.
+
+ to='replica@killrc.oulubox.irc'>
- vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
+ to='replica@eris.dclxvii.irc'>
- vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
+ to='replica@vesa.yeggmaex.irc'>
...
]]>
- Note that the master MUST NOT send the full jid of the user to any slaves without members that are moderators.
- 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.
+ Note that the primary MUST NOT send the full jid of the user to any replicas without members that are moderators.
+ 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.
-
- 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.
+
+ 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.
- vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
-->
- 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.
- 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.
+
Phaedrus, we're all having a truly rotten time.
@@ -317,7 +323,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
Phaedrus, we're all having a truly rotten time.
@@ -328,7 +334,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
Phaedrus, we're all having a truly rotten time.
@@ -337,36 +343,36 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
stamp='1990-10-13T23:58:37Z'/>
]]>
- 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.
+ 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.
-
- 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.
- Likewise, each slave should ping the master if there has been no traffic for more than the usual amount of time.
+
+ 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.
+ Likewise, each replica should ping the primary if there has been no traffic for more than the usual amount of time.
- A 'lost connection' can be detected by either slave or master when a stanza sent to the master or a slave respectively bounced.
-
- If the master receives a stanza with type=error from the slave JID, it MUST:
+ A 'lost connection' can be detected by either replica or primary when a stanza sent to the primary or a replica respectively bounced.
+
+ If the primary receives a stanza with type=error from the replica JID, it MUST:
- - mark the slave as 'split', making sure that any further broadcasts are not sent to the affected slave
- - start sending pings to the slave with a higher frequency to get a timely notification if the slave reappears
- - resync when the slave reappears as described below
+ - mark the replica as 'split', making sure that any further broadcasts are not sent to the affected replica
+ - start sending pings to the replica with a higher frequency to get a timely notification if the replica reappears
+ - resync when the replica reappears as described below
- In addition, the master MAY send a presence update for each user on the affected slave, marking them as away.
+ In addition, the primary MAY send a presence update for each user on the affected replica, marking them as away.
-
- If the slave receives a stanza with type=error from the master's JID, it MUST:
+
+ If the replica receives a stanza with type=error from the primary's JID, it MUST:
- - stop submitting messages to the master
+ - stop submitting messages to the primary
- react to people sending presence updates or leaving the room and broadcast those changes to local users
- In addition, the slave MAY (and be careful when using this):
+ In addition, the replica MAY (and be careful when using this):
- enable local participants to continue their in-room conversation with other local participants
- enable local participants to continue 1-1 messaging in the context of a room (such as private chat or vcard retrieval)
- enable local users to enter the room (DANGER!!!)
- - enable moderators (as designated by the master) to kick participants
+ - enable moderators (as designated by the primary) to kick participants
- mark non-local users as away
@@ -377,7 +383,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
- This section narratively describes the master-slave protocol in context with client interactions.
+ This section narratively describes the primary-replica protocol in context with client interactions.
The user seeks to enter the wallops chatroom with the room nickname BigCheese:
vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
to='wallops@channel.avalon.irc/BigCheese'>
- The master sends the presence update to each slave to inform the current occupants of BigCheese's arrival:
- The primary sends the presence update to each replica to inform the current occupants of BigCheese's arrival:
+
+ to='replica@killrc.oulubox.irc'>
- vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
+ to='replica@eris.dclxvii.irc'>
- vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
+ to='replica@vesa.yeggmaex.irc'>
...
]]>
- Each slave then distributes this presence update:
- Each replica then distributes this presence update:
+
@@ -435,7 +441,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
to='phaedrus@killrc.oulubox.irc/phone'>
...
]]>
-
@@ -456,24 +462,24 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
...
]]>
-
...
]]>
- The master then informs the slave of the entered user about a new occupant:
- The primary then informs the replica of the entered user about a new occupant:
+
+ to='replica@vesa.yeggmaex.irc'>
...
]]>
- The slave sends presence from existing occupants to new occupant:
- The replica sends presence from existing occupants to new occupant:
+
@@ -517,14 +523,14 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
]]>
and concludes the room roster by sending the new occupant's presence to the new occupant:
- ]]>
- After that, the slave will send the discussion history to the new occupant:
- After that, the replica will send the discussion history to the new occupant:
+
@@ -567,11 +573,11 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
type='groupchat'>
Phaedrus, we're all having a truly rotten time.
]]>
- The master will broadcast this message to all slaves:
- The primary will broadcast this message to all replicas:
+
Phaedrus, we're all having a truly rotten time.
@@ -582,7 +588,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
Phaedrus, we're all having a truly rotten time.
@@ -593,7 +599,7 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
Phaedrus, we're all having a truly rotten time.
@@ -602,8 +608,8 @@ BigCheese ----> vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
stamp='1990-10-13T23:58:37Z'/>
]]>
- And each slave distributes to local occupants
- And each replica distributes to local occupants
+ vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
type='groupchat'>
Phaedrus, we're all having a truly rotten time.
]]>
- vesa.yeggmaex.irc ----> wallops MUC ----> killrc.oulubox.irc ---
type='groupchat'>
Phaedrus, we're all having a truly rotten time.
]]>
- Pusateri
pusateri@bangj.com
+
+ 0.1.3
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.1.2
2019-11-23
@@ -167,7 +173,7 @@
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).
- 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.
+ 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.
diff --git a/xep-0289.xml b/xep-0289.xml
index 2b07eb64..e7d62c15 100644
--- a/xep-0289.xml
+++ b/xep-0289.xml
@@ -24,6 +24,12 @@
FMUC
&ksmithisode;
+
+ 0.2.1
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.2
2012-05-29
@@ -52,8 +58,8 @@
FMUC set - the union of all MUC rooms that federate together
FMUC node - a single MUC room that is a member of an FMUC set (abbreviated to "node")
FMUC room - a room represented by an FMUC set
- Master-Master mode - two FMUC nodes operating such that both will continue to work when a network fails between them. This mode has the properties of reduced network traffic and of not having a guarantee of consistent message ordering between nodes
- Master-Slave mode - two FMUC nodes operating where one, the master, will continue working during a network outage while the slave will cease to work while it cannot communicate with the master. This mode has increased network traffic and a consistent message delivery order across both nodes.
+ 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
+ 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.
Joining FMUC node - a node that initiates an FMUC connection to another node (abbreviated to "joining node").
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.
@@ -64,9 +70,9 @@
- If appropriately configured, avoid bandwidth use that isn't strictly necessary for message exchange.
- - 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.
- - If configured, allow a master/slave configuration such that a disconnected node is no longer usable for local chat
- - Acceptable compromise When operating in multi-master mode the message ordering may not be consistent between FMUC nodes.
+ - 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.
+ - If configured, allow a primary/replica configuration such that a disconnected node is no longer usable for local chat
+ - Acceptable compromise When operating in multi-primary mode the message ordering may not be consistent between FMUC nodes.
@@ -195,7 +201,7 @@
]]>
-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.
+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.
@@ -241,7 +247,7 @@
- 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.
+ 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.
How to get the join-target to tell the joining room how much history to send during a resync.
How to perform a resync (Part and then full rejoin)
- Illustrate master-slave mode - this is simply that the sending room waits for the echo back from the room to which it's joined before distributing messages locally.
+ 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.
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.
diff --git a/xep-0324.xml b/xep-0324.xml
index ea14a320..73629a47 100644
--- a/xep-0324.xml
+++ b/xep-0324.xml
@@ -31,6 +31,12 @@
sensor-network-provisioning
&peterwaher;
+
+ 0.5.1
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.5
2017-05-20
@@ -707,7 +713,8 @@
-
]]>
@@ -864,7 +871,7 @@
-
Access denied.
@@ -917,7 +924,7 @@
@@ -930,7 +937,7 @@
from='device@example.org/device'
to='provisioning.example.org'
id='14'>
-
+
@@ -940,14 +947,14 @@
from='provisioning.example.org'
to='device@example.org/device'
id='14'>
-
+
]]>
@@ -977,7 +984,7 @@
-
+
@@ -1002,7 +1009,7 @@
]]>
@@ -1033,7 +1040,7 @@
@@ -1045,7 +1052,7 @@
from='device@example.org/device'
to='provisioning.example.org'
id='18'>
-
+
@@ -1054,12 +1061,12 @@
from='provisioning.example.org'
to='device@example.org/device'
id='18'>
-
]]>
@@ -1085,7 +1092,7 @@
@@ -1101,7 +1108,7 @@
from='concentrator@example.org/plc'
to='provisioning.example.org'
id='20'>
-
+
+
@@ -1122,7 +1129,7 @@
@@ -1179,7 +1186,7 @@
from='plc@example.org/plc'
to='provisioning.example.org'
id='22'>
-
+
+
sensor-network-control
&peterwaher;
+
+ 0.5.1
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.5
2017-05-20
@@ -348,7 +354,7 @@
@@ -377,7 +383,7 @@
]]>
@@ -399,7 +405,7 @@
@@ -409,7 +415,7 @@
@@ -539,7 +545,7 @@
@@ -742,7 +748,7 @@
]]>
@@ -760,7 +766,7 @@
@@ -780,7 +786,7 @@
@@ -858,7 +864,7 @@
@@ -888,7 +894,7 @@
@@ -936,7 +942,7 @@
@@ -976,7 +982,7 @@
]]>
@@ -990,7 +996,7 @@
@@ -1015,7 +1021,7 @@
jingle-message
&fippo;
&stpeter;
+
+ 0.3.1
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.3
2017-09-11
@@ -270,7 +276,7 @@
Thanks to Lance Stout for his feedback.
- 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.
+ 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.
This document requires no interaction with &IANA;.
diff --git a/xep-0355.xml b/xep-0355.xml
index 2a34fb5c..9430611d 100644
--- a/xep-0355.xml
+++ b/xep-0355.xml
@@ -28,6 +28,12 @@
goffi@goffi.org
goffi@jabber.fr
+
+ 0.4.2
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.4.1
2018-11-03
@@ -608,7 +614,7 @@
Managing entity can manage sensitive data, admin delegation should be granted carefuly, only if you absolutely trust the entity.
A server MAY choose to filter allowed namespaces. In this case, it MUST always set the allowed type of filtered namespaces to 0.
- 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).
+ 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).
diff --git a/xep-0371.xml b/xep-0371.xml
index 5ce9c5e6..9818ac14 100644
--- a/xep-0371.xml
+++ b/xep-0371.xml
@@ -27,6 +27,12 @@
jingle-ice
&stpeter;
+
+ 0.3.1
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.3
2020-05-14
@@ -907,7 +913,7 @@ Romeo Gateway Juliet
- 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;).
- The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in RFC 3921.
- - The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.
+ - The user has explicitly added the contact to a list of entities who are allowed to access the user's personally-identifying information.
diff --git a/xep-0379.xml b/xep-0379.xml
index 2f04f18b..649051a4 100644
--- a/xep-0379.xml
+++ b/xep-0379.xml
@@ -28,6 +28,12 @@
georg@op-co.de
georg@yax.im
+
+ 0.3.3
+ 2021-03-04
+ mw
+ Cross-document editorial adjustments for inclusive language.
0.3.2
2020-01-14
@@ -240,7 +246,7 @@ https://juicyxmpp.example/i/#romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;
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.
@@ -273,7 +279,7 @@ https://juicyxmpp.example/i/#romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;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.
diff --git a/xep-0420.xml b/xep-0420.xml index d4dec42b..1f9f75b8 100644 --- a/xep-0420.xml +++ b/xep-0420.xml @@ -30,6 +30,12 @@Cross-document editorial adjustments for inclusive language.
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.
-Next the extension elements of the &content; elements &payload; element are checked against the whitelist/blacklist and any disallowed elements are discarded.
+Next the extension elements of the &content; elements &payload; element are checked against the permitted list and any disallowed elements are discarded.
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.
Contrary to this, other elements are considered sensitive and MUST NOT be available in plaintext outside the &content; element.
It is hard to come up with a complete list of exceptional elements at this point, as there is no practical implementation experience.
-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.
+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.
| Element | @@ -395,7 +401,7 @@
|---|