Multiple XEPs: Cross-document editorial adjustments for inclusive lan…

…guage.

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.

xep-0009.xml

@@ -29,6 +29,12 @@
     <email>[email protected]</email>
     <jid>[email protected]</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>

xep-0011.xml

@@ -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>

xep-0045.xml

@@ -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 [email protected] is allowed to log in simultaneously as the nick "JuliC" in the [email protected] chatroom from both [email protected]/balcony and [email protected]/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[

xep-0060.xml

@@ -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>

xep-0062.xml

@@ -29,6 +29,12 @@
     <email>[email protected]</email>
     <jid>[email protected]</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>

xep-0065.xml

@@ -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>

xep-0073.xml

@@ -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>

xep-0130.xml

@@ -50,6 +50,12 @@
       <jid>[email protected]</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>