typos

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@357 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0045.xml

@@ -1238,7 +1238,7 @@
   </x>
 </presence>
       ]]></example>
-      <p>However, it MAY done by sending a message of type "groupchat" to the new occupant containing an &lt;x/&gt; child with a &lt;status/&gt; element that has the 'code' attribute set to a value of "100":</p>
+      <p>However, it MAY be done by sending a message of type "groupchat" to the new occupant containing an &lt;x/&gt; child with a &lt;status/&gt; element that has the 'code' attribute set to a value of "100":</p>
       <example caption='Service Warns New Occupant About Lack of Anonymity'><![CDATA[
 <message
     from='darkcave@macbeth.shakespeare.lit'
@@ -1623,7 +1623,7 @@
   </error>
 </presence>
     ]]></example>
-    <p>The use SHOULD then discover its reserved nickname as specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
+    <p>The user SHOULD then discover its reserved nickname as specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
   </section2>
   <section2 topic='Changing Availability Status' anchor='changepres'>
     <p>In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In Jabber, availability is of course noted by a change in presence (specifically the &lt;show/&gt; and &lt;status/&gt; elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.</p>
@@ -2133,9 +2133,7 @@
     <p>It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where data form contains only a 'muc#role' field with a value of "participant".</p>
     <example caption='Occupant Requests Voice'><![CDATA[
 <message from='hag66@shakespeare.lit/pda'
-         id='getvoice1'
+         to='darkcave@macbeth.shakespeare.lit'>
-         to='darkcave@macbeth.shakespeare.lit'
-         type='set'>
   <x xmlns='jabber:x:data' type='submit'>
     <field var='FORM_TYPE'>
       <value>http://jabber.org/protocol/muc#request</value>

xep-0050.xml

@@ -289,7 +289,7 @@
         <field var='service' label='Service'/>
         <field var='runlevel-1' label='Single-User mode'/>
         <field var='runlevel-2' label='Non-Networked Multi-User mode'/>
-        <field var='runlevel-3' label='Full Mult-User mode'/>
+        <field var='runlevel-3' label='Full Multi-User mode'/>
         <field var='runlevel-5' label='X-Windows mode'/>
       </reported>
       <item>

xep-0106.xml

@@ -209,7 +209,7 @@
     <example caption='Invalid escape sequence 2'><strong>foob\41r</strong> is not modified (to <strong>foobAr</strong>) by encoding or decoding transformations.</example>
   </section2>
   <section2 topic='JID Escaping vs. Older Methods' anchor='bizrules-othermethods'>
-    <p>When a client attempts to communicate with another entity through a gateway, it needs to know which encoding mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support for the <strong>jid\20escaping</strong> [sic] feature via Service Discovery as shown above. If there any errors in the service discovery exchange or if support for JID escaping is not discovered, the client SHOULD proceed as follows:</p>
+    <p>When a client attempts to communicate with another entity through a gateway, it needs to know which encoding mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support for the <strong>jid\20escaping</strong> [sic] feature via Service Discovery as shown above. If there are any errors in the service discovery exchange or if support for JID escaping is not discovered, the client SHOULD proceed as follows:</p>
     <ol>
       <li>If the gateway supports the 'jabber:iq:gateway' protocol (as specified in &xep0100;), use that protocol.</li>
       <li>If the gateway does not support the 'jabber:iq:gateway' protocol, use customary escaping mechanisms (such as transformation of the @ character to the % character).</li>