gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0001] branch master updated: improve English and structure


From: gnunet
Subject: [lsd0001] branch master updated: improve English and structure
Date: Fri, 30 Jun 2023 22:48:56 +0200

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

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 0b2d643  improve English and structure
0b2d643 is described below

commit 0b2d6432fe6ee9451b997720868ef79ab76cd007
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Fri Jun 30 22:48:51 2023 +0200

    improve English and structure
---
 draft-schanzen-gns.xml | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 0e40007..f9975b4 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1777,18 +1777,16 @@ GET(key) -> block
        ]]></artwork>
      <t>
        There is no mechanism to explicitly delete individual blocks from 
remote storage.
-       However, blocks in remote storage include an expiration time
-       and it is under the discretion of the storage implementation as to when 
to
-       actually delete an expired block.
-       The GNS implementation <bcp14>MUST NOT</bcp14> include expired resource
-       records in blocks. Any GNS resolver <bcp14>MUST</bcp14> disregard 
expired records returned from
-       remote storage.
+       However, blocks include an EXPIRATION field which guides remote
+       storage implementations to decide when to delete blocks.
      </t>
      <t>
        All resource records from the same zone sharing the same label are
        encrypted and published together in a single records block
        (RRBLOCK) in the remote storage under a key q as illustrated
        in <xref target="figure_storage_publish"/>.
+       A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource
+       records in blocks.
        The implementation <bcp14>MUST</bcp14> use the PUT storage procedure
        to update the zone contents accordingly.
      </t>
@@ -1888,7 +1886,7 @@ q := SHA-512 (ZKDF(zk, label))
          GNS records are grouped by their labels and published as a single
          block in the storage. The grouped record sets <bcp14>MAY</bcp14> be 
paired with any
          number of supplemental records. Supplemental records 
<bcp14>MUST</bcp14> have the
-         supplemental flag set (See <xref target="rrecords"/>).
+         supplemental flag set (see <xref target="rrecords"/>).
          The contained resource records are encrypted using a symmetric
          encryption scheme.
          A GNS implementation publishes RRBLOCKs
@@ -2221,8 +2219,10 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zk2)
            In record processing, only the valid records obtained are 
considered.
            To filter records by validity, the resolver
            <bcp14>MUST</bcp14> at least check the expiration time and the 
FLAGS field of the
-           respective record.  In particular, SHADOW and
-           SUPPLEMENTAL flags can exclude the record from being considered.
+           respective record.
+           Specifically, the resolver <bcp14>MUST</bcp14> disregard expired 
records.
+           Furthermore, SHADOW and
+           SUPPLEMENTAL flags can also exclude records from being considered.
            If the resolver encounters a record with the CRITICAL flag set and
            does not support the record type the resolution <bcp14>MUST</bcp14> 
be aborted
            and an error <bcp14>MUST</bcp14> be returned. The information that 
the critical

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]