commit 23fcffb83cb7b139ac7ca0f1364625dbe8c757ce
parent 4f4d8fc9f51b3c114aef8c67f9ceae45b7775b94
Author: Emmanuel Benoist <emmanuel.benoist@bfh.ch>
Date: Tue, 1 Jul 2025 17:04:47 +0200
fixing some issues for compiling the draft
Diffstat:
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/draft-donau.xml b/draft-donau.xml
@@ -24,8 +24,8 @@
<rfc category="info"
docName="draft-donau-01"
- ipr="?????">
-
+ ipr="trust200902">
+<!-- FIXME ipr is copied from lsd0001, need to be updated -->
<front>
<title abbrev="The 'donau' URI scheme">
The 'donau' URI scheme for validation of Donau donation statements.
@@ -198,6 +198,7 @@
</section>
<section anchor="verification" title="Verification of a Donau URI">
+ <t>
The verification requires the Donau verification application to test
if a given taxpayer has got the right to be granted a tax
reduction. For doing this, the Donau verification application must
@@ -205,15 +206,17 @@
statement. The Donau verification application MUST verify the
validity of the donation statement. There are two possibilities:
signature and amount are available or at least one is not available.
-
+ </t>
+ <t>
If signature and amount are available, then the verification
- application will directly generate the corresponding JSON and verify
+ application will verify
that the signature is valide for the server key (see <xref
target="get-server-keys"/> to get the key).
-
+ </t>
+ <t>
If one of both is missing, the application MUST download them from
the get donation statement endpoint <xref target="get-donation-statement"/>.
-
+ </t>
</section>
<section anchor="get-server-keys" title="Access the Donau server public
@@ -330,7 +333,7 @@ Example of an element of USD 100.00 :
value given in the URI.
The verification of the signature is done using EdDSA which was
- presented in <xref target="RFC7748">.
+ presented in <xref target="RFC7748" />.
The verification MAY be done with the following instructions
@@ -349,31 +352,34 @@ Example of an element of USD 100.00 :
</section>
-<section anchor="signature-verification">
-The signature versification step is taking the JSON as
+<section anchor="signature-verification" title="Signature verification">
+ <t>
+The signature verification step is taking the json as
input. Signature MUST be verified using the EdDSA scheme described in
-<xref target="RFC8032"/>. Public key and signature that are given
+<xref target="RFC8032" />. Public key and signature that are given
encoded in Base 32 U Crockford must first be decoded to get a binary
out of it.
+ </t>
</section>
<section anchor="base32-U-crockford" title="Base 32 representation of
binary data">
-All binary data MUST be encoded to be transmitted. For encoding, one
+<t>All binary data MUST be encoded to be transmitted. For encoding, one
MUST use the Base32 U Crockford encoding. This is a variation of the
base32 encoding <xref target ="RFC4648" />. This encoding is presented
in details in the appendix of the RFC for GNU Name System <xref target="RFC9498" />
-
-
+</t>
+<t>
The encoding works similarly to the standard, but uses another Base 32
-Alphabet. The new alphabet is given in the Table <xref target="figure_base32_encoding"/>, below.
-
+Alphabet. The new alphabet is given in the Table <xref target="figure_base32_encoding" />, below.
+</t>
- <figure anchor="figure_base32_encoding" title="The Base 32 Encoding Alphabet."><artwork name="" type="" align="left" alt=""><![CDATA[
+<figure anchor="figure_base32_encoding" title="The Base 32 Encoding Alphabet.">
+ <artwork name="" type="" align="left" alt="table where value beween 0 and 9 are encoded with the character corresponding to the number. Then between 10 and 31, we have all the letters expect I, L, O, U that could be missleading (OCR may not recognize them properly). Pading is the char ="><![CDATA[
Value Encoding Value Encoding Value Encoding Value Encoding
- 0 0 9 9 18 J 27 V
- 1 1 10 A 19 K 28 W
- 2 2 11 B 20 M 29 X
+ 0 0 9 9 18 J 27 V
+ 1 1 10 A 19 K 28 W
+ 2 2 11 B 20 M 29 X
3 3 12 C 21 N 30 Y
4 4 13 D 22 P 31 Z
5 5 14 E 23 Q
@@ -381,13 +387,15 @@ Alphabet. The new alphabet is given in the Table <xref target="figure_base32_enc
7 7 16 G 25 S
8 8 17 H 26 T
-]]></artwork></figure>
-
+ ]]>
+ </artwork>
+</figure>
+<t>
To prevent optical character reading (OCR) problems, a system decoding binary data encoded with base 32 U Crockford MUST
accept the codes presented in the Table <xref target="figure_base32_decoding"/>, below. System reading a U
MUST evaluate it as a V.
-
+</t>
<figure anchor="figure_base32_decoding" title="The Base 32 Decoding Alphabet.">
<artwork name="" type="" align="left" alt=""><