[muji/master] Update to document a race-free way of joining the conference

[Sjoerd Simons]

---
 xep/muji.xml |   61 +++++++++++++++++++++++++++++++--------------------------
 1 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/xep/muji.xml b/xep/muji.xml
index c1f092e..47fcd9e 100644
--- a/xep/muji.xml
+++ b/xep/muji.xml
@@ -12,7 +12,7 @@
     managing multiparty voice and video conferences within an XMPP MUC
   </abstract>
   &LEGALNOTICE;
-  <number>proto-muji0.1</number>
+  <number>proto-muji0.2</number>
   <status>ProtoXep</status>
   <type>Extension</type>
   <sig>Standards</sig>
@@ -66,11 +66,40 @@ streams.
 </section1>
 
 <section1 topic='Starting a conference' anchor='starting'>
-  <!-- TODO better conflict handling -->
   Assuming there is no existing Muji conference in the <cite>XEP-0045</cite>
   room a new conference can be started by a user putting a Muji stanza with
   the proposed contents in its presence. As shown in the example below:
 
+  This presence indicates that there is a conference available with a video
+  stream and an audio stream.
+</section1>
+
+<section1 topic='Joining a conference' anchor='starting'>
+  <p>
+  Joining a conference is done in two stages. The first step is to
+  declare that preparations are being done to either join or start a muji
+  session inside the MUC. This is indicated by the client sending a presence
+  stanza to the MUC with a preparing element in muji section.
+
+  <code><![CDATA[
+    <presence from='wiccarocks at shakespeare.lit/laptop'
+      to='darkcave at chat.shakespeare.lit/oldhag'>
+      <c xmlns="http://jabber.org/protocol/caps"
+        node="http://telepathy.freedesktop.org/wiki/Muji"
+        ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
+        hash="sha-1" />
+      <muji xmlns='http://telepathy.freedesktop.org/muji>
+        <preparing />
+      </muji>
+    </presence>
+  ]]></code>
+
+  The client MUST then wait until the MUC rebroadcasts its presence message,
+  after which it MUST wait for all other participants that had a preparing
+  element in their presence to finish preparation. Afterwards it should finish
+  it's own preparation by updating its presence with the contents it wants to
+  take part in.
+
   <code><![CDATA[
     <presence from='wiccarocks at shakespeare.lit/laptop'
       to='darkcave at chat.shakespeare.lit/oldhag'>
@@ -81,7 +110,7 @@ streams.
       <muji xmlns='http://telepathy.freedesktop.org/muji'>
         <content name='video'>
           <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
-            <payload-type id='98' name='theora' clockrate='90000'/>
+            <payload-type id='97' name='theora' clockrate='90000'/>
           </description>
         </content>
         <content creator='initiator' name='voice'>
@@ -93,24 +122,6 @@ streams.
        </muji>
     </presence>
   ]]></code>
-
-  This presence indicates that there is a conference available with a video
-  stream and an audio stream.
-</section1>
-
-<section1 topic='Joining a conference' anchor='starting'>
-  <p>
-  A client that is a member of a MUC joins a Muji conference by first
-  updating their MUC presence with a Muji stanza reflecting the contents
-  they want to provide.
-  </p>
-
-  <p>
-  A Muji client MUST NOT advertise Muji 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 Muji data.
   </p>
 
   <p>
@@ -140,7 +151,7 @@ streams.
 
   <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
+  the Jingle session-initiate stanza is sent from one MUC JID to another. This
   allows participants to easily identify sessions as belonging to a Muji
   conference. Content names inside Muji-related Jingle sessions always refer
   to the content with the same name inside the Muji conference.
@@ -157,12 +168,6 @@ streams.
 
 <section1 topic='TODO' anchor='TODO'>
 <ul>
-  <li> There is a race when two participants try to start a new Muji
-       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
-       guaranteed to be ordered.)
-  </li>
   <li> Describe how to add/remove contents.
   </li>
   <li> Add support for relays. Not all participants might have the necessary
-- 
1.5.6.5