From 4c62b84b7cd2f6abcfe7326c2940854ac4570522 Mon Sep 17 00:00:00 2001
From: Stefan Strigler <stefan@strigler.de>
Date: Mon, 18 Jul 2016 17:51:31 +0200
Subject: [PATCH] an XMPP ...

---
 xep-0060.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xep-0060.xml b/xep-0060.xml
index 49b5f18f..763b9e8e 100644
--- a/xep-0060.xml
+++ b/xep-0060.xml
@@ -481,7 +481,7 @@ And by opposing end them?
   </ul>
 
         <!-- =================== MAYS and SHOULDS =================== -->
-  <p>Some of the possible uses of a XMPP-based pubsub service will require other features, but these features are OPTIONAL and therefore not mandatory for compliance with this specification. However, if these features are implemented, they MUST adhere to the protocol described herein in to be compliant. These features include:</p>
+  <p>Some of the possible uses of an XMPP-based pubsub service will require other features, but these features are OPTIONAL and therefore not mandatory for compliance with this specification. However, if these features are implemented, they MUST adhere to the protocol described herein in to be compliant. These features include:</p>
   <ul>
     <li>A service MAY cache the last item published to a node (even if the "persistent-items" option is set to false); if it does default "cache-last-item" to true, it SHOULD send the last published item (or notification thereof) to subscribed entities based on configuration of the "send_last_published_item" field.</li>
     <li>A node owner SHOULD be able to specify who may subscribe to a node.</li>
@@ -1141,7 +1141,7 @@ And by opposing end them?
 
   <section2 topic='Subscribe to a Node' anchor='subscriber-subscribe'>
     <section3 topic='Request' anchor='subscriber-subscribe-request'>
-      <p>When a XMPP entity wishes to subscribe to a node, it sends a subscription request to the pubsub service. The subscription request is an IQ-set where the &lt;pubsub/&gt; element contains one and only one &lt;subscribe/&gt; element. The &lt;subscribe/&gt; element SHOULD possess a 'node' attribute specifying the node to which the entity wishes to subscribe. The &lt;subscribe/&gt; element MUST also possess a 'jid' attribute specifying the exact XMPP address to be used as the subscribed JID -- often a bare JID &BAREJID; or full JID &FULLJID;.</p>
+      <p>When an XMPP entity wishes to subscribe to a node, it sends a subscription request to the pubsub service. The subscription request is an IQ-set where the &lt;pubsub/&gt; element contains one and only one &lt;subscribe/&gt; element. The &lt;subscribe/&gt; element SHOULD possess a 'node' attribute specifying the node to which the entity wishes to subscribe. The &lt;subscribe/&gt; element MUST also possess a 'jid' attribute specifying the exact XMPP address to be used as the subscribed JID -- often a bare JID &BAREJID; or full JID &FULLJID;.</p>
       <p>Here is an example of a subscription request.</p>
       <example caption='Entity subscribes to a node'><![CDATA[
 <iq type='set'