Replace all HTML cite elements with XML entities

Prior to this change, some XEPs are being referenced by an XML entity (eg `&xep0030;`) while others use a HTML cite element (eg `<cite>XEP-0030</cite>`). The latter doesn't seem to do anything with regards to rendering (there's no link to the reference list, for example).

All references to XEPs (and RFCs) _should_ be based on XML entities, as (briefly) discussed in the XSF Discussion chatroom: https://logs.xmpp.org/xsf/2024-08-29#2024-08-29-67941f0944ae8365

The changes in this commit are the result of executing these two commands:

```
sed -i -E 's/<cite>XEP-([0-9]{4})<\/cite>/\&xep\1\;/' xep-*.xml
sed -i -E 's/<cite>RFC ([0-9]{4})<\/cite>/\&rfc\1\;/' xep-*.xml
```

xep-0001.xml

@@ -217,7 +217,7 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <p>The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, <note>Effectively the only such exceptions are protocols that were superseded by <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. <note>The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see <link url="http://python.sourceforge.net/peps/pep-0001.html">PEP-1</link>). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations. (Note: The term "XEP" is normally pronounced "zepp".)</note></p>
+  <p>The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, <note>Effectively the only such exceptions are protocols that were superseded by &rfc3920; and <cite>RFC 3921</cite>.</note> such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. <note>The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see <link url="http://python.sourceforge.net/peps/pep-0001.html">PEP-1</link>). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations. (Note: The term "XEP" is normally pronounced "zepp".)</note></p>
   <p>Advancement of a XEP through the XSF's standards process is contingent on three factors:</p>
   <ul>
     <li>Rough consensus on the XSF's public discussion lists.</li>
@@ -446,7 +446,7 @@ Experimental ----> Proposed ----> Active
 </section1>
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
   <p>The &REGISTRAR; performs a function similar to the IANA, although limited to the XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of XMPP protocols (for example, the categories and types used in &xep0030;).</p>
-  <p>Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Stable (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Stable or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Stable or Active. For details regarding the XMPP Registrar and its processes, refer to <cite>XEP-0053</cite>.</p>
+  <p>Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Stable (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Stable or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Stable or Active. For details regarding the XMPP Registrar and its processes, refer to &xep0053;.</p>
   <p>A XEP may also request that a new registry is to be created by the XMPP Registrar. The XEP author must clearly define the nature of the new registry as well as the process for submitting data to the registry, and should do so in collaboration with the Registrar.</p>
 </section1>
 <section1 topic='XML Schema' anchor='schema'>

xep-0012.xml

@@ -231,7 +231,7 @@
   <p>The information contained in an IQ reply for this namespace is inherently ambiguous. Specifically, for a bare JID &LOCALBARE; the information is the time since the JID was last connected to its server; for a full JID &LOCALFULL; the information is the time since the resource was last active in the context of an existing session; and for a bare domain the information is the uptime for the server or component. An application MUST take these differences into account when presenting the information to a human user (if any).</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
-  <p>A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form &LOCALBARE; or &LOCALFULL;, since doing so would constitute a "presence leak" as described in <cite>RFC 6120</cite>. That is, Last Activity information MAY be divulged only to those entities that have permission to view the user's presence via a presence subscription (potentially as restricted by &xep0016; or &xep0191;).</p>
+  <p>A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form &LOCALBARE; or &LOCALFULL;, since doing so would constitute a "presence leak" as described in &rfc6120;. That is, Last Activity information MAY be divulged only to those entities that have permission to view the user's presence via a presence subscription (potentially as restricted by &xep0016; or &xep0191;).</p>
   <p>A client MUST provide a way for a human user to disable sending of Last Activity responses from the client's full JID &LOCALFULL;.</p>
 </section1>
 <section1 topic='IANA Considerations' anchor='iana'>

xep-0013.xml

@@ -144,7 +144,7 @@
     <p>If the server supports this protocol, it MUST return a &lt;feature/&gt; element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.</p>
   </section2>
   <section2 topic='Requesting Number of Messages' anchor='request-number'>
-    <p><cite>RFC 1939</cite> includes a feature (the "STAT" command) that enables a user to determine how many messages are waiting to be retrieved (without retrieving all of the headers). Such a feature would be helpful in Jabber/XMPP as well, especially if the client is constrained with regard to storage capacity or available bandwidth.</p>
+    <p>&rfc1939; includes a feature (the "STAT" command) that enables a user to determine how many messages are waiting to be retrieved (without retrieving all of the headers). Such a feature would be helpful in Jabber/XMPP as well, especially if the client is constrained with regard to storage capacity or available bandwidth.</p>
     <p>In order to determine the number of messages in the offline message queue, the user sends a disco#info request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline':</p>
     <example caption='User Requests Information About Offline Message Node'><![CDATA[
 <iq type='get'>

xep-0016.xml

@@ -102,7 +102,7 @@
 </header>
 <section1 topic="Introduction">
   <p>Almost all types of Instant Messaging (IM) applications have found it necessary to develop some method for a user to block the receipt of messages and packets from other users (the rationale for such blockage depends on the needs of the individual user). This document defines a flexible method for communications blocking.</p>
-  <p>Note: The protocol specified herein MAY be used in conjunction with &xep0191;; see <cite>XEP-0191</cite> for details.</p>
+  <p>Note: The protocol specified herein MAY be used in conjunction with &xep0191;; see &xep0191; for details.</p>
 </section1>
 
 <section1 topic="Protocol" anchor="protocol">
@@ -150,7 +150,7 @@
       <li>&lt;domain&gt; (the domain itself matches, as does any user@domain or domain/resource)</li>
     </ol>
     <p>If the type is "group", then the 'value' attribute SHOULD contain the name of a group in the user's roster.  (If a client attempts to update, create, or delete a list item with a group that is not in the user's roster, the server SHOULD return to the client an &lt;item-not-found/&gt; stanza error.)</p>
-    <p>If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined <cite>RFC 6121</cite>, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all. These values are exact matches, so that "both" means a bidirectional subscription (not "from" or "to" only).</p>
+    <p>If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined &rfc6121;, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all. These values are exact matches, so that "both" means a bidirectional subscription (not "from" or "to" only).</p>
     <p>If no 'type' attribute is included, the rule provides the "fall-through" case.</p>
     <p>The 'action' attribute MUST be included and its value MUST be either "allow" or "deny". <note>An implementation MUST NOT block communications from one of a user's resources to another, even if the user happens to define a rule that would otherwise result in that behavior.</note></p>
     <p>The 'order' attribute MUST be included and its value MUST be a non-negative integer that is unique among all items in the list.  (If a client attempts to create or update a list with non-unique order values, the server MUST return to the client a &lt;bad-request/&gt; stanza error.)</p>
@@ -169,8 +169,8 @@
     <ol>
       <li><p>If there is an active list set for a session, it affects only the session(s) for which it is activated, and only for the duration of the session(s); the server MUST apply the active list only and MUST NOT apply the default list (i.e., there is no "layering" of lists).</p></li>
       <li><p>The default list applies to the user as a whole, and is processed if there is no active list set for the target session/resource to which a stanza is addressed, or if there are no current sessions for the user.</p></li>
-      <li><p>If there is no active list set for a session (or there are no current sessions for the user), and there is no default list, then all stanzas SHOULD BE accepted or appropriately processed by the server on behalf of the user in accordance with the server rules for handling XML stanzas defined in <cite>RFC 6121</cite>.</p></li>
-      <li><p>Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in server rules for handling XML stanzas defined in <cite>RFC 6121</cite> and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in <cite>RFC 6121</cite>.</p></li>
+      <li><p>If there is no active list set for a session (or there are no current sessions for the user), and there is no default list, then all stanzas SHOULD BE accepted or appropriately processed by the server on behalf of the user in accordance with the server rules for handling XML stanzas defined in &rfc6121;.</p></li>
+      <li><p>Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in server rules for handling XML stanzas defined in &rfc6121; and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in <cite>RFC 6121</cite>.</p></li>
       <li><p>The order in which privacy list items are processed by the server is important.  List items MUST be processed in ascending order determined by the integer values of the 'order' attribute for each &lt;item/&gt;.</p></li>
       <li><p>As soon as a stanza is matched against a privacy list rule, the server MUST appropriately handle the stanza in accordance with the rule and cease processing.</p></li>
       <li><p>If no fall-through item is provided in a list, the fall-through action is assumed to be "allow".</p></li>
@@ -637,7 +637,7 @@
 </iq>
 ]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p>
-    <p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 6121</cite>).</p>
+    <p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in &rfc6121;).</p>
   </section2>
   <section2 topic="Blocking IQ Stanzas" anchor="protocol-iq">
     <p>Server-side privacy lists enable a user to block incoming IQ stanzas from other entities based on the entity's JID, roster group, or subscription status (or globally).  The following examples illustrate the protocol.</p>
@@ -755,7 +755,7 @@
     <p>If a blocked entity attempts to send a stanza to the user (i.e., an inbound stanza from the user's perspective), the user's server shall handle the stanza according to the following rules:</p>
     <ul>
       <li>For presence stanzas (including notifications, subscriptions, and probes), the server MUST NOT respond and MUST NOT return an error.</li>
-      <li>For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. <note>Until version 1.5 of this document (therefore also in <cite>RFC 6121</cite>), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.</note></li>
+      <li>For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. <note>Until version 1.5 of this document (therefore also in &rfc6121;), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.</note></li>
       <li>For IQ stanzas of type "get" or "set", the server MUST return an error, which SHOULD be &unavailable;. IQ stanzas of other types MUST be silently dropped by the server.</li>
     </ul>
     <p>If the foregoing suggestions are followed, the user will appear offline to the contact.</p>
@@ -843,7 +843,7 @@
   <p>A service MAY also filter blocking users out of searches performed on user directories (see, for example, &xep0055;); however, that functionality is out of scope for this specification.</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
-  <p>If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in <cite>RFC 6120</cite> and <cite>RFC 6121</cite>.</p>
+  <p>If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in &rfc6120; and <cite>RFC 6121</cite>.</p>
 </section1>
 <section1 topic='IANA Considerations' anchor='iana'>
   <p>No interaction with &IANA; is required as a result of this specification.</p>

xep-0026.xml

@@ -138,7 +138,7 @@
 
 	<section2 topic='Service support'>
 		<p>
-			Jabber based services that wish to comply to this document have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on <cite>XEP-0004</cite>.
+			Jabber based services that wish to comply to this document have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on &xep0004;.
 		</p>
 		<example caption='Search form in English'>
 &lt;iq from='users.jabber.org' type='result' id='4' xml:lang='en'&gt;

xep-0030.xml

@@ -653,7 +653,7 @@
   </section1>
 
   <section1 topic='Publishing Available Items' anchor='publish'>
-    <p>This feature has been removed in favor of the XMPP publish-subscribe technology defined in <cite>XEP-0060</cite>.</p>
+    <p>This feature has been removed in favor of the XMPP publish-subscribe technology defined in &xep0060;.</p>
   </section1>
 
   <section1 topic='Implementation Notes' anchor='impl'>
@@ -718,7 +718,7 @@
         <p>In response to a disco#items request, the server MUST return an empty result set if:</p>
         <ol>
           <li>The target entity does not exist (no matter if the request specifies a node or not).</li>
-          <li>The request did not specify a node, the only items are available resources (as defined in <cite>RFC 3921</cite>), and the requesting entity is not authorized to receive presence from the target entity (i.e., via the target having a presence subscription to the requesting entity of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network). <note>However, the server MAY return items other than available resources (if any).</note></li>
+          <li>The request did not specify a node, the only items are available resources (as defined in &rfc3921;), and the requesting entity is not authorized to receive presence from the target entity (i.e., via the target having a presence subscription to the requesting entity of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network). <note>However, the server MAY return items other than available resources (if any).</note></li>
         </ol>
       </li>
     </ol>

xep-0035.xml

@@ -122,7 +122,7 @@ S: <stream:stream xmlns='jabber:client'
 <section1 topic="Certificate-based authentication">
   <p>TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile (see &xep0034;) and the EXTERNAL mechanism.</p>
 
-  <p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and <cite>XEP-0034</cite> for more information.</p>
+  <p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and &xep0034; for more information.</p>
 
   <p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
 </section1>