aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <mschanzenbach@posteo.de>2020-10-16 18:08:11 +0200
committerMartin Schanzenbach <mschanzenbach@posteo.de>2020-10-16 18:08:11 +0200
commit6051cb330e6fb672b044c3e7f5db094578bdf56c (patch)
tree770f7696097df72d98f6f10711843b93f2f64c80
parentf330dd9f7555c2c24105cafe5a8a701c249f1417 (diff)
downloadlsd0001-6051cb330e6fb672b044c3e7f5db094578bdf56c.tar.gz
lsd0001-6051cb330e6fb672b044c3e7f5db094578bdf56c.zip
less base32
-rw-r--r--draft-schanzen-gns.xml24
1 files changed, 10 insertions, 14 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 75094c9..0760ce3 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -194,16 +194,6 @@
194 </dd> 194 </dd>
195 </dl> 195 </dl>
196 <t> 196 <t>
197 In this document we use a base-32 data encoding of the binary values,
198 including when they
199 are used in domain names. However, instead of following
200 <xref target="RFC4648"/> we base
201 our character map on the optical character recognition friendly proposal
202 of Crockford <xref target="CrockfordB32"/>.
203 The only difference to Crockford is that the letter
204 "U" decodes to the same base-32 value as the letter "V" (27).
205 </t>
206 <t>
207 The "zid" wire format is defined as follows: 197 The "zid" wire format is defined as follows:
208 </t> 198 </t>
209 <figure anchor="figure_zid"> 199 <figure anchor="figure_zid">
@@ -218,10 +208,16 @@
218 <!-- <postamble>which is a very simple example.</postamble>--> 208 <!-- <postamble>which is a very simple example.</postamble>-->
219 </figure> 209 </figure>
220 <t> 210 <t>
221 The string representation of the "zid" is defined as: 211 For the string representation of the "zid", we use a base-32 encoding
212 "StringEncode".
213 However, instead of following <xref target="RFC4648"/> we base
214 our character map on the optical character recognition friendly
215 proposal of Crockford <xref target="CrockfordB32"/>.
216 The only difference to Crockford is that the letter
217 "U" decodes to the same base-32 value as the letter "V" (27).
222 </t> 218 </t>
223 <artwork name="" type="" align="left" alt=""><![CDATA[ 219 <artwork name="" type="" align="left" alt=""><![CDATA[
224zkl := <Base32(zid)> 220zkl := <StringEncode(zid)>
225 ]]></artwork> 221 ]]></artwork>
226 <t> 222 <t>
227 If "zkl" is less than 63 characters, it is also the "zTLD". 223 If "zkl" is less than 63 characters, it is also the "zTLD".
@@ -496,7 +492,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
496 </dl> 492 </dl>
497 <t> 493 <t>
498 The "zid" of a PKEY is 32 + 4 bytes in length. This means that 494 The "zid" of a PKEY is 32 + 4 bytes in length. This means that
499 a Crockford Base32-encoded "zTLD" will always fit into a single label and does 495 a "zTLD" will always fit into a single label and does
500 not need any further conversion. 496 not need any further conversion.
501 </t> 497 </t>
502 <t> 498 <t>
@@ -665,7 +661,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
665 </dl> 661 </dl>
666 <t> 662 <t>
667 The "zid" of an EDKEY is 32 + 4 bytes in length. This means that 663 The "zid" of an EDKEY is 32 + 4 bytes in length. This means that
668 a Crockford Base32-encoded "zTLD" will always fit into a single label and does 664 a "zTLD" will always fit into a single label and does
669 not need any further conversion. 665 not need any further conversion.
670 </t> 666 </t>
671 <t> 667 <t>