adding FIXMEs to be discussed, might be reasonable optimizations...

1 files changed, 21 insertions, 3 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 5682f02..2f64c20 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1545,7 +1545,7 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
      <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 MUST permit storing at least 164 byte values
+       To be useful, the API MUST permit storing at least 176 byte values
        to be able to support the defined zone delegation record encodings,
        and SHOULD allow at least 1024 byte values.
        We assume that an implementation realizes two procedures on top of a
@@ -1645,20 +1645,23 @@ q := SHA-512 (ZKDF-Public(zk, label))
            ]]></artwork>
        </figure>
        <t>The RRBLOCK Wire Format.</t>
+       <!-- FIXME: Should we remove size and purpose from the wire format? They are entirely redundant, right?
+            I (CG) also think we should then move the expiration first (before ztype), so that it is aligned. -->
        <dl>
          <dt>ZONE TYPE</dt>
          <dd>
-           is the 32-bit zone type.
+           is the 32-bit ztype.
          </dd>
          <dt>ZONE KEY</dt>
          <dd>
            is the blinded zone key "ZKDF-Public(zk, label)"
            to be used to verify SIGNATURE.
+           The length and format of the public key depends on the ztype.
          </dd>
          <dt>SIGNATURE</dt>
          <dd>
            The signature is computed over the data following
-           this field.
+           this field.  The length and format of the signature depends on the ztype.
            The signature is created using the Sign() function of
            the cryptosystem of the zone and the derived private key
            "ZKDF-Private(d, label)" (see <xref target="zones" />).
@@ -1673,6 +1676,12 @@ q := SHA-512 (ZKDF-Public(zk, label))
            size significantly below 4 GB. However, a minimum block size of
            62 kilobytes MUST be supported.
            <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
+           <!-- FIXME: I (CG) think for storage we should go for the minimum
+                as an embedded system may not be able to handle 62k and may
+                still find utility in GNS with smaller records; for the
+                client-side resolver, we MAY choose to require a higher limit;
+                but it is unclear that this belongs here with this field!
+                (and I think we should kill the field! see above!) -->
          </dd>
          <dt>PURPOSE</dt>
          <dd>
@@ -1706,6 +1715,15 @@ q := SHA-512 (ZKDF-Public(zk, label))
          The wire format of the RDATA is illustrated in
          <xref target="figure_rdata"/>.
        </t>
+       <!-- FIXME: I (CG) think we can do better here:
+            use the canonical TYPE-LENGTH-(FLAGS-EXPR)-VALUE
+            (as in TLV) instead of LENGTH-TYPE-(FLAGS-EXPR)-VALUE;
+            we should consider using 16 bit for DATA SIZE and
+            FLAGS (improves alignment, hardly a good use for 32-bit
+            flags or values);
+            We MAY also consider removing RRCOUNT, just bad
+            for alignment, and --- strictly speaking --- redundant,
+            just causes another error check for implementations.  -->
        <figure anchor="figure_rdata">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56