[lsd0004] 01/02: Add address to terminology; HelloMessage review

[gnunet]

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

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

commit 23e204ee1d6e8fe113fcee4e417ac6ddcb24a773
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Dec 25 20:10:09 2022 +0900

    Add address to terminology; HelloMessage review
---
 draft-schanzen-r5n.xml | 95 ++++++++++++++++++++++++++++++--------------------
 1 file changed, 57 insertions(+), 38 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 668fcb9..fe62993 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -165,6 +165,25 @@
     <section anchor="terminology">
     <name>Terminology</name>
     <dl>
+      <dt>Address</dt>
+      <dd>
+        <t>
+         is a UTF-8 <xref target="RFC3629"/> URI
+         <xref target="RFC3986"/> which can be
+         used as address to contact a peer.
+         An example of an addressing scheme used in
+         this document is "r5n+ip+tcp", which refers to a standard TCP/IP 
socket
+         connection. The "hier"-part of the URI must provide a suitable
+         address for the given addressing scheme.
+         The following is a non-normative example of address strings:
+        </t>
+        <figure title="Example Address URIs.">
+          <artwork name="" type="" align="left" alt=""><![CDATA[
+r5n+ip+udp://1.2.3.4:6789/
+gnunet+tcp://12.3.4.5/
+]]></artwork>
+        </figure>
+      </dd>
       <dt>Applications</dt>
       <dd>
         Applications are components which directly use the DHT overlay
@@ -846,16 +865,6 @@ BEGIN
         or <tt>PutMessage</tt>s.
         The status of initiator is relevant for peers when processing 
<tt>ResultMessages</tt>
         and the potential handover of results to the application.
-        <!-- FIXME: Are hello messages should or must?
-        -->
-        Initiation of <tt>HelloMessages</tt> is <bcp14>RECOMMENDED</bcp14>.
-        <tt>HelloMessage</tt>s are used to inform neighbors of
-       a peer about the sender's available addresses. The
-       recipients use these messages to inform their respective
-       Underlays about ways to sustain the connections and to
-       generate HELLO blocks (see <xref target="hello_block"/>)
-        to answer peer discovery queries
-       from other peers.
       </t>
       <t>
         The implementation <bcp14>MUST</bcp14> listen for <tt>RECEIVE(P, 
M)</tt> signals
@@ -1166,15 +1175,31 @@ BEGIN
           <!-- FIXME: While it is discussed here how to hangle HelloMessages
                nowhere in the draft is a HelloMessage created at the
                initiator so it is completely irrelevant atm -->
-         In contrast to a HELLO block, a
+          When the Underlay notifies the implementation of added or removed
+          addresses through <tt>ADDRESS_ADDED</tt> and <tt>ADDRESS_DELETED</tt>
+          it <bcp14>MAY</bcp14> disseminate those changes to neighbors using
+          <tt>HelloMessage</tt>s.
+         <!-- FIXME yesyes this is blabla and obvious when reading the 
processing section.
+              In contrast to a HELLO block, a
          <tt>HelloMessage</tt> does not contain the ID of
          the peer the address information is about: in a
          <tt>HelloMessage</tt>, the address information is always
-         about the sender. Since
-         the Underlay is responsible to determine the
+         about the sender.
+          Since the Underlay is responsible to determine the
          peer ID of the sender for all messages, it would thus be
          redundant to also include the peer ID in the
-         <tt>HelloMessage</tt>.
+         <tt>HelloMessage</tt>.-->
+          <!-- FIXME: Are hello messages should or must?
+               Only recommended not, if so, what if that is not done?
+          -->
+          Initiation of <tt>HelloMessages</tt> by the implementation itself is 
<bcp14>RECOMMENDED</bcp14>.
+          <tt>HelloMessage</tt>s are used to inform neighbors of
+         a peer about the sender's available addresses. The
+         recipients use these messages to inform their respective
+         Underlays about ways to sustain the connections and to
+         generate HELLO blocks (see <xref target="hello_block"/>)
+          to answer peer discovery queries
+         from other peers.
         </t>
         <section anchor="p2p_hello_wire">
           <name>Wire Format</name>
@@ -1232,10 +1257,10 @@ BEGIN
             <dt>ADDRESSES</dt>
             <dd>
               A sequence of exactly URL_CTR
-              0-terminated URIs in UTF-8 encoding representing addresses
-              of this peer. Each URI must begin with a non-empty
-              URI scheme terminated by "://" and followed by some
-              non-empty Underlay- and scheme-specific address encoding.
+              addresses (<xref target="terminology"/>)
+              which can be used to contact the peer.
+              Each address <bcp14>MUST</bcp14> be 0-terminated.
+              The set of addresses <bcp14>MAY</bcp14> be empty.
             </dd>
           </dl>
         </section>
@@ -1251,13 +1276,21 @@ BEGIN
               is discarded.
             </li>
             <li>
-              The signature is verified, including a check that the expiration 
time is in the future. If the signature is invalid, the message is discarded.
+              The signature is verified, including a check that the expiration 
time
+              is in the future. If the signature is invalid, the message is 
discarded.
+            </li>
+            <li>
+              The HELLO information is cached in the routing table until it 
expires,
+              the peer is removed from the routing table, or the information 
is replaced by another message from the peer.
             </li>
             <li>
-              The HELLO information is cached in the routing table until it 
expires, the peer is removed from the routing table, or the information is 
replaced by another message from the peer.
+              <!-- We need a statement like this here. Should they? Can they? 
What if they are (not)? -->
+              <tt>HelloMessages</tt> <bcp14>SHOULD NOT</bcp14> be forwarded.
             </li>
           </ol>
          <t>
+            <!-- FIXME: How? What function of the underlay? The underlay also 
already knows so...
+                 what is the point? -->
            The address information about P should then also be made
            available to each respective Underlays to enable the
            Underlay to maintain optimal connectivity to the
@@ -2169,24 +2202,10 @@ BEGIN
             </dd>
             <dt>ADDRESSES</dt>
             <dd>
-             <t>
-              is a list of UTF-8 <xref target="RFC3629"/> URIs
-              <xref target="RFC3986"/> which can be
-              used as addresses to contact the peer.
-              The strings <bcp14>MUST</bcp14> be 0-terminated.
-              The set of URIs MAY be empty.
-              An example of an addressing scheme used throughout
-              this document is "r5n+ip+tcp", which refers to a standard TCP/IP 
socket
-              connection. The "hier"-part of the URI must provide a suitable
-              address for the given addressing scheme.
-              The following is a non-normative example of address strings:
-              </t>
-          <figure title="Example Address URIs.">
-            <artwork name="" type="" align="left" alt=""><![CDATA[
-r5n+ip+udp://1.2.3.4:6789/
-gnunet+tcp://12.3.4.5/
-             ]]></artwork>
-          </figure>
+              is a list of UTF-8 addresses (<xref target="terminology"/>)
+              which can be used to contact the peer.
+              Each address <bcp14>MUST</bcp14> be 0-terminated.
+              The set of addresses MAY be empty.
             </dd>
             <dt>SIGNATURE</dt>
             <dd>

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