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

clarified application-specific error conditions 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2634 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-01-13 19:23:22 +00:00
parent 87dd2f094f
commit 493a28a3ce
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-0205.xml
View File

@ -106,7 +106,7 @@
</section2>
<section2 topic='Simultaneous Resources' anchor='rec-resources'>
<p>A server implementation SHOULD enable a server administrator to limit the number of resources it will allow an account to bind at any one time.</p>
<p>If a connected client attempts to bind a resource but has already reached the configured number of allowable resources, the receiving server MUST return a &constraint; stanza error, which in turn SHOULD include an application-specific error condition of &lt;resource-limit-exceeded/&gt;, as shown in the following example:</p>
<p>If a connected client attempts to bind a resource but has already reached the configured number of allowable resources, the receiving server MUST return a &constraint; stanza error, where the XMPP &ERROR; element SHOULD also include an application-specific error condition of &lt;resource-limit-exceeded/&gt;, as shown in the following example:</p>
<example caption='Resource number limit violation'><![CDATA[
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
@ -121,7 +121,7 @@
</section2>
<section2 topic='Stanza Size' anchor='rec-stanzasize'>
<p>A server implementation SHOULD enable a server administrator to limit the size of stanzas it will accept from a connected client or peer server.</p>
<p>If a connected client or peer server sends a stanza that violates the upper limit, the receiving server SHOULD NOT process the stanza and instead SHOULD return a &notallowed; stanza error, which in turn SHOULD include an application-specific error condition of &lt;stanza-too-big/&gt;, as shown in the following example:</p>
<p>If a connected client or peer server sends a stanza that violates the upper limit, the receiving server SHOULD NOT process the stanza and instead SHOULD return a &notallowed; stanza error, where the XMPP &ERROR; element SHOULD also include an application-specific error condition of &lt;stanza-too-big/&gt;, as shown in the following example:</p>
<example caption='Stanza size limit violation: stanza error'><![CDATA[
<message from='shakespeare.lit' to='iago@shakespare.lit/evilos'>
<error type='modify'>
@ -142,7 +142,7 @@
</section2>
<section2 topic='Multiple Recipients' anchor='rec-recipients'>
<p>A server implementation SHOULD enable a server administrator to limit the number of XML stanzas that a connected client may send to distinct recipients within a given time period.</p>
<p>If a connected client sends too many stanzas to distinct recipients in a given time period, the receiving server SHOULD NOT process the stanza and instead SHOULD return an &unexpected; stanza error, which in turn SHOULD include an application-specific error condition of &lt;too-many-stanzas/&gt;, as shown in the following example:</p>
<p>If a connected client sends too many stanzas to distinct recipients in a given time period, the receiving server SHOULD NOT process the stanza and instead SHOULD return an &unexpected; stanza error, where the XMPP &ERROR; element SHOULD also include an application-specific error condition of &lt;too-many-stanzas/&gt;, as shown in the following example:</p>
<example caption='Stanza recipients violation: stanza error'><![CDATA[
<message from='iago@shakespeare.lit/evilos' to='juliet@capulet.lit'>
<error type='wait'>
@ -211,6 +211,6 @@
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Special thanks to Chris Mullins for calling attention to the need for a specification on this topic. Thanks also to Thiago Camargo, Bruce Campbell, Dave Cridland, Gustavo Felisberto, Justin Karneges, Pedro Melo, Kevin Smith, Michal Vaner, and Matthew Wild for their suggestions.</p>
<p>Special thanks to Chris Mullins for calling attention to the need for a specification on this topic. Thanks also to Thiago Camargo, Bruce Campbell, Dave Cridland, Gustavo Felisberto, Justin Karneges, Alexey Melnikov, Pedro Melo, Kevin Smith, Michal Vaner, and Matthew Wild for their suggestions.</p>
</section1>
</xep>