moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

typos 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@357 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-17 17:02:58 +00:00
parent 8590e2c4be
commit 60d578d7ee
3 changed files with 5 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
xep-0045.xml
View File

@ -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'
type='set'>
to='darkcave@macbeth.shakespeare.lit'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/muc#request</value>

2
xep-0050.xml
View File

@ -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>

2
xep-0106.xml
View File

@ -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>