[lsd0004] branch master updated: -use flags consistently, instead of mixing options and flags

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new ba1936d  -use flags consistently, instead of mixing options and flags
ba1936d is described below

commit ba1936d7c92d579345f7ff25a05bcae48366a11a
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Thu Mar 10 08:11:02 2022 +0100

    -use flags consistently, instead of mixing options and flags
---
 draft-schanzen-r5n.xml | 52 +++++++++++++++++++++++++-------------------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 91d7a9a..542d019 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -333,7 +333,7 @@ Connectivity | |Underlay|  |Underlay|
         <dl>
           <dt><tt>QueryKey</tt>:</dt>
           <dd>
-            the key to look for in the DHT.
+            the 512-bit key to look for in the DHT.
           </dd>
         </dl>
         <t>
@@ -343,18 +343,18 @@ Connectivity | |Underlay|  |Underlay|
         <dl>
           <dt>Block-Type:</dt>
           <dd>
-            the type of block to look for.
+            the type of block to look for, possibly "any".
           </dd>
           <dt>Replication-Level:</dt>
           <dd>
             An integer which controls how many nearest peers the request
             should reach.
           </dd>
-          <dt>Route-Options:</dt>
+          <dt>Route-Flags:</dt>
           <dd>
             Flags that are used in order to indicate certain
             processing requirements for messages.
-            Any combination of options as defined in <xref 
target="route_options"/>
+            Any combination of flags as defined in <xref target="route_flags"/>
             may be specified.
           </dd>
           <dt>eXtended-Query:</dt>
@@ -440,11 +440,11 @@ Connectivity | |Underlay|  |Underlay|
             An integer which controls how many nearest peers the request
             should reach.
           </dd>
-          <dt>Route-Options:</dt>
+          <dt>Route-flags:</dt>
           <dd>
             Flags that are used in order to indicate certain
             processing requirements for messages.
-            Any combination of options as defined in <xref 
target="route_options"/>
+            Any combination of flags as defined in <xref target="route_flags"/>
             may be specified.
           </dd>
           <dt>Block-Expiration</dt>
@@ -679,7 +679,7 @@ Connectivity | |Underlay|  |Underlay|
           <!-- FIXME: CG: I think this last one is not implemented! -->
           <!-- FIXME: CG: I also suspect we need to review how the block API 
filters HELLOs, to NOT use the full body / expiration time in the hash -->
           These requests <bcp14>MUST</bcp14> use the FindApproximate and 
DemultiplexEverywhere
-          options. FindApproximate will ensure that other peers will reply
+          flags. FindApproximate will ensure that other peers will reply
           with keys they merely consider close-enough, while 
DemultiplexEverywhere
           will cause each peer on the path to respond, which is likely to yield
           HELLOs of peers that are useful somewhere in the routing table.
@@ -799,11 +799,11 @@ Connectivity | |Underlay|  |Underlay|
         processing are detailed.
         The local peer address is referred to as <tt>N</tt>.
       </t>
-      <section anchor="route_options">
-        <name>Route Options</name>
+      <section anchor="route_flags">
+        <name>Route Flags</name>
         <t>
-          The <tt>RouteOptions</tt> consist of the following flags which
-          are represented in an options field in the messages.
+          The <tt>RouteFlags</tt> consist of the following flags which
+          are represented in a flags field in the messages.
           Each flag is represented by a bit in the field starting from 0 as
           the rightmost bit to 15 as the leftmost bit.
           <!--FIXME: Actually, we set those bits and then store the resulting
@@ -1071,7 +1071,7 @@ Connectivity | |Underlay|  |Underlay|
 +-----+-----+-----+-----+-----+-----+-----+-----+
 |  MSIZE    |   MTYPE   |         BTYPE         |
 +-----+-----+-----+-----+-----+-----+-----+-----+
-|  OPTIONS  | HOPCOUNT  | REPL_LVL  | PATH_LEN  |
+|   FLAGS   | HOPCOUNT  | REPL_LVL  | PATH_LEN  |
 +-----+-----+-----+-----+-----+-----+-----+-----+
 |                    EXPIRATION                 |
 +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1104,9 +1104,9 @@ Connectivity | |Underlay|  |Underlay|
               is a 32-bit block type field. The block type indicates the 
content
               type of the payload. In network byte order.
             </dd>
-            <dt>OPTIONS</dt>
+            <dt>FLAGS</dt>
             <dd>
-              is a 16-bit options field (see below).
+              is a 16-bit flags field (see below).
             </dd>
             <dt>HOPCOUNT</dt>
             <dd>
@@ -1181,14 +1181,14 @@ Connectivity | |Underlay|  |Underlay|
               If not, the implementation <bcp14>MAY</bcp14> log an error, but 
<bcp14>MUST</bcp14> continue.
             </li>
             <li>
-              If the <tt>RecordRoute</tt> flag is set in OPTIONS,
+              If the <tt>RecordRoute</tt> flag is set in FLAGS,
               the local peer address <bcp14>MUST</bcp14> be appended to the 
<tt>PUTPATH</tt>
               of the message.
             </li>
             <li>
               If the local peer is the closest peer
               (cf. <tt>IsClosestpeer(N, BLOCK_KEY)</tt>) or the 
<tt>DemultiplexEverywhere</tt>
-              options flag ist set, the message <bcp14>MUST</bcp14>
+              flag ist set, the message <bcp14>MUST</bcp14>
               be stored locally in the block storage.
             </li>
             <li>
@@ -1216,7 +1216,7 @@ Connectivity | |Underlay|  |Underlay|
 +-----+-----+-----+-----+-----+-----+-----+-----+
 |  MSIZE    |   MTYPE   |         BTYPE         |
 +-----+-----+-----+-----+-----+-----+-----+-----+
-|  OPTIONS  |  HOPCOUNT | REPL_LVL  |  XQ_SIZE  |
+|   FLAGS   |  HOPCOUNT | REPL_LVL  |  XQ_SIZE  |
 +-----+-----+-----+-----+-----+-----+-----+-----+
 |                 PEER_BF                       /
 /                 (128 byte)                    |
@@ -1248,9 +1248,9 @@ Connectivity | |Underlay|  |Underlay|
               is a 32-bit block type field. The block type indicates the 
content
               type of the payload. In network byte order.
             </dd>
-            <dt>OPTIONS</dt>
+            <dt>FLAGS</dt>
             <dd>
-              is a 16-bit options field (see below).
+              is a 16-bit flags field (see below).
             </dd>
             <dt>HOPCOUNT</dt>
             <dd>
@@ -1321,7 +1321,7 @@ Connectivity | |Underlay|  |Underlay|
               <t>
                 If the local peer is the closest peer
                 (cf. <tt>IsClosestpeer (N, QueryHash)</tt>) or the
-                <tt>DemultiplexEverywhere</tt> options flag is set, a reply
+                <tt>DemultiplexEverywhere</tt> flag is set, a reply
                 <bcp14>MUST</bcp14> be produced (if one is available) using 
the following
                 steps:
               </t>
@@ -1330,12 +1330,12 @@ Connectivity | |Underlay|  |Underlay|
                   If <tt>TYPE</tt> indicates a request for a HELLO block,
                   the peer <bcp14>MUST</bcp14> consult the HELLOs it has 
cached for the
                   peers in its routing table instead of the local block
-                  storage (while continuing to respect options like
+                  storage (while continuing to respect flags like
                   <tt>DemultiplexEverywhere</tt>
                   and <tt>FindApproximate</tt>).
                 </li>
                 <li>
-                  If <tt>OPTIONS</tt> indicate a <tt>FindApproximate</tt> 
request,
+                  If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> 
request,
                   the peer should respond with the closest block it
                   has that is not filtered by the
                   <tt>RESULT_BF</tt>.
@@ -1383,7 +1383,7 @@ Connectivity | |Underlay|  |Underlay|
 +-----+-----+-----+-----+-----+-----+-----+-----+
 |  MSIZE    |   MTYPE   |        BTYPE          |
 +-----+-----+-----+-----+-----+-----+-----+-----+
-|   //      | OPTIONS   | PUTPATH_L | GETPATH_L |
+|   //      |   FLAGS   | PUTPATH_L | GETPATH_L |
 +-----+-----+-----+-----+-----+-----+-----+-----+
 |                   EXPIRATION                  |
 +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1413,9 +1413,9 @@ Connectivity | |Underlay|  |Underlay|
               types but for put messages it must be set to
               the value 148 in network byte order.
             </dd>
-            <dt>OPTIONS</dt>
+            <dt>FLAGS</dt>
             <dd>
-              is a 16-bit options field (see below).
+              is a 16-bit flags field (see below).
             </dd>
             <dt>BTYPE</dt>
             <dd>
@@ -1511,7 +1511,7 @@ Connectivity | |Underlay|  |Underlay|
                 <!-- FIXME-CG: check that it can be! Check implementation! -->
               </t>
               <t>
-                If the request options include <tt>FindApproximate</tt> and 
the result
+                If the request FLAGS include <tt>FindApproximate</tt> and the 
result
                 message block type is HELLO the block validation must use the
                 key derived using <tt>DeriveBlockKey</tt> as the key included 
in
                 the request is only approximate.

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