Add address to terminology; HelloMessage review

1 files 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>