commit e6ba6d1fa5161ec18642c03ce029a385d81d088f
parent e9e07b0449f9ad9ece320830ef546df52e05dbe8
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 28 Dec 2021 16:28:19 +0100
update
Diffstat:
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -284,6 +284,35 @@ PUT(key[, options], BLOCK)
<dd>Specified block type not supported by this implementation. FIXME: We may not need this for the spec.</dd>
</dl>
</section>
+ <section anchor="block_functions">
+ <name>Block Functions</name>
+ <t>
+ Any block type implementation MUST implement the following functions.
+ </t>
+ <dl>
+ <dt>Evaluate-BlockRequest</dt>
+ <dd>
+ is used to evaluate the request for a block. It is used as part of
+ GET message processing, where the block payload is still unkown,
+ but the block XQUERY (FIXME: Undefined here) and key can and should
+ be verified, if possible.
+ </dd>
+ <dt>Evaluate-BlockReply</dt>
+ <dd>
+ is used to evaluate a block including its key and payload.
+ It is used as part of PUT and RESULT message processing.
+ An implementation MAY also use evaluate locally stored blocks
+ (FIXME again?) before passing it to other peers or the Overlay.
+ </dd>
+ <dt>Get-BlockKey</dt>
+ <dd>
+ is used to synthesize the block key from the block payload
+ and metadata. It is used as part of PUT message processing.
+ (FIXME: The implementation currently does PUT block key validation
+ and then Block Evaluate-BlockReply ONLY for RegEx...)
+ </dd>
+ </dl>
+ </section>
<section>
<name>Block Types</name>
<t>
@@ -743,11 +772,6 @@ END
to PUTPATH. FIXME: Should should come way later (?)
</li>
<li>
- If the KEY of this PUT message is in the list of pending queries,
- return the message through the API. FIXME: Is this a conversion to
- a RESULT??
- </li>
- <li>
If the local peer is the closest peer (AM-CLOSEST-PEER) or the
"Demultiplex Everywhere" options flag ist set, the message MUST
be stored locally in the block storage.
@@ -1010,11 +1034,13 @@ END
GETPATH, the path MUST be truncated.
</li>
<li>
- FIXME: No validation??
- </li>
- <li>
- If the KEY of this PUT message is in the list of pending queries,
- return the message through the API.
+ If the KEY of this PUT message is found in the list of pending
+ queries, the the KEY and XQUERY is validated against the requested
+ BTYPE.
+ If the BTYPE is not supported, or if the block key
+ does not match the BTYPE or if the XQUERY is malformed,
+ the message MUST be discarded. (FIXME: It is not clear the key
+ validation is happening. However, block validation is.)
</li>
<li>
The implementation MAY cache RESULT messages.
