From 7a2d2f41261c4520f96b687bd1785215d2a2b456 Mon Sep 17 00:00:00 2001
From: Christian Schudt <christian.schudt@gmx.de>
Date: Wed, 24 Jun 2015 20:50:49 +0200
Subject: [PATCH] XEP-0163: Remove duplicate 'there' and fix dead link

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

diff --git a/xep-0163.xml b/xep-0163.xml
index 22dff2b4..07e59bba 100644
--- a/xep-0163.xml
+++ b/xep-0163.xml
@@ -509,8 +509,8 @@
     </ol>
     <p>If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of <cite>XEP-0060</cite>).</p>
   </section2>
-  <section2 topic='One Node Per Namespace' anchor='impl-onenode'>
-    <p>An earlier version of this document specified that there there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.</p>
+  <section2 topic='One Node Per Namespace' anchor='approach-onenode'>
+    <p>An earlier version of this document specified that there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.</p>
     <p>A specification that defines a given payload format for use in PEP MUST specify whether there shall be only one node per namespace, or whether multiple NodeIDs for the same namespace are allowable.</p>
   </section2>
 </section1>