commit 1e9384f5649de64f3d74f14c36eb7ae3f714ed24
parent ef5cfefc5b877ceda8c7e0188ef476fba847697f
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 20 Feb 2022 09:39:18 +0100
more start zones
Diffstat:
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1901,15 +1901,22 @@ q := SHA-512 (ZKDF-Public(zk, label))
<t>
The resolution of a GNS name starts by identifying the start zone.
For names ending with a zTLD the start zone is explicitly given in the
- rightmost label of the name to resolve.
+ suffix of the name to resolve.
In order to ensure uniqueness of names with zTLDs any
implementation MUST use the given zone as start zone.
</t>
<t>
- An implementation MUST try to interpret the top-level domain of
- the given name zTLD.
- If the rightmost label can be converted to a valid ztype and zone
- key, it MUST be used as the start zone:
+ An implementation MUST first try to interpret the rightmost label of
+ the given name as zTLD.
+ If the zTLD cannot be decoded or if the decoded zTLD does not indicate
+ a supported ztype, the name is treated as a normal name and start zone
+ discovery MUST continue.
+ If a valid ztype can be found in the rightmost label, the
+ implementation MUST try to synthesize and decode the start zone key
+ according to <xref target="zTLD"/>.
+ If the zone key cannot be synthesized or decoded, the resolution of
+ the name fails and an error is returned to the application.
+ Otherwise, the zone key MUST be used as the start zone:
</t>
<artwork name="" type="" align="left" alt=""><