More wording on result message caches and processing.

1 files changed, 18 insertions, 18 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 54212c4..e7a11a8 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1682,14 +1682,13 @@ BEGIN
           </t>
           <ol>
             <li>
-              The <tt>QUERY_HASH</tt> and <tt>XQUERY</tt> fields are validated
-              against the requested <tt>BTYPE</tt> as defined by its respective
-              <tt>ValidateBlockQuery</tt> procedure.
-              If validation
-              function yields <tt>REQUEST_INVALID</tt>, the message <bcp14>MUST</bcp14> be discarded.
+              If the <tt>BTYPE</tt> is supported, the <tt>QUERY_HASH</tt> and <tt>XQUERY</tt> fields are validated
+              as defined by the respective <tt>ValidateBlockQuery</tt> procedure for this type.
+              If the result yields <tt>REQUEST_INVALID</tt>, the message <bcp14>MUST</bcp14> be discarded and
+              processing ends.
               If the <tt>BTYPE</tt> is not supported, the message <bcp14>MUST</bcp14>
               be forwarded (Skip to step 4).
-              If the <tt>BTYPE</tt> is <tt>ANY</tt>, the message is processed
+              If the <tt>BTYPE</tt> is <tt>ANY</tt>, the message is processed further
               without validation.
             </li>
             <li>
@@ -1699,12 +1698,12 @@ BEGIN
             </li>
             <li>
               <t>
-                The local peer <bcp14>MUST</bcp14> try to produce a reply in any of the following cases:
+                The local peer <bcp14>SHOULD</bcp14> try to produce a reply in any of the following cases:
                 (1) If the local peer is the closest peer
                 (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>, or (2)
                 if the <tt>DemultiplexEverywhere</tt> flag is set, or (3)
-                if the local peer is not the closest and a similar <tt>GetRequest</tt> was answered previously
-                with a cached result message this request also matches (<xref target="p2p_result_processing"/>). 
+                if the local peer is not the closest and a previously
+                cached <tt>ResultMessage</tt> also matches this request (<xref target="p2p_result_processing"/>).
               </t>
               <t>
                 The reply is produced (if one is available) using the following
@@ -1712,31 +1711,32 @@ BEGIN
               </t>
               <ol type="%c)">
                 <li>
-                  If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
+                  If the <tt>BTYPE</tt> is <tt>HELLO</tt>, the implementation <bcp14>MUST</bcp14> only consider
+                  synthesizing its own addresses and the addresses it has cached for the peers in its routing table
+                  as <tt>HELLO</tt> block replies.
+                  Otherwise, if the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
                   <tt>ANY</tt>,
                   the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage
                   and previously cached <tt>ResultMessage</tt>s.
-                  Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own addresses and
-                  the addresses it has cached for the peers in its routing table.
                 </li>
                 <li>
-                  If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request,
-                  the peer <bcp14>SHOULD</bcp14> try to respond with the closest block (smallest value
+                  If the <tt>FLAGS</tt> field includes the flag <tt>FindApproximate</tt>,
+                  the peer <bcp14>SHOULD</bcp14> respond with the closest block (smallest value
                   of <tt>GetDistance(QUERY_HASH, BLOCK_KEY)</tt>) it
                   can find that is not filtered by the <tt>RESULT_BF</tt>.
-                  Otherwise, the peer <bcp14>MUST</bcp14> respond if it has a valid block
+                  Otherwise, the peer <bcp14>MUST</bcp14> respond with the block  
                   with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is
                   not filtered by the <tt>RESULT_BF</tt>.
                 </li>
                 <li>
-                  Any resulting (synthesized) block <bcp14>MUST</bcp14> be encapsulated in a
+                  Any resulting (synthesized) block is encapsulated in a
                   <tt>ResultMessage</tt>.
-                  The cached or created <tt>ResultMessage</tt> <bcp14>SHOULD</bcp14> be transmitted to the
+                  The <tt>ResultMessage</tt> <bcp14>SHOULD</bcp14> be transmitted to the
                   neighbor from which the request was received.
                 </li>
               </ol>
               <t>
-                Implementations <bcp14>MAY</bcp14> not to reply if they are resource-constrained.
+                Implementations <bcp14>MAY</bcp14> not reply if they are resource-constrained.
                 However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
                 highest priority among competing transmissions.
               </t>