[lsd0001] branch master updated: use 'block' consisently, and not sometimes 'value'

[gnunet]

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 36a5678  use 'block' consisently, and not sometimes 'value'
36a5678 is described below

commit 36a567839e0609e432392676dd99d8c5342fdce0
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Fri Jun 30 22:29:41 2023 +0200

    use 'block' consisently, and not sometimes 'value'
---
 draft-schanzen-gns.xml | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 980c601..b8d97d7 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1763,31 +1763,31 @@ S-Decrypt(zk,label,expiration,ciphertext):
    <section anchor="publish" numbered="true" toc="default">
      <name>Record Encoding for Remote Storage</name>
      <t>
-       Any API which allows storing a value under a 512-bit key and retrieving
-       one or more values from the key can be used by an implementation for 
record storage.
-       To be useful, the API <bcp14>MUST</bcp14> permit storing at least 176 
byte values
+       Any API which allows storing a block under a 512-bit key and retrieving
+       one or more blocks from a key can be used by an implementation for 
remote storage.
+       To be useful, the API <bcp14>MUST</bcp14> permit storing at least 176 
byte blocks
        to be able to support the defined zone delegation record encodings,
-       and <bcp14>SHOULD</bcp14> allow at least 1024 byte values.
+       and <bcp14>SHOULD</bcp14> allow at least 1024 byte blocks.
        In the following, it is assumed that an implementation realizes two
        procedures on top of a storage:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
-PUT(key,value)
-GET(key) -> value
+PUT(key,block)
+GET(key) -> block
        ]]></artwork>
      <t>
-       There is no explicit delete function as the deletion of a non-expired
-       record would require a revocation of the record.
-       In GNS, zones can only be revoked as a whole. Records automatically
-       expire and it is under the discretion of the storage as to when to 
delete
-       the record. The GNS implementation <bcp14>MUST NOT</bcp14> publish 
expired resource
-       records. Any GNS resolver <bcp14>MUST</bcp14> discard expired records 
returned from
-       the storage.
+       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.
      </t>
      <t>
        Resource records are grouped by their respective labels,
        encrypted and published together in a single records block
-         (RRBLOCK) in the storage under a storage key q as illustrated in 
<xref target="figure_storage_publish"/>.
+       (RRBLOCK) in the storage under a storage key q as illustrated in <xref 
target="figure_storage_publish"/>.
        The implementation <bcp14>MUST</bcp14> use the PUT storage procedure in 
order to update the zone contents accordingly.
      </t>
      <figure anchor="figure_storage_publish" title="Management and publication 
of local zones in the distributed storage.">
@@ -1823,7 +1823,7 @@ GET(key) -> value
        The required knowledge of both zone key and label in combination
        with the similarly derived symmetric secret keys and blinded zone keys
        ensure query privacy (see <xref target="RFC8324"/>, Section 3.5).
-       The storage Key derivation and records
+       The storage key derivation and records
        block creation using is specified in the following sections and a 
high-level
        overview is illustrated in <xref target="figure_storage_derivations"/>.
      </t>
@@ -3739,7 +3739,7 @@ Host: 
000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
        <t>
          This table defines the encode and decode symbols for a given
          symbol value.
-         Each symbol value is 5 bit.
+         Each symbol value encodes 5 bits.
          It can be used to implement the encoding by reading it as:
          A symbol "A" or "a" is decoded to a 5 bit value 10 when decoding.
          A 5 bit block with a value of 18 is encoded to the character "J" when 
encoding.

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