commit 0adb8f4d084225a5684707b63aa6560816bd69d9
parent d5178b0f6bc925914468df9a18cfa437beec51fe
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 20 May 2022 23:13:45 +0200
fix
Diffstat:
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -3323,33 +3323,32 @@ Value Symbol Symbol
</t>
</section>
<section anchor="uc_virthost">
- <name>Virtual Hosting</name>
+ <name>Globally Unique Names and the Web</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.
+ HTTP clients supply a DNS name in the HTTP
+ "Host"-header or as part of 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.
+ with a matching TLS certificate.
+ The global uniqueness 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
+ Not all GNS names are globally unique.
+ But, 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
+ While not human-readable, this globally unique GNS name 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 determines the virtual host as follows:
+ 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 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
+ If there is a LEHO record (<xref target="gnsrecords_leho"/>)
+ containing "www.example.com" in the record set, then the HTTP
+ client uses this as the value of the
"Host"-header field of the HTTP request:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -3359,7 +3358,7 @@ Host: www.example.com
<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
+ and translates the GNS name into a globally unique
zTLD-representation before using it in the "Host"-header field of
the HTTP request:
</t>
@@ -3368,9 +3367,9 @@ GET / HTTP/1.1
Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
]]></artwork>
<t>
- In order to determine a canonical representation of the record with
+ In order to determine the canonical representation of the record with
a zTLD, at most two queries are required:
- First, it must be checked whether "www.example.com" itself points to
+ First, it must be checked whether "www.example.gns" itself points to
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
@@ -3386,7 +3385,7 @@ Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
example above.
In any case, this representation is globally unique.
As such, it can be configured by the HTTP server administrator as a
- virtual host name.
+ virtual host name and respective certificates may be issued.
</t>
<t>
If the HTTP client is a browser, the use of a unique GNS name
