commit 9c78d3ff977835a443841bf58b8c4a5dcb9106e8
parent e4cf44575e4b70d4a643aa9bed30774b4b7da16a
Author: Christian Grothoff <christian@grothoff.org>
Date: Wed, 2 Feb 2022 13:03:19 +0100
-minor English improvements
Diffstat:
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1839,7 +1839,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
<t>
GNS clients MUST first try to interpret the top-level domain of
a GNS name as a zone key representation (i.e. a zTLD).
- If the top-level domain is indicated to be a label representation of
+ If the top-level domain is indicated to be a representation of
a zone key with a supported zone type value, the start zone of
the resolution process is implicitly given by the suffix of the name:
</t>
@@ -1851,10 +1851,11 @@ Example name: www.example.<zTLD>
<t>
In GNS, users MAY own and manage their own zones.
Each local zone SHOULD be associated with a single GNS label,
- but users MAY choose to use longer names consisting of
- multiple labels.
+ but users MAY choose to use longer names consisting of
+ multiple labels.
If the name of a locally managed zone matches the suffix
- of the name to be resolved, resolution MUST start from the respective local zone:
+ of the name to be resolved, resolution MUST start from the
+ respective local zone with the longest matching suffix:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.org