commit 280ca4052700a6c6e5a1bd031dcc26f06994593b
parent 66f3d67fb079eca66530c2fa94ddffeb0a6fe442
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Thu, 10 Mar 2022 12:25:28 +0100
consistent english
Diffstat:
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -333,11 +333,11 @@ Connectivity | |Underlay| |Underlay|
<dl>
<dt><tt>QueryKey</tt>:</dt>
<dd>
- the 512-bit key to look for in the DHT.
+ is the 512-bit key to look for in the DHT.
</dd>
<dt>Block-Type:</dt>
<dd>
- the type of block to look for, possibly "any".
+ is the type of block to look for, possibly "any".
</dd>
</dl>
<t>
@@ -347,19 +347,19 @@ Connectivity | |Underlay| |Underlay|
<dl>
<dt>Replication-Level:</dt>
<dd>
- An integer which controls how many nearest peers the request
+ is an integer which controls how many nearest peers the request
should reach.
</dd>
<dt>Flags:</dt>
<dd>
- Flags that are used in order to indicate certain
+ is a 16-bit vector which indicates certain
processing requirements for messages.
Any combination of flags as defined in <xref target="route_flags"/>
may be specified.
</dd>
- <dt>eXtended-Query:</dt>
+ <dt>eXtended-Query (XQuery):</dt>
<dd>
- is extended query (XQuery) medatadata which may be
+ is medatadata which may be
required depending on the respective <tt>Block-Type</tt>.
A <tt>Block-Type</tt> must define if the <tt>XQuery</tt> can or must
be used and what the specific format of its contents should be.
@@ -371,7 +371,9 @@ Connectivity | |Underlay| |Underlay|
</dd>
<dt>Result-Filter:</dt>
<dd>
- allows applications to indicate results which are not relevant anymore to the
+ is a Bloom filter which allows applications to
+ probabilistically indicate results which are
+ not relevant anymore to the
caller (see <xref target="result_bloomfilter"/>).
</dd>
</dl>
@@ -384,20 +386,20 @@ Connectivity | |Underlay| |Underlay|
<dl>
<dt>Block-Type:</dt>
<dd>
- the type of block in the result.
+ is the desired type of block in the result.
</dd>
<dt>Block-Data:</dt>
<dd>
- the block payload. Contents are specific to the <tt>Block-Type</tt>.
+ is the application-specific block payload. Contents are specific to the <tt>Block-Type</tt>.
</dd>
<dt>Block-Expiration:</dt>
<dd>
- the expiration time of the block. After this time, the result should no
+ is the expiration time of the block. After this time, the result should no
longer be used.
</dd>
<dt>Key:</dt>
<dd>
- the key under which the block was stored. This may be different from the
+ is the key under which the block was stored. This may be different from the
key that was queried if the flag FindApproximate was set.
</dd>
<dt>GET-Path:</dt>
@@ -433,13 +435,13 @@ Connectivity | |Underlay| |Underlay|
</t>
<dl>
<dt>Key:</dt>
- <dd>the key under which to store the block.</dd>
+ <dd>is the key under which to store the block.</dd>
<dt>Block-Type:</dt>
- <dd>the type of the block to store.</dd>
+ <dd>is the type of the block to store.</dd>
<dt>Block-Expiration:</dt>
- <dd>when should the block expire.</dd>
+ <dd>specifies when the block should expire.</dd>
<dt>Block-Data:</dt>
- <dd>the block to store.</dd>
+ <dd>is the application-specific payload of the block to store.</dd>
</dl>
<t>
The PUT procedure may allow a set of optional parameters in order to
@@ -448,12 +450,12 @@ Connectivity | |Underlay| |Underlay|
<dl>
<dt>Replication-Level:</dt>
<dd>
- An integer which controls how many nearest peers the request
+ is an integer which controls how many nearest peers the request
should reach.
</dd>
<dt>Flags:</dt>
<dd>
- Flags are used in order to indicate certain
+ is a bit-vector which indicates certain
processing requirements for messages.
Any combination of flags as defined in <xref target="route_flags"/>
may be specified.
@@ -809,8 +811,7 @@ Connectivity | |Underlay| |Underlay|
<section anchor="route_flags">
<name>Flags</name>
<t>
- The <tt>Flags</tt> consist of the following flags which
- are represented in a flags field in the messages.
+ is a 16-bit vector representing binary options.
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