gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: some REDIRECT; private and relative con


From: gnunet
Subject: [lsd0001] branch master updated: some REDIRECT; private and relative considerations
Date: Thu, 03 Feb 2022 09:48:14 +0100

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 9670d85  some REDIRECT; private and relative considerations
9670d85 is described below

commit 9670d85678e00b223edba74f1a3599bb954a2692
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Thu Feb 3 09:48:10 2022 +0100

    some REDIRECT; private and relative considerations
---
 draft-schanzen-gns.xml | 45 ++++++++++++++++++---------------------------
 1 file changed, 18 insertions(+), 27 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 4df89c5..7658fa2 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1284,37 +1284,27 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
      <section anchor="gnsrecords_rdr" numbered="true" toc="default">
        <name>REDIRECT</name>
        <t>
-         FIXME description
-           A REDIRECT DATA entry is illustrated in <xref 
target="figure_redirectrecord"/>.</t>
+         A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
+         A REDIRECT DATA entry is illustrated in <xref 
target="figure_redirectrecord"/>.</t>
        <figure anchor="figure_redirectrecord">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56
 +-----+-----+-----+-----+-----+-----+-----+-----+
-|                    DNS NAME                   |
+|                    GNS NAME                   |
 /                                               /
 /                                               /
 |                                               |
 +-----+-----+-----+-----+-----+-----+-----+-----+
-|                 DNS SERVER NAME               |
-/                                               /
-/                                               /
-|                                               |
-+-----------------------------------------------+
            ]]></artwork>
        </figure>
        <t> The REDIRECT DATA Wire Format</t>
        <dl>
-         <dt>FIXME</dt>
+         <dt>GNS NAME</dt>
          <dd>
-           The name to continue with in DNS. The value is UTF-8 encoded and
+           The name to continue with in GNS. The value is UTF-8 encoded and
            0-terminated.
          </dd>
        </dl>
-       <t>
-         NOTE: If an application uses DNS names obtained from GNS2DNS records
-         in a DNS request they must first be converted to a punycode 
representation
-         <xref target="RFC5890" />.
-       </t>
      </section>
      <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
        <name>GNS2DNS</name>
@@ -1928,7 +1918,7 @@ example.com = zk2
              appended to the remaining name, except if the remaining name
              is empty and the desired record type is REDIRECT, in which case
              the resolution concludes with the REDIRECT record.
-             If the canonical name ends in ".+",
+               If the redirect name ends in ".+", <!-- FIXME Do we need this? 
-->
              resolution continues in GNS with the new name in the
              current zone. Otherwise, the resulting name is resolved via the
              default operating system name resolution process.
@@ -2256,17 +2246,18 @@ NICK: john (Supplemental)
            are expected to be the exception.
          </t>
          <t>
-           FIXME integrate
-           The expiration time value of the record is a relative time (still 
in microseconds)
-           and not an absolute time. This flag should never be encountered by 
a resolver
-           for records obtained from the storage, but might be present when a 
resolver looks up
-           private records of a zone hosted locally.
-         This is a private record of this peer and it should thus not be
-         published.  Thus, this flag should never be encountered by
-         a resolver for records obtained from the storage.
-         Private records should still be considered just like
-         regular records when resolving labels in local zones.
-
+           In order to ensure availability of records beyond their
+           absolute expiration times, implementations MAY allow to locally
+           define relative expiration time values of records.
+           Records can then be published recurringly with updated
+           absolute expiration times by the implementation.
+         </t>
+         <t>
+           Implementations MAY allow users to manage private records in
+           their zones.
+           Such private records should not be published in the storage.
+           Private records should still be considered just like
+           regular records when resolving labels in local zones.
          </t>
        </section>
        <section anchor="security_dht" numbered="true" toc="default">

-- 
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]