From f112606a8f311cb63c8037fa4e6d7c675c3f1485 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre <stpeter@jabber.org>
Date: Thu, 1 Mar 2007 18:24:24 +0000
Subject: [PATCH] clarification

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@635 4b5297f7-1745-476d-ba37-a9c6900126ab
---
 xep-0016.xml | 2 +-
 xep-0191.xml | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xep-0016.xml b/xep-0016.xml
index ccbd8c98..11376fbc 100644
--- a/xep-0016.xml
+++ b/xep-0016.xml
@@ -140,7 +140,7 @@
     <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 3921</cite>, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all.</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 client's resources to another, even if the user happens to define a rule that would otherwise result in that behavior (e.g., blocking communications from all entities not in the user's roster, since the user is not its own roster).</note></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>
     <p>The &lt;item/&gt; element MAY contain one or more child elements that enable an entity to specify more granular control over which kinds of stanzas are to be blocked (i.e., rather than blocking all stanzas).  The allowable child elements are:</p>
     <ul>
diff --git a/xep-0191.xml b/xep-0191.xml
index be3f160e..4d531306 100644
--- a/xep-0191.xml
+++ b/xep-0191.xml
@@ -90,7 +90,7 @@
 </section1>
 <section1 topic='Relationship to Privacy Lists' anchor='privacy'>
   <p>The simple communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (<cite>XEP-0016</cite>). If a service deploys both privacy lists and simple communications blocking, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with <cite>XEP-0016</cite>; if a particular aspect of functionality is not specified herein, the relevant text in <cite>XEP-0016</cite> shall be taken to apply.)</p>
-  <p>A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny". <note>An implementation MUST NOT block communications from one of a client's resources to another, even if the user happens to define a rule that would otherwise result in that behavior (e.g., blocking communications from all entities not in the user's roster, since the user is not its own roster).</note> If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. This mapping has the following implications:</p>
+  <p>A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "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> If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. This mapping has the following implications:</p>
   <ol start='1'>
     <li><p>If all of a user's clients always use simple communications blocking, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of "virtual list" (in the sense that it is never modified directly by any of the clients).</p></li>
     <li><p>If one of a user's clients uses privacy lists instead of blocklists and modifies the default privacy list by removing a blocked JID or blocking a new JID, then that change will be reflected in the blocklist.</p></li>