[lsd0001] branch master updated: better formatting

[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 d70cb5a  better formatting
d70cb5a is described below

commit d70cb5ad8e25a9068a28d2ba63562ebc81387fef
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri May 20 20:13:52 2022 +0200

    better formatting
---
 draft-schanzen-gns.xml | 64 +++++++++++++++++++++++++++++++-------------------
 1 file changed, 40 insertions(+), 24 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 684ce83..f33fc77 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -3309,38 +3309,48 @@ Value       Symbol            Symbol
        <section>
          <name>Virtual Hosting</name>
          <t>
-            HTTP virtual hosting and TLS Server Name Indication are common
-            use cases on the Web.
-            The HTTP client such as a browser supplies a DNS name in the HTTP
-            "Host"-header or the TLS handshake, respectively.
-            This allows the HTTP server to serve the indicated virtual host
-            with a matching TLS handshake.
-            Any resource record in GNS can be represented as a concatenation of
-            of a GNS label and the zTLD of the zone.
-            While not human-readable, this property of GNS names can be
-            leveraged in order to facilitate the same use cases.
-          </t>
-          <t>
+           HTTP virtual hosting and TLS Server Name Indication are common
+           use cases on the Web.
+           The HTTP client such as a browser supplies a DNS name in the HTTP
+           "Host"-header or the TLS handshake, respectively.
+           This allows the HTTP server to serve the indicated virtual host
+           with a matching TLS handshake.
+           The unambiguity of DNS names are a prerequisite of those use cases.
+         </t>
+         <t>
+           GNS names are not globally unique.
+           But, any resource record in GNS can unambiguously be represented as 
a
+           concatenation of of a GNS label and the zTLD of the zone.
+           While not human-readable, this property of GNS names can be
+           leveraged in order to facilitate the same use cases.
+         </t>
+         <t>
             Consider the GNS name "www.example.gns" entered in a GNS-aware
             HTTP client.
             At first, "www.example.gns" is resolved using GNS yielding a record
             set.
-            Then, the HTTP client first determines the virtual host as follows:
+            Then, the HTTP client determines the virtual host as follows:
+          </t>
+          <t>
+            If there is a LEHO record (<xref target="gnsrecords_leho"/>) in
+            the record set, then the HTTP client uses the record value in the
+            "Host"-header field of the HTTP request:
           </t>
-          <ol>
-            <li>If there is a LEHO record (<xref target="gnsrecords_leho"/>) in
-              the record set, then the HTTP client uses the record value in the
-              "Host"-header field of the HTTP request. Example:
-              "Host: www.example.com".</li>
-            <li>
+          <artwork name="" type="" align="left" alt=""><![CDATA[
+GET / HTTP/1.1
+Host: www.example.com
+          ]]></artwork>
+           <t>
               If there is no LEHO record in the record set,
               then the HTTP client tries to find the zone of the record
               and translates the GNS name into an unabiguous
               zTLD-representation before using it in the "Host"-header field of
-              the HTTP request. Example:
-              "Host: 
www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
-            </li>
-          </ol>
+             the HTTP request:
+           </t>
+           <artwork name="" type="" align="left" alt=""><![CDATA[
+GET / HTTP/1.1
+Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+           ]]></artwork>
           <t>
             In order to determine a canonical representation of the record with
             a zTLD, at most two queries are required:
@@ -3348,7 +3358,13 @@ Value       Symbol            Symbol
             a zone delegation record which would imply that the record set 
which
             was originally resolved is published under the apex label.
             If it does, the unique GNS name is simply the zTLD representation
-            of the delegated zone: "Host: 
000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
+            of the delegated zone:
+          </t>
+          <artwork name="" type="" align="left" alt=""><![CDATA[
+GET / HTTP/1.1
+Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+            ]]></artwork>
+          <t>
             If it does not, the unique GNS name is the concatenation of the
             label "www" and the zTLD representation of the zone as given in the
             example above.

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