gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: another FIXME


From: gnunet
Subject: [lsd0001] branch master updated: another FIXME
Date: Wed, 02 Feb 2022 16:44:23 +0100

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 1af28b3  another FIXME
1af28b3 is described below

commit 1af28b3804e447ebcbcc76e9a8f615d894b7b878
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Feb 2 16:44:21 2022 +0100

    another FIXME
---
 draft-schanzen-gns.xml | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 1112353..580538d 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -841,6 +841,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
 +--------+--------+--------+--------+--------+----
 |RESERVED|PRIVATE |SUPPL   |EXPREL  | SHADOW | ...
 +--------+--------+--------+--------+--------+----
+<!-- FIXME: add DELEGATION bit to FLAGS for
+     PKEY and EDKEY (and maybe CNAME/GNS2DNS?)?
+     Otherwise, how can 7.3.1 work if a resolver
+     does not know if a given future record type is
+     a delegation type? -->
          ]]></artwork>
      </figure>
      <t>The Resource Record Flag Wire Format.</t>
@@ -1979,15 +1984,14 @@ example.com = zk2
            <t>
              When the resolver encounters a record of a supported
              zone delegation record type (such as PKEY or EDKEY)
-             and the remainder of
-             the name is not empty, resolution continues
+             and the remainder of the name is not empty, resolution continues
              recursively with the remainder of the name in the
              GNS zone specified in the delegation record.
-             Implementations MUST NOT allow multiple different zone type
+             Implementations MUST NOT allow multiple different zone
              delegations under a single label.
-             Implementations MAY support any subset of zone types.  If
-             an unsupported zone type is encountered, resolution fails and an
-             error MUST be returned. The information that the zone type is
+             Implementations MAY support any subset of ztypes.  If
+             an unsupported ztype is encountered, resolution fails and an
+             error MUST be returned. The information that the ztype is
              unknown SHOULD be returned in the error description. The
              implementation MAY choose not to return the reason for the 
failure,
              merely impacting troubleshooting information for the user.

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