[GNUnet-SVN] [lsd0001] branch master updated: update

[gnunet]

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 8c9d945  update
8c9d945 is described below

commit 8c9d945fe86b8d1beb1f3c3c228d795f545b598f
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Thu Oct 3 17:12:32 2019 +0200

    update
---
 draft-schanzen-gns.xml | 39 +++++++++++++++++++++++++++++++--------
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index a72d3b4..75ef28c 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -188,7 +188,10 @@
 </section>
 <section anchor="gnsrecords_pkey" numbered="true" toc="default">
   <name>PKEY</name>
-  <t>The a PKEY DATA entry has the following format:</t>
+  <t>In GNS, a delegation of a label to a zone is represented througha PKEY
+    record. A PKEY resource record contains the public key of the zone to
+    delegate to. A PKEY record MUST be the only record under a label. No other
+    labels are allows. The a PKEY DATA entry has the following format:</t>
   <figure anchor="figure_pkeyrecord">
     <artwork name="" type="" align="left" alt=""><![CDATA[
       0     8     16    24    32    40    48    56
@@ -204,16 +207,28 @@
 </section>
 <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
   <name>GNS2DNS</name>
-  <t>The a GNS2DNS DATA entry has the following format:</t>
+  <t>It is possible to delegate a label back into DNS through a GNS2DNS record.
+    The resource record contains a DNS name for the resolver to continue with
+    in DNS followed by a DNS server. Both names are in the format defined in
+    <xref target="RFC1034" /> for DNS names.
+    If a resolver encounters a GNS2DNS record it is expected that it first
+    resolves the IP(s) of the DNS servers using DNS. Then, the encountered DNS
+    name is resolved by querying the name server(s).
+    The a GNS2DNS DATA entry has the following format:</t>
   <figure anchor="figure_gns2dnsrecord">
     <artwork name="" type="" align="left" alt=""><![CDATA[
       0     8     16    24    32    40    48    56
       +-----+-----+-----+-----+-----+-----+-----+-----+
-      |                   PUBLIC KEY                  |
-      |                                               |
-      |                                               |
+      |                    DNS NAME                   |
+      /                                               /
+      /                                               /
       |                                               |
       +-----+-----+-----+-----+-----+-----+-----+-----+
+      |                 DNS SERVER NAME               |
+      /                                               /
+      /                                               /
+      |                                               |
+      +-----------------------------------------------+
       ]]></artwork>
     <!--        <postamble>which is a very simple example.</postamble>-->
   </figure>
@@ -221,14 +236,21 @@
 
 <section anchor="gnsrecords_leho" numbered="true" toc="default">
   <name>LEHO</name>
-  <t>The a LEHO DATA entry has the following format:</t>
+  <t>As names in GNS are not globally unique, established practices such as
+    virtual hosting do not apply directly. In order to support such use cases,
+    GNS support a legacy hostname record which can be used by applications
+    (e.g. HTTP clients) in order to provide the necessary information.
+    The resource record contains a string which is not 0-terminated 
representing
+    the legacy hostname to use. It is expected to be found together in a single
+    resource record with an IPv4 or IPv6 address.
+    A LEHO DATA entry has the following format:</t>
   <figure anchor="figure_lehorecord">
     <artwork name="" type="" align="left" alt=""><![CDATA[
       0     8     16    24    32    40    48    56
       +-----+-----+-----+-----+-----+-----+-----+-----+
       |                 LEGACY HOSTNAME               |
-      |                                               |
-      |                                               |
+      /                                               /
+      /                                               /
       |                                               |
       +-----+-----+-----+-----+-----+-----+-----+-----+
       ]]></artwork>
@@ -589,6 +611,7 @@
       <seriesInfo name="RFC" value="8032"/>
       <seriesInfo name="DOI" value="10.17487/RFC8032"/>
     </reference>
+    <reference anchor="RFC1034" 
target="https://www.rfc-editor.org/info/rfc1034";><front><title>Domain names - 
concepts and facilities</title><author initials="P.V." surname="Mockapetris" 
fullname="P.V. Mockapetris"><organization/></author><date year="1987" 
month="November"/><abstract><t>This RFC is the revised basic definition of The 
Domain Name System.  It obsoletes RFC-882.  This memo describes the domain 
style names and their used for host address look up and electronic mail 
forwardin [...]
     <reference anchor="RFC1035" 
target="https://www.rfc-editor.org/info/rfc1035";>
       <front>
         <title>Domain names - implementation and specification</title>

-- 
To stop receiving notification emails like this one, please contact
address@hidden.