[lsd0003] branch master updated: Added some more formating

[gnunet]

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

elias-summermatter pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new 55acfc4  Added some more formating
55acfc4 is described below

commit 55acfc44d1b59c20abf233af49788e14a44561a9
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Mon Dec 21 14:15:39 2020 +0100

    Added some more formating
---
 draft-summermatter-set-union.xml | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 27be5cb..44e9959 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -465,7 +465,7 @@
                         that the initiating peer wants to initialize a new 
connection.
                     </t>
                     <t>
-                        This Message is sent in the transition between the 
"Initiating connection" state and the "Expect SE" state.
+                        This Message is sent in the transition between the 
<strong>Initiating connection</strong> state and the <strong>Expect SE</strong> 
state.
                     </t>
                     <t>
                         If a peer receives this message the peer answers with 
sending a Strata estimator back.
@@ -522,17 +522,17 @@
                         The Invertible Bloom Filter message contains a slices 
of the IBF.
                     </t>
                     <t>
-                        The IBF message is sent at the start of the protocol 
from the initiating peer in the transaction
-                        between "Expect SE" -> "Passive Decoding" or when the 
IBF does not decode and there is a role change in the
-                        transition between "Active Decoding" -> "Passive 
Decoding".
+                        The <em>IBF</em> message is sent at the start of the 
protocol from the initiating peer in the transaction
+                        between <strong>Expect SE</strong> -> <strong>Passive 
Decoding</strong> or when the IBF does not decode and there is a role change in 
the
+                        transition between <strong>Active Decoding</strong> -> 
<strong>Passive Decoding</strong>.
                     </t>
                     <t>
-                        This message is received either in the state 
transmission between "Expecting IBF" -> "Expecting IBF Last" -> "Active 
Decoding"
+                        This message is received either in the state 
transmission between <strong>Expecting IBF</strong> -> <strong>Expecting IBF 
Last</strong> -> <strong>Active Decoding</strong>
                         if multiple IBFs need to be transmitted or if only one 
IBF needs to be transmitted directly from
-                        "Expecting IBF" -> "Active Decoding". Since the active 
and passive roles can be reversed in this
-                        protocol, receiving the IBF message can initiate a 
role change so receiving
-                        the message can initiate the transitions "Passive 
Decoding" -> "Expecting IBF Last" -> "Active Decoding" and
-                        "Passive Decoding" -> "Active Decoding".
+                        <strong>Expecting IBF</strong> -> <strong>Active 
Decoding</strong>. Since the active and passive roles can be reversed in this
+                        protocol, receiving the <em>IBF</em> message can 
initiate a role change so receiving
+                        the message can initiate the transitions 
<strong>Passive Decoding</strong> -> <strong>Expecting IBF Last</strong> -> 
<strong>Active Decoding</strong> and
+                        <strong>Passive Decoding</strong> -> <strong>Active 
Decoding</strong>.
                     </t>
                 </section>
                 <section anchor="messages_ibf_structure" numbered="true" 
toc="default">

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