moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

small typos noticed by Nate Leon

Browse Source
This commit is contained in:
Peter Saint-Andre 2012-08-24 19:47:37 -06:00
parent 3e8cf4d0b0
commit 49894184e5
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
xep-0045.xml
View File

@ -1325,10 +1325,10 @@
to='coven@chat.shakespeare.lit/thirdwitch'/>
]]></example>
<p>In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "coven" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".</p>
<p>If the user does not specify a room nickname, the service MUST return a &badjid; error:</p>
<p>If the user does not specify a room nickname (note the bare JID on the 'from' address in the following example), the service MUST return a &badjid; error:</p>
<example caption='No Nickname Specified'><![CDATA[
<presence
from='coven@chat.shakespeare.lit/thirdwitch'
from='coven@chat.shakespeare.lit'
id='273hs51g'
to='hag66@shakespeare.lit/pda'
type='error'>
@ -1697,7 +1697,7 @@
</tr>
</table>
<p>The service MUST send the smallest amount of traffic that meets any combination of the above criteria, taking into account service-level and room-level defaults. The service MUST send complete message stanzas only (i.e., it MUST not literally truncate the history at a certain number of characters, but MUST send the largest number of complete stanzas that results in a number of characters less than or equal to the 'maxchars' value specified). If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).</p>
<p>Note: It is known that not all service implementations support MUC history management, so in practice a client might not be able depend on receiving only the history that it has requested.</p>
<p>Note: It is known that not all service implementations support MUC history management, so in practice a client might not be able to depend on receiving only the history that it has requested.</p>
<p>The following examples illustrate the use of this feature.</p>
<example caption='User Requests Limit on Number of Characters in History'><![CDATA[
<presence
@ -1777,7 +1777,7 @@
</section3>
<section3 topic='Live Messages' anchor='enter-live'>
<p>After the room has sent the room subject, it SHALL begin to send live messages, presence changes, occupant "joins" and "leaves", and other real-time traffic ot the new occupant, as described in other sections of this document.</p>
<p>After the room has sent the room subject, it SHALL begin to send live messages, presence changes, occupant "joins" and "leaves", and other real-time traffic to the new occupant, as described in other sections of this document.</p>
</section3>
<section3 topic='Error Conditions' anchor='enter-errorcodes'>