commit ba1936d7c92d579345f7ff25a05bcae48366a11a
parent a9ee5fcfbd0ba72b4834113e08649b057e6ed2f8
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Thu, 10 Mar 2022 08:11:02 +0100
-use flags consistently, instead of mixing options and flags
Diffstat:
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git 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.
