commit 5a91d9457f0a1d465185ba381e6a26936b4c69ff
parent 708869b9de9e1f1512a0cf28974cf6a415039dd8
Author: Christian Grothoff <christian@grothoff.org>
Date: Sat, 13 Jul 2024 10:00:56 +0200
more English fixes
Diffstat:
1 file changed, 107 insertions(+), 78 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1454,9 +1454,9 @@ BEGIN
</dd>
<dt>EXPIRATION</dt>
<dd>
- denotes the absolute 64-bit expiration date of the block.
- In microseconds since midnight (0 hour), January 1, 1970 UTC in
- network byte order.
+ denotes the absolute 64-bit expiration date of the block
+ in microseconds since midnight (0 hour), January 1, 1970
+ UTC in network byte order.
</dd>
<dt>BLOCK HASH</dt>
<dd>
@@ -1767,89 +1767,119 @@ BEGIN
If the message is expired, it <bcp14>MUST</bcp14> be discarded.
</li>
<li>
- If the <tt>BTYPE</tt> is not supported by the implementation,
- no validation of the block payload is performed and processing
- continues at (5).
- If the <tt>BTYPE</tt> is <tt>ANY</tt>, then the message <bcp14>MUST</bcp14> be discarded.
- Else, the block <bcp14>MUST</bcp14> be validated as defined in (3) and (4).
+ If the <tt>BTYPE</tt> is <tt>ANY</tt>, then the message
+ <bcp14>MUST</bcp14> be discarded. If the <tt>BTYPE</tt>
+ is not supported by the implementation, no validation of
+ the block payload is performed and processing continues
+ at (5). Else, the block <bcp14>MUST</bcp14> be
+ validated as defined in (3) and (4).
</li>
<li>
- The message is evaluated using the block validation functions matching
- the <tt>BTYPE</tt>. First, the client attempts to
- derive the key using the respective <tt>DeriveBlockKey</tt> procedure
- as described in <xref target="block_functions"/>. If a key can be
- derived and does not match, the message <bcp14>MUST</bcp14> be discarded.
+ The message is evaluated using the block validation
+ functions matching the <tt>BTYPE</tt>. First, the client
+ attempts to derive the key using the respective
+ <tt>DeriveBlockKey</tt> procedure as described in <xref
+ target="block_functions"/>. If a key can be derived and
+ does not match, the message <bcp14>MUST</bcp14> be
+ discarded.
</li>
<li>
- Next, the <tt>ValidateBlockStoreRequest</tt> procedure for the <tt>BTYPE</tt>
- as described in <xref target="block_functions"/> is used to
- validate the block payload. If the block payload
- is invalid, the message <bcp14>MUST</bcp14> be discarded.
+ Next, the <tt>ValidateBlockStoreRequest</tt> procedure
+ for the <tt>BTYPE</tt> as described in <xref
+ target="block_functions"/> is used to validate the block
+ payload. If the block payload is invalid, the message
+ <bcp14>MUST</bcp14> be discarded.
</li>
<li>
- The peer identity of the sender peer <tt>P</tt> <bcp14>SHOULD</bcp14> be in <tt>PEER_BF</tt>.
- If not, the implementation <bcp14>MAY</bcp14> log an error, but <bcp14>MUST</bcp14> continue.
+ The peer identity of the sender peer <tt>P</tt>
+ <bcp14>SHOULD</bcp14> be in <tt>PEER_BF</tt>. If not,
+ the implementation <bcp14>MAY</bcp14> log an error, but
+ <bcp14>MUST</bcp14> continue.
</li>
<li>
- If the <tt>RecordRoute</tt> flag is not set, the <tt>PATH_LEN</tt>
- <bcp14>MUST</bcp14> be set to zero.
+ If the <tt>RecordRoute</tt> flag is not set, the
+ <tt>PATH_LEN</tt> <bcp14>MUST</bcp14> be set to zero.
If the flag is set and <tt>PATH_LEN</tt> is non-zero,
- the local peer <bcp14>SHOULD</bcp14> verify the signatures from the <tt>PUTPATH</tt>.
- Verification <bcp14>MAY</bcp14> involve checking all signatures or any random
- subset of the signatures.
- It is <bcp14>RECOMMENDED</bcp14> that peers adapt
- their behavior to available computational resources so as to not make signature
- verification a bottleneck. If an invalid signature is found, the
- <tt>PUTPATH</tt> <bcp14>MUST</bcp14> be truncated to only include the elements
- following the invalid signature.
+ the local peer <bcp14>SHOULD</bcp14> verify the
+ signatures from the <tt>PUTPATH</tt>. Verification
+ <bcp14>MAY</bcp14> involve checking all signatures or
+ any random subset of the signatures. It is
+ <bcp14>RECOMMENDED</bcp14> that peers adapt their
+ behavior to available computational resources so as to
+ not make signature verification a bottleneck. If an
+ invalid signature is found, the <tt>PUTPATH</tt>
+ <bcp14>MUST</bcp14> be truncated to only include the
+ elements following the invalid signature.
</li>
<li>
If the local peer is the closest peer
- (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt>
- flag ist set, the message <bcp14>SHOULD</bcp14>
- be stored locally in the block storage if possible.
- The implementation <tt>MAY</tt> choose not store the block if external factors or configurations
- prevent this, such as limited (alottted) disk space.
+ (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY,
+ PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt>
+ flag ist set, the message <bcp14>SHOULD</bcp14> be
+ stored locally in the block storage if possible. The
+ implementation <tt>MAY</tt> choose not store the block
+ if external factors or configurations prevent this, such
+ as limited (allotted) disk space.
</li>
<li>
- If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
- peer <bcp14>MUST</bcp14> be considered for the local routing
- table by using the peer identity in <tt>BLOCK_KEY</tt>.
- If the peer is not either already connected or the respective k-bucket is
- not already full the peer <bcp14>MUST</bcp14> try to establish a
- connection to the peer indicated in the <tt>HELLO</tt> block using
- the address information
- from the <tt>HELLO</tt> block and the underlay's <tt>TRY_CONNECT()</tt> function.
- The implementation <bcp14>MUST</bcp14> instruct the underlay to try to connect to all
- provided addresses using <tt>TRY_CONNECT()</tt> in order to make the underlay aware of
- multiple addresses for this connection.
- When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
- the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>).
+ If the <tt>BTYPE</tt> of the message indicates a
+ <tt>HELLO</tt> block, the peer <bcp14>MUST</bcp14> be
+ considered for the local routing table by using the peer
+ identity in <tt>BLOCK_KEY</tt>. If neither the peer is
+ already connected nor the respective k-bucket is already
+ full, then the peer <bcp14>MUST</bcp14> try to establish
+ a connection to the peer indicated in the <tt>HELLO</tt>
+ block using the address information from the
+ <tt>HELLO</tt> block and the underlay's
+ <tt>TRY_CONNECT()</tt> function. The implementation
+ <bcp14>MUST</bcp14> instruct the underlay to try to
+ connect to all provided addresses using
+ <tt>TRY_CONNECT()</tt> in order to make the underlay
+ aware of multiple addresses for this connection. When a
+ connection can be established, the underlay's
+ <tt>PEER_CONNECTED</tt> signal will cause the peer to be
+ added to the respective k-bucket of the routing table
+ (<xref target="routing"/>).
</li>
<li>
- Given the value in <tt>REPL_LVL</tt>, <tt>HOPCOUNT</tt> and
- <tt>FALSE = IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt> the number of peers to
- forward to <bcp14>MUST</bcp14> be calculated
- using <tt>ComputeOutDegree()</tt>.
- The implementation <bcp14>SHOULD</bcp14> select up to this
- number of peers to forward the message to using the function <tt>SelectPeer()</tt> (<xref target="routing_functions"/>)
- using the <tt>BLOCK_KEY</tt>, <tt>HOPCOUNT</tt>, and utilizing <tt>PEER_BF</tt> as Bloom filter.
- For each selected peer <tt>PEER_BF</tt> is updated with that peer
- in between calls to <tt>SelectPeer()</tt>.
- The implementation <bcp14>MAY</bcp14>
- forward to fewer or no peers in order to handle resource constraints
- such as limited bandwidth or simply if there are not suitable
- peers.
- For each selected peer with peer identity <tt>P</tt> a dedicated <tt>PutMessage_P</tt>
- is created containing the original (and where applicable already updated) fields
- of the received <tt>PutMessage</tt>.
- In each message the all selected peer identities and the local peer identity <bcp14>MUST</bcp14> be added to the
- <tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt> is incremented by 1.
- If the <tt>RecordRoute</tt> flag is set, a new path element is created using the
- predecessor peer public key and the signature of the current peer.
- The path element is added to the <tt>PUTPATH</tt> fields and the <tt>PATH_LEN</tt> field is incremented by 1.
- When creating the path element signature, the successor must be set to the recipient peer <tt>P</tt> of the <tt>PutMessageP</tt>.
- The successor in the new path element is the recipient peer <tt>P</tt> of Finally, the messages are sent using <tt>SEND(P, PutMessageP)</tt> each recipient.
+ Given the value in <tt>REPL_LVL</tt>, <tt>HOPCOUNT</tt>
+ and <tt>FALSE = IsClosestPeer(SELF, BLOCK_KEY,
+ PeerFilter)</tt> the number of peers to forward to
+ <bcp14>MUST</bcp14> be calculated using
+ <tt>ComputeOutDegree()</tt>. The implementation
+ <bcp14>SHOULD</bcp14> select up to this number of peers
+ to forward the message to using the function
+ <tt>SelectPeer()</tt> (<xref
+ target="routing_functions"/>) using the
+ <tt>BLOCK_KEY</tt>, <tt>HOPCOUNT</tt>, and utilizing
+ <tt>PEER_BF</tt> as peer Bloom filter. For each
+ selected peer <tt>PEER_BF</tt> is updated with that peer
+ in between calls to <tt>SelectPeer()</tt>. The
+ implementation <bcp14>MAY</bcp14> forward to fewer or no
+ peers in order to handle resource constraints such as
+ limited bandwidth or simply because there are not enough
+ suitable connected peers. For each selected peer with
+ peer identity <tt>P</tt> a dedicated
+ <tt>PutMessage_P</tt> is created containing the original
+ (and where applicable already updated) fields of the
+ received <tt>PutMessage</tt>. In each message
+ <em>all</em> selected peer identities and the local peer
+ identity <bcp14>MUST</bcp14> be added to the
+ <tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt>
+ <bcp14>MUST</bcp14> be incremented by 1. If the
+ <tt>RecordRoute</tt> flag is set, a new path element is
+ created using the predecessor peer public key and the
+ signature of the current peer. The path element is
+ added to the <tt>PUTPATH</tt> fields and the
+ <tt>PATH_LEN</tt> field is incremented by 1. When
+ creating the path element signature, the successor must
+ be set to the recipient peer <tt>P</tt> of the
+ <tt>PutMessage_P</tt>. The successor in the new path
+ element is the recipient peer <tt>P</tt>. If the path
+ becomes too long for the resulting message to be
+ transmitted by the underlay, it <bcp14>MUST</bcp14> be
+ truncated. Finally, the messages are sent using
+ <tt>SEND(P, PutMessage_P)</tt> to each recipient.
</li>
</ol>
</section>
@@ -1900,8 +1930,8 @@ BEGIN
</dd>
<dt>BTYPE</dt>
<dd>
- is a 32-bit block type field. The block type indicates the content
- type of the payload. Set by the initiator. Read-only. In network byte order.
+ is a 32-bit block type field in network byte order. The block type indicates the content
+ type of the payload. Set by the initiator. Read-only.
</dd>
<dt>VER</dt>
<dd>
@@ -2187,8 +2217,7 @@ BEGIN
</dd>
<dt>EXPIRATION</dt>
<dd>
- denotes the absolute 64-bit expiration date of the content.
- In microseconds since midnight (0 hour), January 1, 1970 in network
+ denotes the absolute 64-bit expiration date of the content in microseconds since midnight (0 hour), January 1, 1970 in network
byte order.
Set by the initiator to the expiration value as recorded from
the <tt>PutMessage</tt> from which the block originated.
@@ -2584,9 +2613,9 @@ BEGIN
</dd>
<dt>EXPIRATION</dt>
<dd>
- denotes the absolute 64-bit expiration date of the HELLO.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.
+ denotes the absolute 64-bit expiration date of the HELLO
+ in microseconds since midnight (0 hour), January 1, 1970
+ in network byte order.
</dd>
<dt>H_ADDRS</dt>
<dd>
@@ -3149,7 +3178,7 @@ Type | Name | References | Description
</figure>
<t>
When adding an element to the Bloom filter <tt>bf</tt> using
- <tt>BF-SET(bf,e)</tt>, each integer <tt>n</tt> of the mapping
+ <tt>BF-SET(bf, e)</tt>, each integer <tt>n</tt> of the mapping
<tt>M(e)</tt> is interpreted as a bit offset <tt>n mod L</tt> within
<tt>bf</tt> and set to 1.
</t>
