[lsd0001] branch master updated: resolution cleanup

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 2be9a4c  resolution cleanup
2be9a4c is described below

commit 2be9a4cfe49d292c2af812bcbb3032241f9e29c7
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Feb 20 10:22:16 2022 +0100

    resolution cleanup
---
 draft-schanzen-gns.xml | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 01360c9..125a6f3 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1980,13 +1980,13 @@ example.com = zTLD2 (ztype2||zk2)
            <xref target="blinding" />.</li>
            <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li>
            <li>Verify and process the RRBLOCK and decrypt the BDATA contained
-             in it as defined by its zone type (see also <xref 
target="records_block" />).</li>
+             in it as defined in <xref target="records_block" />.</li>
          </ol>
          <t>
            Upon receiving the RRBLOCK from the storage, as part of verifying 
the
            provided signature, the resolver MUST check that the SHA-512 hash 
of the
            derived authoritative zone key zk' from the RRBLOCK matches the 
query q
-           and that the overall block is not yet expired.
+           and that the block is not yet expired.
            If the signature does not match or the block is expired, the 
RRBLOCK MUST
            be ignored and, if applicable, the storage lookup GET(q) MUST 
continue to
            look for other RRBLOCKs.
@@ -1998,9 +1998,9 @@ example.com = zTLD2 (ztype2||zk2)
            Record processing occurs once a well-formed block has been 
decrypted.
            In record processing, only the valid records obtained are 
considered.
            To filter records by validity, the resolver
-           MUST at least check the expiration time and the FLAGS of the
-           respective record.  In particular, FLAGS may exclude shadow and
-           supplemental records from being considered.
+           MUST at least check the expiration time and the FLAGS field of the
+           respective record.  In particular, SHADOW and
+           SUPPLEMENTAL flags may exclude the record from being considered.
            If the resolver encounters a record with the CRITICAL flag set and
            does not support the record type the resolution MUST be aborted
            and an error MUST be returned. The information that the critical
@@ -2062,7 +2062,7 @@ example.com = zTLD2 (ztype2||zk2)
              This may in turn trigger a GNS name resolution process depending
              on the system configuration.
              In case resolution continues in DNS, the name MUST first be
-             converted to an IDNA complaint representation <xref 
target="RFC5890" />.
+             converted to an IDNA compliant representation <xref 
target="RFC5890" />.
            </t>
            <t>
              In order to prevent infinite loops, the resolver MUST

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.