commit d1f07dffec9c22b7215c68f5fe6f392c030a3189
parent 39e9026ba90ffad363ae5049fc50411e95f458b9
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Thu, 17 Feb 2022 18:25:51 +0100
label length
Diffstat:
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -188,8 +188,13 @@
<dt>Label</dt>
<dd>
A GNS label is a label as defined in <xref target="RFC8499"/>.
- Within this document, labels are always assumed to be U-labels as
+ It is always assumed to be a U-label as
defined in <xref target="RFC5890"/> and <xref target="RFC5891"/>.
+ Consequently, labels are case-sensitive and in Unicode Normalization
+ Form C (NFC) <xref target="Unicode-UAX15"/>.
+ GNS does not impose length restrictions on labels. However, applications
+ MAY ensure that name and label lengths are compatible with legacy
+ DNS.
<!-- FIXME U-labels MUST not be too long. Their A-label representation
must fit into a DNS label. Do we want this limitation for GNS?
Or do we define "compatibility" labels that follow this limitation?
@@ -478,11 +483,14 @@ zkl := Base32GNS-Encode(ztype||zkey)
ztype||zkey := Base32GNS-Decode(zkl)
]]></artwork>
<t>
+ The zkl can be used as-is as zTLD.
+ If an application wants to ensure DNS compatibility of the name,
+ it MAY also represent the zTLD as follows:
If zkl is less than or equal to 63 characters, it can directly be
used as a zTLD.
If zkl is longer than 63 characters, the
zTLD is constructed by dividing zkl into smaller labels separated by the
- label separator ".".
+ label separator U+002E.
Here, the most significant bytes of the "ztype||zkey" concatenation must be contained
in the rightmost label of the resulting string and the least significant
bytes in the leftmost label of the resulting string. This allows the
