[lsd0001] branch master updated: clarify recursions, make LEHO synthesis a SHOULD

[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 a928ebf  clarify recursions, make LEHO synthesis a SHOULD
a928ebf is described below

commit a928ebf3def4adec7767c7e52c0699e7202606bf
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Feb 2 17:30:50 2022 +0100

    clarify recursions, make LEHO synthesis a SHOULD
---
 draft-schanzen-gns.xml | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 8150e21..ac04d78 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -2051,8 +2051,8 @@ example.com = zk2
              authoritative DNS servers.
              The first successful recursive name resolution result
              is returned to the client.
-             In addition, the resolver returns the queried DNS name as a
-             supplemental LEHO record (<xref target="gnsrecords_leho" />) with 
a
+             In addition, the resolver SHOULD return the queried DNS name as a
+             supplemental LEHO record (see <xref target="gnsrecords_leho" />) 
with a
              relative expiration time of one hour.
            </t>
            <t>
@@ -2086,22 +2086,24 @@ example.com = zk2
              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.
-             This may in turn again trigger a GNS resolution process depending
+             This may in turn trigger a GNS name resolution process depending
              on the system configuration.
              <!-- Note: this permits non-DNS resolvers to be triggered via 
NSS! -->
            </t>
            <t>
-             The recursive DNS resolution process may yield a CNAME as well
-             which in turn may either point into the DNS or GNS namespace
-             (if it ends in a label representation of a zone key).
              In order to prevent infinite loops, the resolver MUST
              implement loop detections or limit the number of recursive
-             resolution steps.
-             If the last CNAME was a DNS name, the resolver returns the DNS 
name
-             as a supplemental LEHO record (<xref target="gnsrecords_leho" />)
+             resolution steps.  The loop detection MUST be effective even
+             if a CNAME found in GNS triggers subsequent GNS lookups via
+             the default operating system name resolution process.
+           </t>
+           <t>
+             If the last CNAME encountered was a DNS name, the resolver
+             SHOULD return the DNS name
+             as a supplemental LEHO record (see <xref target="gnsrecords_leho" 
/>)
              with a relative expiration time of one hour.
-       <!-- Note: Martin: do we actually implement this in GNS today?
-      Seems rather tricky to detect if we go via NSS... -->
+             <!-- Note: Martin: do we actually implement this in GNS today?
+                  Seems rather tricky to detect if we go via NSS... -->
            </t>
          </section>
          <section anchor="box_processing" numbered="true" toc="default">

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