[lsd0004] branch master updated: More wording on result message caches and processing.

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new 553fd21  More wording on result message caches and processing.
553fd21 is described below

commit 553fd21c5ca5cc437555580de2281698d348cfe9
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Dec 28 12:18:30 2022 +0900

    More wording on result message caches and processing.
---
 draft-schanzen-r5n.xml | 36 ++++++++++++++++++------------------
 1 file 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>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.