update

1 files changed, 110 insertions, 90 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index b346566..5218e94 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -258,96 +258,6 @@ PUT(key[, options], BLOCK)
        </t>
      </section>
    </section>
-   <section anchor="blockstorage" numbered="true" toc="default">
-     <name>Block Storage</name>
-     <section>
-       <name>Block Processing</name>
-       <dl>
-         <dt>OK_MORE</dt>
-         <dd>Valid result, and there may be more.</dd>
-         <dt>OK_LAST</dt>
-         <dd>Last possible valid result.</dd>
-         <dt>OK_DUPLICATE</dt>
-         <dd>Valid result, but duplicate.</dd>
-         <dt>RESULT_INVALID</dt>
-         <dd>Invalid result. Block does not match query. Value = 4.</dd>
-         <dt>RESULT_IRRELEVANT</dt>
-         <dd>Block does not match xquery. Valid result, but not relevant for the request.</dd>
-         <dt>REQUEST_VALID</dt>
-         <dd>Query is valid, no reply given.</dd>
-         <dt>REQUEST_INVALID</dt>
-         <dd>
-           Query format does not match block type. For example, xquery not
-           given or xquery_size not appropriate for type.
-         </dd>
-         <dt>TYPE_NOT_SUPPORTED</dt>
-         <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>
-         Applications can and should define their own block types.
-         The block type determines the format and handling of the block
-         payload by peers in PUT and RESULT messages.
-         Block types MUST be registered with GANA <xref target="gana"/>.
-       </t>
-       <t>
-         For bootstrapping and peer discovery, the DHT implementation uses
-         its own block type called "HELLO". A block with this block type
-         contains the peer ID of the peer initiating the GET request.
-       </t>
-       <section>
-         <name>HELLO</name>
-         <t>
-           The HELLO block type wire format is illustrated in
-           <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT
-           include extended query data (xquery). Any implementation
-           encountering a HELLO block with xquery data MUST consider the
-           block invalid and ignore it.
-         </t>
-         <t>
-           A HELLO reply block MAY be empty. Otherwise, it contains the
-           HELLO URI of a peer.
-         </t>
-         <figure anchor="figure_hellobt">
-           <artwork name="" type="" align="left" alt=""><![CDATA[
-         FIXME: Wire format
-         ]]></artwork>
-         </figure>
-       </section>
-     </section>
-   </section>
-
    <section anchor="underlay" numbered="true" toc="default">
      <name>Underlay</name>
      <t>
@@ -1063,6 +973,116 @@ END
        </section>
      </section>
    </section>
+   <section anchor="blockstorage" numbered="true" toc="default">
+     <name>Block Storage</name>
+     <section>
+       <name>Block Processing</name>
+       <t>RequestEvaluationResult</t>
+       <dl>
+         <dt>REQUEST_VALID</dt>
+         <dd>Query is valid, no reply given.</dd>
+         <dt>REQUEST_INVALID</dt>
+         <dd>
+           Query format does not match block type. For example, XQuery not
+           given or of size of XQuery is not appropriate for type.
+         </dd>
+       </dl>
+       <t>ReplyEvaluationResult</t>
+       <dl>
+         <dt>OK_MORE</dt>
+         <dd>Valid result, and there may be more.</dd>
+         <dt>OK_LAST</dt>
+         <dd>Last possible valid result.</dd>
+         <dt>OK_DUPLICATE</dt>
+         <dd>Valid result, but duplicate.</dd>
+         <dt>RESULT_INVALID</dt>
+         <dd>Invalid result. Block does not match query. Value = 4.</dd>
+         <dt>RESULT_IRRELEVANT</dt>
+         <dd>Block does not match xquery. Valid result, but not relevant for the request.</dd>
+       </dl>
+     </section>
+     <section anchor="block_functions">
+       <name>Block Functions</name>
+       <t>
+         Any block type implementation MUST implement the following functions.
+       </t>
+       <dl>
+         <dt>ValidateBlockQuery(Key, XQuery) -> QueryEvaluationResult</dt>
+         <dd>
+           is used to evaluate the request for a block. It is used as part of
+           <tt>GetMessage</tt> processing, where the block payload is still unkown,
+           but the block <tt>XQuery</tt> (FIXME: Undefined here) and <tt>Key</tt> can and
+           MUST be verified, if possible.
+         </dd>
+         <dt>ValidateBlockStoreRequest(PutMessage, Key) -> StoreRequestEvaluationResult</dt>
+         <dd>
+           is used to evaluate a block including its key and payload.
+           It is used as part of <tt>PutMessage</tt> processing.
+           The validation MUST include a check of the block payload against the
+           <tt>Key</tt> under which it is requested to be stored.
+         </dd>
+         <dt>ValidateBlockReply(ResultMessage, XQuery, Key) -> ReplyEvaluationResult</dt>
+         <dd>
+           is used to evaluate a block including its <tt>Key</tt> and payload.
+           It is used as part <tt>ResultMessage</tt> processing.
+           The validation of a <tt>ResultMessage</tt> requires a pending local query
+           or a previously routed request of another peer and its associated
+           XQuery data and Key.
+           The validation MUST include a check of the block payload against the
+           key under which it is requested to be stored.
+         </dd>
+         <dt>DeriveBlockKey(Block) -> Key</dt>
+         <dd>
+           is used to synthesize the block key from the block payload
+           and metadata. It is used as part of FIND-PEER message processing.
+         </dd>
+         <dt>FilterResult(Block, XQuery, Key) -> ReplyEvaluationResult</dt>
+         <dd>
+           is used to filter results stored in the local block storage for local
+           queries. Locally stored blocks from previously observed
+           <tt>ResultMessages</tt> and <tt>PutMessages</tt> MAY use this
+           function instead of <tt>ValidateBlockReply</tt> in order to
+           avoid revalidation of the block and only perform filtering based on
+           request parameters.
+         </dd>
+       </dl>
+     </section>
+     <section>
+       <name>Block Types</name>
+       <t>
+         Applications can and should define their own block types.
+         The block type determines the format and handling of the block
+         payload by peers in PUT and RESULT messages.
+         Block types MUST be registered with GANA <xref target="gana"/>.
+       </t>
+       <t>
+         For bootstrapping and peer discovery, the DHT implementation uses
+         its own block type called "HELLO". A block with this block type
+         contains the peer ID of the peer initiating the GET request.
+       </t>
+       <section>
+         <name>HELLO</name>
+         <t>
+           The HELLO block type wire format is illustrated in
+           <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT
+           include extended query data (xquery). Any implementation
+           encountering a HELLO block with xquery data MUST consider the
+           block invalid and ignore it.
+         </t>
+         <t>
+           A HELLO reply block MAY be empty. Otherwise, it contains the
+           HELLO URI of a peer.
+         </t>
+         <figure anchor="figure_hellobt">
+           <artwork name="" type="" align="left" alt=""><![CDATA[
+         FIXME: Wire format
+         ]]></artwork>
+         </figure>
+       </section>
+     </section>
+   </section>
+
+
    <section>
      <name>Bootstrapping</name>
      <t>