[muji/master] add paragraphs and stuff

[Dafydd Harries]

---
 xep/mingle.xml |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/xep/mingle.xml b/xep/mingle.xml
index c568695..d3625ae 100644
--- a/xep/mingle.xml
+++ b/xep/mingle.xml
@@ -93,55 +93,69 @@ streams.
 </section1>
 
 <section1 topic='Joining a conference' anchor='starting'>
+  <p>
   A client that is a member of a MUC joins a Mingle conference by first
   updating their MUC presence with a Mingle stanza reflecting the contents
   they want to provide.
+  </p>
 
+  <p>
   A Mingle client MUST NOT advertise Mingle capabilities in their MUC presence
   before they have received MUC presence from every other participant in the
   MUC, because otherwise they cannot reliably create a payload type mapping
   that's compatible with those of the existing participants. This means that
   the initial MUC presence must not contain Mingle data.
+  </p>
 
+  <p>
   When a client adds a payload ID to a content description, it MUST have the
   same codec name and encoding parameters as the corresponding entries in
   other participants' payload maps for that content. For instance, if Alice
   defines a payload type with ID 98, codec Speex and a a clock rate of 8000
   for a content called “voice0”, then Bob must define payload type 98
   identically or not at all for that content.
+  </p>
 
+  <p>
   Furthermore, each content description MUST include at least one payload type
   that every other participant supports. In other words, the intersection of
   payload type mappings in descriptions for a content must not be the empty
   set. This avoids clients having to encode the same stream multiple times,
   which can be very costly, and also allows sending the encoded data only once
   where the transport makes this possible (e.g. IP multicast).
+  </p>
 
+  <p>
   Once a client has constructed content descriptions and advertised them in
   its MUC presence, it MUST initiate a Jingle session with every other
   participant. The requirement that it is the joining participant that
   initiates sessions avoids race conditions.
+  </p>
 
+  <p>
   Jingle sessions are initiated between the MUC JIDs of participants. That is,
   the Jingle session-intiate stanza is sent from one MUC JID to another. This
   allows participants to easily identify sessions as belonging to a Mingle
   conference. Content names inside Mingle-related Jingle sessions always refer
   to the content with the same name inside the Mingle conference.
+  </p>
 
+  <p>
   To leave a conference first the Mingle information, presence MUST first be
   removed from the participant's presence; subsequently it SHOULD terminate
   all Jingle sessions related to that conference. Updating the presence first
   reduces the likelihood of situations where new participants initiate
   sessions with participants who are leaving the conference.
+  </p>
 </section1>
 
 <section1 topic='TODO' anchor='TODO'>
 <ul>
-  <li> There is a slight race when two participants try to start a new Mingle
+  <li> There is a race when two participants try to start a new Mingle
        conference at the same time. This can be solves by making the initial
        conference announceemnt two stage and relying on the fact that messages
-       are ordered to be the arbiter. (Note actually find out if presence is
-       ensured to be ordered as well)
+       are ordered to be the arbiter. (Note: actually find out if presence is
+       guaranteed to be ordered.)
   </li>
   <li> Describe how to add/remove contents.
   </li>
-- 
1.5.6.5