gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0004] branch master updated: improve English


From: gnunet
Subject: [lsd0004] branch master updated: improve English
Date: Sun, 20 Aug 2023 17:48:57 +0200

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new fd79295  improve English
fd79295 is described below

commit fd792950235f8d753fe90e0a5b227555c31e5b69
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Aug 20 17:48:41 2023 +0200

    improve English
---
 draft-schanzen-r5n.xml | 46 +++++++++++++++++++++++-----------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 441d700..ed3f2a5 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1024,12 +1024,12 @@ BEGIN
              it is very difficult to understand. Is it worth 32 byte -->
         <name>Path Element</name>
         <t>
-          A Path Element represents a hop in the path a message has taken
+          A path element represents a hop in the path a message has taken
           through the network.
-          The wire format of a Path Element is illustrated in
+          The wire format of a path element is illustrated in
           <xref target="figure_pathelement"/>.
         </t>
-        <figure anchor="figure_pathelement" title="The Wire Format of a Path 
Element.">
+        <figure anchor="figure_pathelement" title="The Wire Format of a path 
element.">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56
 +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1062,9 +1062,9 @@ BEGIN
           </dd>
         </dl>
         <t>
-          An ordered list of Path Elements may be appended to any routed
+          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
+          The signature of a path element is created by the current hop
           after it made its routing decision identifiying the successor peer.
         </t>
         <t>
@@ -1072,7 +1072,7 @@ BEGIN
           path from Peers A over B and C as it would be received by D in the
           <tt>PUTPATH</tt> of a <tt>PutMessage</tt> or the combined
           <tt>PUTPATH</tt> and <tt>GETPATH</tt> of a <tt>ResultMessage</tt>.
-          The wire format of the Path Elements allows a natural
+          The wire format of the path elements allows a natural
           extension of the <tt>PUTPATH</tt> along the route of the 
<tt>ResultMessage</tt>
           to the destination forming the <tt>GETPATH</tt>.
           The <tt>PutMessage</tt> would indicate in the <tt>PATH_LEN</tt> field
@@ -1140,10 +1140,10 @@ BEGIN
 
         <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
-          verification of the subsequent Path Element signature.
+          path element is omitted leaving only the Peer ID 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 last Path Element is omitted as it must be that of
+          The Peer ID of the last path element is omitted as it must be that of
           the sender of the PutMesssage or ResultMessage.
           The wire format of a truncated example path from Peers B over C to D
             is illustrated in <xref target="figure_path_ex_trunc"/>.
@@ -1190,7 +1190,7 @@ BEGIN
          ]]></artwork>
         </figure>
         <t>
-          The SIGNATURE field in a Path Element covers a 64-bit 
contextualization header, the
+          The SIGNATURE field in a path element covers a 64-bit 
contextualization header, the
           the block expiration, a hash of the block
           payload, as well as the predecessor peer ID and the peer ID of the
           successor that the peer making the signature is routing the
@@ -1199,7 +1199,7 @@ BEGIN
          it to PEER SUCCESSOR.  The wire format is illustrated
           in <xref target="figure_pathelewithpseudo"/>.
         </t>
-        <figure anchor="figure_pathelewithpseudo" title="The Wire Format of 
the Path Element for Signing.">
+        <figure anchor="figure_pathelewithpseudo" title="The Wire Format of 
the path element for Signing.">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56
 +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1459,7 +1459,7 @@ BEGIN
             </dd>
             <dt>PATH_LEN</dt>
             <dd>
-              is a 16-bit number indicating the number of Path Elements
+              is a 16-bit number indicating the number of path elements
               recorded in PUTPATH.
               As PUTPATH is optional, this value may be zero.
               If the PUTPATH is enabled, set initially to 0 by the initiator.
@@ -1502,7 +1502,7 @@ BEGIN
             <dt>PUTPATH</dt>
             <dd>
               the variable-length PUT path.
-              The path consists of a list of PATH_LEN Path Elements.
+              The path consists of a list of PATH_LEN path elements.
               Set by the initiator to 0.
               Incremented by processing peers.
             </dd>
@@ -1615,11 +1615,11 @@ BEGIN
               of the received <tt>PutMessage</tt>.
               In each message the all selected addresses and the local peer 
<bcp14>MUST</bcp14> be added to the
               <tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt> is incremented by 1.
-              If the <tt>RecordRoute</tt> flag is set, a new Path Element is 
created using the
+              If the <tt>RecordRoute</tt> flag is set, a new path element is 
created using the
               predecessor peer ID and the signature of the current peer.
-              The Path Element is added to the <tt>PUTPATH</tt> fields and the 
<tt>PATH_LEN</tt> field is incremented by 1.
-              When creating the Path Element signature, the successor must be 
set to the recipient peer <tt>P</tt> of the <tt>PutMessageP</tt>.
-              The successor in the new Path Element is the recipient peer 
<tt>P</tt> of               Finally, the messages are sent using <tt>SEND(P, 
PutMessageP)</tt> each recipient.
+              The path element is added to the <tt>PUTPATH</tt> fields and the 
<tt>PATH_LEN</tt> field is incremented by 1.
+              When creating the path element signature, the successor must be 
set to the recipient peer <tt>P</tt> of the <tt>PutMessageP</tt>.
+              The successor in the new path element is the recipient peer 
<tt>P</tt> of               Finally, the messages are sent using <tt>SEND(P, 
PutMessageP)</tt> each recipient.
             </li>
           </ol>
         </section>
@@ -1933,7 +1933,7 @@ BEGIN
             </dd>
             <dt>PUTPATH_L</dt>
             <dd>
-              is a 16-bit number indicating the number of Path Elements 
recorded
+              is a 16-bit number indicating the number of path elements 
recorded
               in <tt>PUTPATH</tt>. As <tt>PUTPATH</tt> is optional, this value 
may be zero
              even if the message has traversed several peers.
               Set by the initiator to the <tt>PATH_LEN</tt> of the 
<tt>PutMessage</tt>
@@ -1943,7 +1943,7 @@ BEGIN
             </dd>
             <dt>GETPATH_L</dt>
             <dd>
-              is a 16-bit number indicating the number of Path Elements
+              is a 16-bit number indicating the number of path elements
               recorded in <tt>GETPATH</tt>. As <tt>GETPATH</tt> is optional, 
this value may be zero
              even if the message has traversed several peers.
               Set by the initiator to 0.
@@ -1983,7 +1983,7 @@ BEGIN
             <dt>PUTPATH</dt>
             <dd>
               the variable-length PUT path.
-              The path consists of a list of <tt>PUTPATH_L</tt> Path Elements.
+              The path consists of a list of <tt>PUTPATH_L</tt> path elements.
               Set by the initiator to the the <tt>PUTPATH</tt> of the 
<tt>PutMessage</tt>
               from which the block originated.
               Modified by processing peers in case of path truncation.
@@ -1991,7 +1991,7 @@ BEGIN
             <dt>GETPATH</dt>
             <dd>
               the variable-length PUT path.
-              The path consists of a list of <tt>GETPATH_L</tt> Path Elements.
+              The path consists of a list of <tt>GETPATH_L</tt> path elements.
               Set by processing peers.
             </dd>
             <dt>LAST HOP SIGNATURE</dt>
@@ -2759,8 +2759,8 @@ Contact: gnunet-registry@gnunet.org
         <artwork name="" type="" align="left" alt=""><![CDATA[
 Purpose | Name            | References | Description
 --------+-----------------+------------+---------------
-6         DHT PATH Element  [This.I-D]   DHT message routing data
-7         HELLO Payload     [This.I-D]   Peer contact information
+6         DHT PATH ELEMENT  [This.I-D]   DHT message routing data
+7         HELLO PAYLOAD     [This.I-D]   Peer contact information
 ]]></artwork>
       </figure>
       </section>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]