commit d76195f4037b64af0a9f7694acadebdbcec1b7ac
parent 493430793e2814b5fb5fd787b9a186bcfea05128
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 20 Aug 2023 18:23:44 +0200
try to address FIXME
Diffstat:
1 file changed, 49 insertions(+), 10 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1043,7 +1043,7 @@ BEGIN
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
-| PEER ID |
+| PRED PEER ID |
| (32 bytes) |
| |
| |
@@ -1065,12 +1065,16 @@ BEGIN
<t>
An ordered list of path elements may be appended to any routed
<tt>PutMessage</tt>s or <tt>ResultMessage</tt>s.
- The signature of a path element is created by the current hop only
- after it made its routing decision identifiying the successor peer.
+ The last signature (after which the peer ID is omitted)
+ is created by the current hop only after the peer made its routing
+ decision identifiying the successor peer. The peer ID is not
+ included after the last signature as it must be that of the sender of
+ the message. Similarly, the predecessor of the first element of
+ an untruncated path is not stated explicitly, as it must be ZERO.
</t>
<t>
<xref target="figure_path_ex"/> shows the wire format of an example
- path from peer A over peers B and C as it would be received by peer D in the
+ path from peer A over peers B and C and D as it would be received by peer E in the
<tt>PUTPATH</tt> of a <tt>PutMessage</tt>, or as the combined
<tt>PUTPATH</tt> and <tt>GETPATH</tt> of a <tt>ResultMessage</tt>.
The wire format of the path elements allows a natural
@@ -1080,6 +1084,7 @@ BEGIN
a length of 3.
The <tt>ResultMessage</tt> would indicate a path length of 3 as the
sum of the field values in <tt>PUTPATH_L</tt> and <tt>GETPATH_L</tt>.
+ Basically, the last signature does not count for the path length.
</t>
<figure anchor="figure_path_ex" title="Example of a path as found in PutMessages or ResultMessages from A to D.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1122,35 +1127,69 @@ BEGIN
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+| PEER C |
+| (32 bytes) |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE D (last sig) |
+| (64 bytes) |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>
A path may be truncated in which case the signature of the truncated
- path element is omitted leaving only the Peer ID required for the
+ path element is omitted leaving only the peer ID of the peer preceeding
+ the trunction which is required for the
verification of the subsequent path element signature.
- Such a truncated path is indicated with the respective flag (<xref target="route_flags"/>).
- The peer ID of the signer of the last path element is omitted as it must be that of
+ Such a truncated path is indicated with the respective
+ truncated flag (<xref target="route_flags"/>).
+ For truncated paths, the peer ID of the signer of the last path element is
+ again omitted as it must be that of
the sender of the <tt>PutMesssage</tt> or <tt>ResultMessage</tt>. Similarly,
the peer ID of the receiving peer used in the last path element is omitted as
it must be SELF.
- The wire format of a truncated example path from peers B over C to D
- is illustrated in <xref target="figure_path_ex_trunc"/>.
+ The wire format of a truncated example path from peers B over C and D to E
+ (possibly still originating at A, but the origin is unknowable to E due to truncation)
+ is illustrated in <xref target="figure_path_ex_trunc"/>.
Here, a <tt>ResultMessage</tt> would indicate in the <tt>PATH_LEN</tt> field
a length of 1 while
a <tt>PutMessage</tt> would indicate a length of 1 as the sum of
<tt>PUTPATH_L</tt> and <tt>GETPATH_L</tt> fields.
+ Basically, the truncated peer and the last signature do not count
+ for the path length.
</t>
<figure anchor="figure_path_ex_trunc" title="Example of a truncated path from Peer B to Peer D.">
<artwork name="" type="" align="left" alt=""><