barejid/fulljid cleanup

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1675 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0012.xml

@@ -82,7 +82,7 @@
   <p>The requesting entity must interpret the IQ-result based on the responding entity's JID type in order to determine the meaning of the information. Specifically, the information means something different depending on whether the responding entity has a JID of the form 'host', 'user@host', or 'user@host/resource'. These differences are explained more fully below.</p>
 </section1>
 <section1 topic='Offline User Query' anchor='offline'>
-  <p>The primary usage of the 'jabber:iq:last' namespace is to find out how long ago a user logged out (and, additionally, what their status message was at that time). This primary usage assumes that the IQ-get is sent to a bare JID (&BAREJID;). When used in this way, the &QUERY; element contained in the IQ-result has a 'seconds' attribute, which is the number of seconds that have passed since the user last logged out. In addition, the element MAY contain XML character data that specifies the status message of the last unavailable presence received from the user. An example is shown below:</p>
+  <p>The primary usage of the 'jabber:iq:last' namespace is to find out how long ago a user logged out (and, additionally, what their status message was at that time). This primary usage assumes that the IQ-get is sent to a bare JID &BAREJID;. When used in this way, the &QUERY; element contained in the IQ-result has a 'seconds' attribute, which is the number of seconds that have passed since the user last logged out. In addition, the element MAY contain XML character data that specifies the status message of the last unavailable presence received from the user. An example is shown below:</p>
   <example caption='Last Activity Query'><![CDATA[
 <iq from='romeo@montague.net/orchard' to='juliet@capulet.com' type='get' id='last1'>
   <query xmlns='jabber:iq:last'/>
@@ -97,7 +97,7 @@
   <p>Note well that, as specified in &xmppcore; and &xmppim;, an IQ query sent to a JID of the form user@host is handled by a server on the user's behalf, not forwarded to one or more active resources. In addition, a server MUST NOT return last activity information to an entity that is not authorized to view the user's presence information (normally via presence subscription), and MUST return a "Forbidden" error in response to such a request (for information about error conditions, refer to &xep0086;).</p>
 </section1>
 <section1 topic='Online User Query' anchor='online'>
-  <p>When the IQ-get is sent to a full JID (&FULLJID;), the responding entity MAY respond with the idle time of the user.</p>
+  <p>When the IQ-get is sent to a full JID (&LOCALFULL;), the responding entity MAY respond with the idle time of the user.</p>
   <example caption='Online User Last Query'><![CDATA[
 <iq from='romeo@montague.net/orchard' to='juliet@capulet.com/balcony' type='get' id='last2'>
   <query xmlns='jabber:iq:last'/>
@@ -154,11 +154,11 @@
   ]]></example>
 </section1>
 <section1 topic='Implementation Notes' anchor='impl'>
-  <p>The information contained in an IQ reply for this namespace is inherently ambiguous. Specifically, for a bare JID (&BAREJID;) the information is the time since the JID was last connected to its server; for a full JID (&FULLJID;) 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.</p>
+  <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.</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 user@host or user@host/resource; i.e., 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 (&FULLJID;).</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'>
   <p>This document requires no interaction with &IANA;.</p>

xep-0045.xml

@@ -1414,7 +1414,7 @@
   </error>
 </presence>
       ]]></example>
-      <p>However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).</p>
+      <p>However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).</p>
       <p>How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).</p>
     </section3>
     <section3 topic='Max Users' anchor='enter-maxusers'>
@@ -1715,7 +1715,7 @@
   </error>
 </presence>
     ]]></example>
-    <p>However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the <link url='#enter-conflict'>Nickname Conflict</link> section of this document for details.</p>
+    <p>However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the <link url='#enter-conflict'>Nickname Conflict</link> section of this document for details.</p>
     <p>If the user attempts to change his or her room nickname but room nicknames are "locked down", the service MUST deny the nickname change request and return a presence stanza of type "error" specifying a &notacceptable; error condition:</p>
     <example caption='Service Denies Nickname Change Because Roomnicks Are Locked Down'><![CDATA[
 <presence

xep-0065.xml

@@ -397,7 +397,7 @@
     <ol>
       <li>The hostname MUST be SHA1(SID + Initiator JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary).</li>
       <li>The port MUST be 0 (zero).</li>
-      <li>The JIDs provided MUST be the JIDs used for the IQ exchange, which MAY be full JIDs (&FULLJID;) or bare JIDs (&BAREJID;).</li>
+      <li>The JIDs provided MUST be the JIDs used for the IQ exchange, which MAY be full JIDs &FULLJID; or bare JIDs &BAREJID;.</li>
       <li>The appropriate stringprep profiles (as specified in &xmppcore;) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</li>
     </ol>
     <example caption='Target Connects to StreamHost'><![CDATA[

xep-0077.xml

@@ -313,8 +313,8 @@
     ]]></example>
     <p>There are two scenarios:</p>
     <ol>
-      <li><p>If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID (&BAREJID;) associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &rfc3921;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p></li>
+      <li><p>If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &rfc3921;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p></li>
-      <li><p>If the entity cancels its registration with a service other than its home server, its home server MUST stamp a 'from' address on the remove request, which in accordance with <cite>XMPP Core</cite> will be the entity's full JID (&FULLJID;). The service MUST perform the remove based on the bare JID (&BAREJID;) portion of the 'from' address.</p></li>
+      <li><p>If the entity cancels its registration with a service other than its home server, its home server MUST stamp a 'from' address on the remove request, which in accordance with <cite>XMPP Core</cite> will be the entity's full JID &LOCALFULL;. The service MUST perform the remove based on the bare JID &LOCALBARE; portion of the 'from' address.</p></li>
     </ol>
     <p>As specified below, several error cases are possible.</p>
     <table caption='Unregister Error Cases'>

xep-0084.xml

@@ -483,7 +483,7 @@
 </section1>
 <section1 topic='Service Discovery' anchor='disco'>
   <section2 topic='Discovering Avatar Availability' anchor='disco-sub'>
-    <p>The pubsub "auto-subscribe" and "filtered-notifications" features enable a contact to automatically subscribe to a user's avatar. However, a contact can also explicitly determine if another user publishes avatars using this protocol by sending a &xep0030; items ("disco#items") request to the user's bare JID (&BAREJID;).</p>
+    <p>The pubsub "auto-subscribe" and "filtered-notifications" features enable a contact to automatically subscribe to a user's avatar. However, a contact can also explicitly determine if another user publishes avatars using this protocol by sending a &xep0030; items ("disco#items") request to the user's bare JID &LOCALBARE;.</p>
     <example caption='Disco items request'><![CDATA[
 <iq type='get'
     from='romeo@montague.lit/orchard'

xep-0115.xml

@@ -423,7 +423,7 @@
 </iq>
       ]]></example>
 
-      <p>The disco#info request is sent by the requesting entity to the generating entity. The value of the 'to' attribute MUST be the exact JID of the generating entity, which in the case of a client will be the full JID (&FULLJID;).</p>
+      <p>The disco#info request is sent by the requesting entity to the generating entity. The value of the 'to' attribute MUST be the exact JID of the generating entity, which in the case of a client will be the full JID &LOCALFULL;.</p>
 
       <p>The disco 'node' attribute MUST be included for backwards-compatibility. The value of the 'node' attribute SHOULD be generated by concatenating the value of the caps 'node' attribute (e.g., "http://code.google.com/p/exodus") as provided by the generating entity, the "#" character, and the value of the caps 'ver' attribute (e.g., "SrFo9ar2CCk2EnOH4q4QANeuxLQ=") as provided by the generating entity.</p>
 

xep-0136.xml

@@ -333,7 +333,7 @@
     </ul>
   </section2>
   <section2 topic='Setting Modes for a Contact' anchor='pref-contact'>
-    <p>A client may use a similar protocol to set the Modes for a particular contact or domain of contacts (bare JID, full JID or domain). Note: It is STRONGLY RECOMMENDED for the value of the 'jid' attribute to be a bare JID (&BAREJID;).</p>
+    <p>A client may use a similar protocol to set the Modes for a particular contact or domain of contacts (bare JID, full JID or domain). Note: It is STRONGLY RECOMMENDED for the value of the 'jid' attribute to be a bare JID &LOCALBARE; rather than a full JID &LOCALFULL;.</p>
     <example caption='Client Sets Modes for a Contact'><![CDATA[
 <iq type='set' id='pref3'>
   <pref xmlns='http://www.xmpp.org/extensions/xep-0136.html#ns'>

xep-0154.xml

@@ -412,7 +412,7 @@
     ]]></example>
   </section2>
   <section2 topic='Receiving Profile Updates' anchor='consumer-sub'>
-    <p>In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID (&BAREJID;) and specify a node of "http://www.xmpp.org/extensions/xep-0154.html#ns":</p>
+    <p>In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID &LOCALBARE; and specify a node of "http://www.xmpp.org/extensions/xep-0154.html#ns":</p>
     <example caption='Entity subscribes to profile node'><![CDATA[
 <iq type='set'
     from='francisco@denmark.lit/barracks'

xep-0155.xml

@@ -662,7 +662,7 @@ PENDING  o---------------+
     <p>In accordance with the rules specified in <cite>XMPP-IM</cite>, sharing presence enables one party's server to send unavailable presence to the other party if the sending party goes offline for any reason.</p>
   </section2>
   <section2 topic='Unavailable Presence' anchor='impl-unavail'>
-    <p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).</p>
+    <p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID &LOCALFULL; of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).</p>
     <p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Session</link>) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
   </section2>
   <section2 topic='Mapping to SIP' anchor='impl-sip'>

xep-0157.xml

@@ -90,7 +90,7 @@
 </section1>
 <section1 topic='XMPP Addresses' anchor='xmpp'>
   <p>The administrators of an XMPP service may desire to advertise contact information related to that service.
-    <note>Many existing Jabber/XMPP server implementations use the bare domain (&DOMAIN;) of the server (e.g., "example.org") as an alias for the server administrators, such that a &MESSAGE; stanza addressed to that domain name is delivered to the JIDs of the server administrators. (Currently, this functionality does not apply to &IQ; or &PRESENCE; stanzas.) Unfortunately, using the "domain.tld" address as a way to direct messages to the server administrators may result in overloading of the bare domain address (i.e., it may be desirable to send messages to the server's address without having those messages delivered to the server admins, for example if the server doubles as a &xep0060; service). Therefore, it is instead RECOMMENDED to support service discovery of contact addresses as specified herein.</note>
+    <note>Many existing Jabber/XMPP server implementations use the bare domain &DOMAINBARE; of the server (e.g., "example.org") as an alias for the server administrators, such that a &MESSAGE; stanza addressed to that domain name is delivered to the JIDs of the server administrators. (Currently, this functionality does not apply to &IQ; or &PRESENCE; stanzas.) Unfortunately, using the "domain.tld" address as a way to direct messages to the server administrators may result in overloading of the bare domain address (i.e., it may be desirable to send messages to the server's address without having those messages delivered to the server admins, for example if the server doubles as a &xep0060; service). Therefore, it is instead RECOMMENDED to support service discovery of contact addresses as specified herein.</note>
   This contact information may include email addresses, web URLs, and JabberIDs for specific roles and functions such as the service administrators, abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains SHOULD support the electronic mailboxes required by <cite>RFC 2142</cite>. However, additional contact mechanisms may be desirable, and it would be helpful if those who want to initiate contact could discover the contact information using standard XMPP extensions, specifically &xep0030;. To make such discovery possible, we specify a &xep0128; mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in <cite>XEP-0128</cite>) and data form fields registered for this purpose as defined in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
   <p>To illustrate this usage, consider the following example of a disco#info request sent to the mythical shakespeare.lit XMPP server:</p>
   <example caption='Entity queries server for information'><![CDATA[

xep-0163.xml

@@ -306,7 +306,7 @@
   </ol>
   <p>These principles are described more fully below.</p>
   <section2 topic='Every Account a Pubsub Service' anchor='approach-everyjid'>
-    <p>When a user creates an account (or has an account provisioned) at a Jabber/XMPP server that supports PEP, the server associates a virtual pubsub service with the account. This greatly simplifies the task of discovering the account owner's personal pubsub nodes, since the root pubsub node simply is the account owner's bare JID (&BAREJID;). This assumption also simplifies publishing and subscribing.</p>
+    <p>When a user creates an account (or has an account provisioned) at a Jabber/XMPP server that supports PEP, the server associates a virtual pubsub service with the account. This greatly simplifies the task of discovering the account owner's personal pubsub nodes, since the root pubsub node simply is the account owner's bare JID &BAREJID;. This assumption also simplifies publishing and subscribing.</p>
   </section2>
   <section2 topic='One Publisher Per Node' anchor='approach-publisher'>
     <p>There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.</p>
@@ -373,17 +373,17 @@
   <section2 topic='Generating Notifications' anchor='notify-generate'>
     <section3 topic='Addressing' anchor='notify-addressing'>
       <ol start='1'>
-        <li><p>The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in these examples, "juliet@capulet.lit").</p></li>
+        <li><p>The server MUST set the 'from' address on the notification to the bare JID &BAREJID; of the account owner (in these examples, "juliet@capulet.lit").</p></li>
         <li><p>Any errors generated by the recipient or the recipient's server in relation to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.</p></li>
         <li><p>When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &xep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.lit/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner.</p></li>
-        <li><p>If the PEP service has presence information about the intended recipient, it SHOULD direct the notification(s) to the full JID(s) of the recipients (&FULLJID;); if the PEP service does not have presence information about a subscriber, it MUST address the notification to the subscriber's bare JID (&BAREJID;).</p></li>
+        <li><p>If the PEP service has presence information about the intended recipient, it SHOULD direct the notification(s) to the full JID(s) of the recipient's &FULLJID;; if the PEP service does not have presence information about a subscriber, it MUST address the notification to the subscriber's bare JID &BAREJID;.</p></li>
       </ol>
     </section3>
     <section3 topic='Number of Notifications' anchor='notify-num'>
       <ol start='1'>
-        <li><p>If a subscriber subscribed using a full JID (&FULLJID;), domain identifier (&DOMAIN;), or domain plus resource (&DOMAINRES;), a PEP service MUST send one notification only, addressed to the subscribed JID.</p></li>
+        <li><p>If an entity subscribed using a full JID &FULLJID; or a bare domain identifier &DOMAINBARE;, a PEP service MUST send one notification only, addressed to the subscribed JID.</p></li>
-        <li><p>If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID (&BAREJID;) of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and <cite>XEP-0115</cite> data that indicates interest in the relevant data format.)</p></li>
+        <li><p>If a subscriber subscribed using a local JID &LOCAL; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the local JID &LOCAL; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and <cite>XEP-0115</cite> data that indicates interest in the relevant data format.)</p></li>
-        <li><p>If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID (&FULLJID;) of each of the subscriber's available resources that have specified non-negative presence priority and included <cite>XEP-0115</cite> information that indicates an interest in the data format.</p></li>
+        <li><p>If a subscriber subscribed using a local JID &LOCAL; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have specified non-negative presence priority and included <cite>XEP-0115</cite> information that indicates an interest in the data format.</p></li>
       </ol>
     </section3>
     <section3 topic='When to Generate Notifications' anchor='notify-when'>
@@ -444,7 +444,7 @@
     <li>Support the "owner" and "subscriber" affiliations.</li>
     <li>Support the "presence" access model and set it to the default.</li>
     <li>Support the "open", "roster", and "whitelist" access models.</li>
-    <li>Treat the account owner's bare JID (&BAREJID;) as a collection node (i.e., as the root collection node for the account's virtual pubsub service).</li>
+    <li>Treat the account owner's bare JID &BAREJID; as a collection node (i.e., as the root collection node for the account's virtual pubsub service).</li>
     <li>Default the 'deliver_notifications' configuration option to true (i.e., deliver payloads by default).</li>
     <li>Default the 'send_last_published_item' configuration option to true (i.e., send the last publish item by default).</li>
   </ul>
@@ -488,7 +488,7 @@
     ]]></example>
   </section2>
   <section2 topic='Contact Service Discovery' anchor='disco-contact'>
-    <p>A contact MAY send service discovery requests to the account owner's bare JID (&BAREJID;). If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in <cite>XEP-0060</cite>.</p>
+    <p>A contact MAY send service discovery requests to the account owner's bare JID &BAREJID;. If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in <cite>XEP-0060</cite>.</p>
     <p>Note: When returning disco#info results, the account owner's server MUST check the access model for each of the account owner's PEP nodes and MUST return as service discovery items only those nodes to which the contact is allowed to subscribe or from which the contact is allowed to retrieve items without first subscribing.</p>
   </section2>
 </section1>

xep-0168.xml

@@ -127,7 +127,7 @@
   <p>As extensions to that core use case, this document also defines:</p>
   <ul>
     <li>A way for an XMPP server to mark which resource it considers to be primary for any given application type, if it has information -- such as communication preferences -- that can help it determine the primary resource.</li>
-    <li>A way for an XMPP server to use application priority data for more intelligent routing of specially-labelled XMPP &MESSAGE; stanzas directed to a user's bare JID (&BAREJID;).</li>
+    <li>A way for an XMPP server to use application priority data for more intelligent routing of specially-labelled XMPP &MESSAGE; stanzas directed to a user's bare JID &LOCALBARE;.</li>
   </ul>
 </section1>
 <section1 topic='Application Priority' anchor='rap'>
@@ -276,7 +276,7 @@
   </ol>
 </section1>
 <section1 topic='RAP-Based Message Routing' anchor='route'>
-  <p>A server MAY use the RAP data provided by a client in determing how to route incoming &MESSAGE; stanzas directed to the bare JID (&BAREJID;) of a registered account. In order to enable such routing, the sender MUST include an empty &lt;route/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0168.html#ns-raproute' namespace &NSNOTE; including an 'ns' attribute corresponding to the desired application type.</p>
+  <p>A server MAY use the RAP data provided by a client in determing how to route incoming &MESSAGE; stanzas directed to the bare JID &LOCALBARE; of a registered account. In order to enable such routing, the sender MUST include an empty &lt;route/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0168.html#ns-raproute' namespace &NSNOTE; including an 'ns' attribute corresponding to the desired application type.</p>
   <p>For example, consider a &xep0155; request sent from one user (Romeo) to another (Juliet), where the users do not share presence. Romeo wants the request to be delivered to the highest-priority resource for the "http://www.xmpp.org/extensions/xep-0167.html#ns" application type.</p>
   <example caption="User requests session"><![CDATA[
 <message from='romeo@montague.lit/orchard'

xep-0172.xml

@@ -105,7 +105,7 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <p>A nickname is a global, memorable (but not necessarily unique) friendly or informal name chosen by the owner of a bare JID (&BAREJID;) for the purpose of associating a distinctive mapping between the person's unique JID and non-unique nickname. While nicknames have been a common feature of instant messaging systems for many years, they have not always featured prominently in Jabber/XMPP IM systems (e.g., nicknames are not specified in &rfc3921;). However, there are several reasons why nicknames are important:</p>
+  <p>A nickname is a global, memorable (but not necessarily unique) friendly or informal name chosen by the owner of a bare JID &LOCALBARE; for the purpose of associating a distinctive mapping between the person's unique JID and non-unique nickname. While nicknames have been a common feature of instant messaging systems for many years, they have not always featured prominently in Jabber/XMPP IM systems (e.g., nicknames are not specified in &rfc3921;). However, there are several reasons why nicknames are important:</p>
   <ul>
     <li>Users like them.</li>
     <li>They are easier to remember than JIDs.</li>
@@ -122,7 +122,7 @@
     </tr>
     <tr>
       <td>Jabber ID (JID)</td>
-      <td>A global and unique XMPP identifier registered to a particular user, of the form &BAREJID;; represented in the 'from' attribute of XML stanzas sent by that user, the 'jid' attribute of items associated with that user in a contact's roster, etc.</td>
+      <td>A global and unique XMPP identifier registered to a particular user, of the form &LOCALBARE;; represented in the 'from' attribute of XML stanzas sent by that user, the 'jid' attribute of items associated with that user in a contact's roster, etc.</td>
     </tr>
     <tr>
       <td>Nickname</td>

xep-0175.xml

@@ -58,7 +58,7 @@
     <li>The client specifies a desired resource identifier but the server does not accept it, instead overruling the client and assigning a resource identifier.</li>
     <li>The client asks the server to assign a resource identifier and the server does so.</li>
   </ol>
-  <p>No matter which scenario is enacted, at the end of the process the server informs the client of its full JID (&FULLJID;). In particular, it might be helpful for an XMPP server to assign a full JID to the client (i.e., not just the resource identifier) if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID" portion (&BAREJID;) is unique in the context of the domain served by the server.</p>
+  <p>No matter which scenario is enacted, at the end of the process the server informs the client of its full JID &LOCALFULL;. In particular, it might be helpful for an XMPP server to assign a full JID to the client (i.e., not just the resource identifier) if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID" portion &LOCALBARE; is unique in the context of the domain served by the server.</p>
   <p>The method for ensuring the uniqueness of the node identifier is a matter of implementation. It is RECOMMENDED for the node identifier to be a UUID as specified in &rfc4122;.</p>
   <p>Although <cite>RFC 4505</cite> allows the initiating entity (client) to provide so-called "trace data" when authenticating via SASL ANONYMOUS, it is NOT RECOMMENDED to include trace data as the XML character data of the &lt;auth/&gt; element (instead, the &lt;auth/&gt; element SHOULD be empty). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., in server logs).</p>
 </section1>

xep-0184.xml

@@ -114,7 +114,7 @@
 <section1 topic='Business Rules' anchor='rules'>
   <p>The following business rules apply:</p>
   <ol start='1'>
-    <li><p>A sender SHOULD NOT include a request for message receipts when sending a message to the bare JID (&BAREJID;) of the recipient, only when sending to a full JID (&FULLJID;).</p></li>
+    <li><p>A sender SHOULD NOT include a request for message receipts when sending a message to the bare JID &LOCALBARE; of the recipient, only when sending to a full JID &LOCALFULL;.</p></li>
     <li><p>A sender SHOULD NOT include a request for message receipts unless it knows (via &xep0030; or &xep0115;) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via &xep0155;.</p></li>
     <li><p>A sender SHOULD include an 'id' attribute on the message so that the sender can properly track the receipt.</p></li>
   </ol>

xep-0186.xml

@@ -138,8 +138,8 @@
       <li><p>MUST NOT broadcast presence notifications as a result of receiving any subsequent undirected presence notifications from the client.</p></li>
       <li><p>MUST deliver directed presence stanzas generated by the client.</p></li>
       <li><p>MUST deliver inbound &PRESENCE; stanzas.</p></li>
-      <li><p>SHOULD deliver inbound &MESSAGE; stanzas whose 'to' address is the bare JID (&BAREJID;) of the user (subject to standard XMPP stanza handling rules).</p></li>
+      <li><p>SHOULD deliver inbound &MESSAGE; stanzas whose 'to' address is the bare JID &LOCALBARE; of the user (subject to standard XMPP stanza handling rules).</p></li>
-      <li><p>MUST deliver inbound &MESSAGE; and &IQ; stanzas whose 'to' address is the full JID (&FULLJID;) corresponding to the resource of the client.</p></li>
+      <li><p>MUST deliver inbound &MESSAGE; and &IQ; stanzas whose 'to' address is the full JID &LOCALFULL; corresponding to the resource of the client.</p></li>
       <li><p>MUST deliver outbound &MESSAGE; and &IQ; stanzas generated by the client (for an important note regarding presence leaks, see the <link url='#security'>Security Considerations</link> section of this document).</p></li>
     </ol>
     <p>If after sending directed presence the client then sends &UNAVAILABLE;, the server MUST deliver that unavailable presence only to the entities to which the client sent directed presence after going invisible.</p>

xep-0193.xml

@@ -71,7 +71,7 @@
   </unbind>
 </iq>
   ]]></code>
-  <p>If the server does not understand the &lt;unbind/&gt; element, it MUST return an error of &badrequest;. Otherwise, if there is no such resource, the server MUST return an error of &notfound;. When the client unbinds the only resource associated with the stream, the server SHOULD close the stream and terminate the TCP connection. The 'from' address included in bind and unbind stanzas SHOULD be the full JID (&FULLJID;) associated with the resource in question; however, the server MUST NOT accept further stanzas from that full JID after successfully processing the unbind request.</p>
+  <p>If the server does not understand the &lt;unbind/&gt; element, it MUST return an error of &badrequest;. Otherwise, if there is no such resource, the server MUST return an error of &notfound;. When the client unbinds the only resource associated with the stream, the server SHOULD close the stream and terminate the TCP connection. The 'from' address included in bind and unbind stanzas SHOULD be the full JID &LOCALFULL; associated with the resource in question; however, the server MUST NOT accept further stanzas from that full JID after successfully processing the unbind request.</p>
   <p>A server SHOULD advertise its support for the 'urn:ietf:params:xml:ns:xmpp-bind' namespace and the unbind functionality by returning an appropriate stream feature as shown below:</p>
   <code><![CDATA[
 <stream:features>
@@ -84,7 +84,7 @@
 </section1>
 <section1 topic='Business Rules' anchor='bizrules'>
   <section2 topic='From Addresses' anchor='from'>
-    <p>When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID (&FULLJID;) associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an &lt;unknown-sender/&gt; stanza error. <note>Currently there is no &lt;unknown-sender/&gt; stanza defined in <cite>RFC 3920</cite>. The author will work to add such an error condition (with a type of "modify") to <cite>rfc3920bis</cite>.</note></p>
+    <p>When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID &LOCALFULL; associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an &lt;unknown-sender/&gt; stanza error. <note>Currently there is no &lt;unknown-sender/&gt; stanza defined in <cite>RFC 3920</cite>. The author will work to add such an error condition (with a type of "modify") to <cite>rfc3920bis</cite>.</note></p>
     <p>Naturally, the existing rules from <cite>RFC 3920</cite> regarding validation of asserted 'from' addresses still apply.</p>
   </section2>
   <section2 topic='Server Sessions' anchor='sessions'>

xep-0199.xml

@@ -109,7 +109,7 @@
   <ping xmlns='urn:xmpp:ping'/>
 </iq>
     ]]></example>
-    <p>Note: The client MAY include a 'to' address of the client's bare JID (&BAREJID;, in this instance "juliet@capulet.lit" or MAY include no 'to' address (this signifies that the stanza shall be handled by the server on behalf of the connected user's bare JID, which in the case of &IQ; stanzas is equivalent to directing the IQ-get to the server itself).</p>
+    <p>Note: The client MAY include a 'to' address of the client's bare JID &LOCALBARE;, in this instance "juliet@capulet.lit" or MAY include no 'to' address (this signifies that the stanza shall be handled by the server on behalf of the connected user's bare JID, which in the case of &IQ; stanzas is equivalent to directing the IQ-get to the server itself).</p>
     <p>If the server supports the ping namespace, it MUST return an IQ-result:</p>
     <example caption="Pong"><![CDATA[
 <iq from='capulet.lit' to='juliet@capulet.lit/balcony' id='c2s1' type='result'/>
@@ -157,7 +157,7 @@
   <ping xmlns='urn:xmpp:ping'/>
 </iq>
     ]]></example>
-    <p>Note: The 'to' address should be a full JID (&FULLJID;), since a ping sent to a bare JID (&BAREJID;) will be handled by the server on behalf of the client.</p>
+    <p>Note: The 'to' address should be a full JID &LOCALFULL;, since a ping sent to a bare JID &LOCALBARE; will be handled by the server on behalf of the client.</p>
     <p>If the pinged entity supports the ping namespace, it SHOULD return an IQ-result:</p>
     <example caption="Pong"><![CDATA[
 <iq from='juliet@capulet.lit/chamber'
@@ -189,7 +189,7 @@
   <ping xmlns='urn:xmpp:ping'/>
 </iq>
     ]]></example>
-    <p>Note: The 'to' address should be a full JID (&FULLJID;), since a ping sent to a bare JID (&BAREJID;) will be handled by the server on behalf of the client.</p>
+    <p>Note: The 'to' address should be a full JID &LOCALFULL;, since a ping sent to a bare JID &LOCALBARE; will be handled by the server on behalf of the client.</p>
     <p>If the pinged entity supports the ping namespace, it SHOULD return an IQ-result:</p>
     <example caption="Pong"><![CDATA[
 <iq from='juliet@capulet.lit/chamber'
@@ -237,7 +237,7 @@
   ]]></example>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
-  <p>If a server receives a ping request directed to a full JID (&FULLJID;) associated with a registered account but there is no connected resource matching the 'to' address, it MUST reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.</p>
+  <p>If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, it MUST reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.</p>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>

xep-0219.xml

@@ -176,7 +176,7 @@
       <li>If the respondent does not support the hopcheck namespace, it MUST return a &unavailable; error.</li>
       <li>If the &lt;hopcheck/&gt; element does not include a 'to' attribute, the respondent MUST return a &badrequest; error.</li>
       <li>If the 'to' or 'for' attribute of the &lt;hopcheck/&gt; element contains a JID that is malformed, the respondent MUST return a &badjid; error.</li>
-      <li>If the respondent is a server and the sender is a full JID (&FULLJID;), the server MUST verify that the JID is a connected resource of the server (per <cite>RFC 3920</cite>); if it is not, then the respondent MUST return a &forbidden; error.</li>
+      <li>If the respondent is a server and the sender is a full JID &LOCALFULL;, the server MUST verify that the JID is a connected resource of the server (per <cite>RFC 3920</cite>); if it is not, then the respondent MUST return a &forbidden; error.</li>
       <li>If both the sender and the respondent are servers and the domain identifier of the &lt;hopcheck/&gt; element's 'to' attribute does not match a validated domain of the respondent, the respondent MUST return a &notfound; error.</li>
       <li>If both the sender and the respondent are servers, the JID of the &lt;hopcheck/&gt; element's 'to' is a connected resource of the respondent server, and the JID of the &lt;hopcheck/&gt; element's 'for' is not authorized to know the presence of the target (either via presence subscription or temporary presence sharing via directed presence as defined in &rfc3921;), then the respondent MUST return a &forbidden; error.</li>
     </ul>

xep-0222.xml

@@ -41,7 +41,7 @@
 
 <section1 topic='Introduction' anchor='intro'>
   <section2 topic='Motivation' anchor='motivation'>
-    <p>&xep0163; introduced the idea of a virtual &xep0060; service associated with an IM user's bare JID (&BAREJID;). However, personal eventing (PEP) is not optimized for the persistent storage of semi-public data objects such as public keys or user profiles. Therefore this document defines a set of best practices that enable an IM user to persistently store semi-public data objects at their virtual pubsub service; in effect, we "sub-class" PEP by showing how a particular pubsub node can be configured for persisting objects (we call such a node a "POP node").</p>
+    <p>&xep0163; introduced the idea of a virtual &xep0060; service associated with an IM user's bare JID &LOCALBARE;. However, personal eventing (PEP) is not optimized for the persistent storage of semi-public data objects such as public keys or user profiles. Therefore this document defines a set of best practices that enable an IM user to persistently store semi-public data objects at their virtual pubsub service; in effect, we "sub-class" PEP by showing how a particular pubsub node can be configured for persisting objects (we call such a node a "POP node").</p>
   </section2>
   <section2 topic='How It Works' anchor='howitworks'>
     <p>This section provides a friendly introduction to persisting objects via pubsub (a.k.a. POP).</p>

xep-0223.xml

@@ -41,7 +41,7 @@
 
 <section1 topic='Introduction' anchor='intro'>
   <section2 topic='Motivation' anchor='motivation'>
-    <p>&xep0163; introduced the idea of a virtual &xep0060; service associated with an IM user's bare JID (&BAREJID;). However, personal eventing (PEP) is not optimized for the persistent storage of data objects that are meant to be accessed only by the account owner, &#224; la &xep0049;. Therefore this document defines a set of best practices that enable a user to persistently store private information at their virtual pubsub service; in effect, we "sub-class" PEP by showing how a particular pubsub node can be configured for storing private information (we call such a node a "PIP node").</p>
+    <p>&xep0163; introduced the idea of a virtual &xep0060; service associated with an IM user's bare JID &LOCALBARE;. However, personal eventing (PEP) is not optimized for the persistent storage of data objects that are meant to be accessed only by the account owner, &#224; la &xep0049;. Therefore this document defines a set of best practices that enable a user to persistently store private information at their virtual pubsub service; in effect, we "sub-class" PEP by showing how a particular pubsub node can be configured for storing private information (we call such a node a "PIP node").</p>
   </section2>
   <section2 topic='How It Works' anchor='howitworks'>
     <p>This section provides a friendly introduction to private information via pubsub (a.k.a. PIP).</p>