Edits relating to changes from Daurnimator

xep-0369.xml

@@ -143,7 +143,7 @@
     <li>Presence is sent to all participants using bare JID, whether or not the user has an online client. </li>
     <li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li>
     <li>MIX decouples addressing of occupants from their nicknames, so that nickname changes do not affect addressing.</li>
-    <li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
+    <li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
     <li>MIX requires client support and server support from the server providing the MIX service.  Although some protocol is shared with MUC, MUC clients are not interoperable with MIX servers.  This means that where a user chooses to use MIX, all of the users clients need to support MIX.</li>
   </ol>
   <section2 topic="MIX and PubSub" anchor="concepts-pubsub">
@@ -533,7 +533,7 @@
   </join>
 </iq>
 ]]></example>
-      <p>The channel must process the join atomically. The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list.  If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed.    If none of the nodes requested are successfully subscribed to, and error response is sent indicating the reason that the first node requested was not subscribed to.   This response will also include other nodes requested where subscription failed for the same reason.  A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed.  </p>
+      <p>The channel must process the join atomically. The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list.  If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed.    If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to.   This response will also include other nodes requested where subscription failed for the same reason.  A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed.  </p>
       <example caption="Channel Successfully Processes Join"><![CDATA[
 <iq type='result'
     from='coven@mix.shakespeare.example'
@@ -593,7 +593,7 @@
        <li>'Prefer Not Show JID.   If this is set, JID will only be shared if mode is JID-visible-mandatory.</li>
      </ol>
      <p>
-       AUTHOR'S NOTE AND QUESTION: Dave Cridland has suggested.   I would prefer:
+       AUTHOR'S NOTE AND QUESTION: Dave Cridland (+1) has suggested.   I would prefer:
       
         a) User options be sent in the initial join/>.
         b) Unknown options are ignored.
@@ -859,7 +859,7 @@
         A MIX channel MAY support message retraction, where the sender of a messages deletes a messages from the message history and optionally replace it with another message.   This retraction mechanism will be based on the &xep0060; retract operation.   A client looking at message history may choose to look at "current state" which will show status after the retraction or "full history" which will include the message that was retracted.
       </p>
       <p>
-        AUTHOR'S NOTE: Define new protocol to support this and add example.
+        AUTHOR'S NOTE: Define new protocol to support this and add example. 
       </p>
     </section3>
     <section3 topic='Inviting another user to join a Channel' anchor='usecase-user-invite'>
@@ -872,7 +872,7 @@
         <li>The channel member sends the invitation to the invitee.</li>
         <li>The invitee uses the invitation to construct a request to join the channel.</li>
       </ol>
-      <p> AUTHOR'S NOTES AND QUESTION:   To be expanded considerably and perhaps modified based on the following:  Dave Cridland notes: 
+      <p> AUTHOR'S NOTES AND QUESTION:   Need to consider including declines.   To be expanded considerably and perhaps modified based on the following:  Dave Cridland notes: 
         > There are three actors - the Member (who is the inviter), the Invitee, and
         > the Channel.
         > 
@@ -1208,7 +1208,7 @@
   <p>TBD.</p>
 </section1>
 <section1 topic='Acknowledgements' anchor='ack'>
-  <p>Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, and Matthew Wild.</p>
+  <p>Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.</p>
 </section1>
 </xep>