moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Update revision and fix typos

Browse Source
This commit is contained in:
Matthew A. Miller 2015-08-24 08:36:34 -06:00
parent ee9ed5c7e5
commit 756e38b9c2
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
xep-0280.xml
View File

@ -40,6 +40,15 @@
<email>linuxwolf@outer-planes.net</email> <email>linuxwolf@outer-planes.net</email>
<jid>linuxwolf@outer-planes.net</jid> <jid>linuxwolf@outer-planes.net</jid>
</author> </author>
<revision>
<version>0.10</version>
<date>2015-08-24</date>
<initials>mm (editor)</initials>
<remark>
<p>Removed distinction between full-JID and bare-JID when receiving messages (Georg Lukas).</p>
<p>Define rules around "elible messages", and provide reasonable default guidelines (Kevin Smith).</p>
</remark>
</revision>
<revision> <revision>
<version>0.9</version> <version>0.9</version>
<date>2013-10-17</date> <date>2013-10-17</date>
@ -341,7 +350,7 @@
<p><strong>Note:</strong> if the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to <cite>RFC 6121</cite>. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the &lt;private/&gt; element for recipients.</p> <p><strong>Note:</strong> if the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to <cite>RFC 6121</cite>. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the &lt;private/&gt; element for recipients.</p>
</section1> </section1>
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
<section2 topic='Handling Multiple Enable/Disalble Requests' anchor='bizrules-multi'> <section2 topic='Handling Multiple Enable/Disable Requests' anchor='bizrules-multi'>
<p>If a client is permitted to enable Carbons during its login session, the server MUST allow the client to enable and disable the protocol multiple times within a session. The server SHOULD NOT treat multiple enable requests (without an intermediate disable request) as an error; it SHOULD simply return an IQ-result (if the protocol is already enabled) or an IQ-error (if the client is not permitted to enable Carbons) for any subsequent requests after the first. Similarly, the server SHOULD NOT treat multiple disable requests (without an intermediate enable request) as an error; it SHOULD return an IQ-result (if the protocols is already disabled) or an IQ-error (if the client's request failed previously) for any subsequent requests after the first.</p> <p>If a client is permitted to enable Carbons during its login session, the server MUST allow the client to enable and disable the protocol multiple times within a session. The server SHOULD NOT treat multiple enable requests (without an intermediate disable request) as an error; it SHOULD simply return an IQ-result (if the protocol is already enabled) or an IQ-error (if the client is not permitted to enable Carbons) for any subsequent requests after the first. Similarly, the server SHOULD NOT treat multiple disable requests (without an intermediate enable request) as an error; it SHOULD return an IQ-result (if the protocols is already disabled) or an IQ-error (if the client's request failed previously) for any subsequent requests after the first.</p>
</section2> </section2>
<section2 topic='Interaction with Chat States' anchor='bizrules-chatstates'> <section2 topic='Interaction with Chat States' anchor='bizrules-chatstates'>