moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

XEP-0280: Restructure Section 10: Business Rules

Browse Source
This commit is contained in:
Stefan Haun 2017-02-10 22:18:18 +01:00 committed by Sam Whited
parent 0680ac1bb9
commit 1ddda5dc97
1 changed files with 19 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
xep-0280.xml
View File

@ -396,25 +396,36 @@
</section1> </section1>
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
<section2 topic='Handling Multiple Enable/Disable 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>Handling multiple enable/disable request must adhere to the following rules:</p>
<ul>
<li>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.</li>
<li>The server SHOULD NOT treat multiple enable requests (without an intermediate disable request) as an error;</li>
<li>the server 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.</li>
<li>Similarly, the server SHOULD NOT treat multiple disable requests (without an intermediate enable request) as an error;</li>
<li>the server 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.</li>
</ul>
</section2> </section2>
<section2 topic='Interaction with Chat States' anchor='bizrules-chatstates'> <section2 topic='Interaction with Chat States' anchor='bizrules-chatstates'>
<p>Note that &xep0085; recommends sending chat state <p><strong>Note: </strong>&xep0085; recommends sending chat state notifications as chat type messages, which means that they will be subject to Carbon-copying. This is intentional.</p>
notifications as chat type messages, which means that they will be
subject to Carbon-copying. This is intentional.</p>
<p>Additionally, there are other considerations for clients that implement Carbons and <cite>XEP-0085</cite>:</p> <p>Additionally, there are other considerations for clients that implement Carbons and <cite>XEP-0085</cite>:</p>
<ul> <ul>
<li>Upon receiving an inbound or outbound &lt;gone/&gt; chat state (as a carbon copy) for a given conversation, the client SHOULD visually indicate the conversation is terminated.</li> <li>Upon receiving an inbound or outbound &lt;gone/&gt; chat state (as a carbon copy) for a given conversation, the client SHOULD visually indicate the conversation is terminated.</li>
<li>In order to prevent unwanted termination of conversations on other resources, clients SHOULD NOT send &lt;gone/&gt; chat states on logout, but instead SHOULD count on the broadcast of unavailable presence to convey the change in attention.</li> <li>In order to prevent unwanted termination of conversations on other resources, clients SHOULD NOT send &lt;gone/&gt; chat states on logout, instead</li>
<li>clients SHOULD count on the broadcast of unavailable presence to convey the change in attention.</li>
<li>Upon receiving an outbound notification of any chat state other than &lt;gone/&gt;, the copied client MAY conclude that the sending client has taken responsibility for the conversation, and make appropriate user interface modifications. For example, notifications could be suppressed on devices receiving the Carbon copies.</li> <li>Upon receiving an outbound notification of any chat state other than &lt;gone/&gt;, the copied client MAY conclude that the sending client has taken responsibility for the conversation, and make appropriate user interface modifications. For example, notifications could be suppressed on devices receiving the Carbon copies.</li>
</ul> </ul>
</section2> </section2>
<section2 topic='Handling of Errors' anchor='bizrules-errors'> <section2 topic='Handling of Errors' anchor='bizrules-errors'>
<p>When a receiving server attempts to deliver a forked message, and that message bounces with an error for any reason, the receiving server MUST NOT forward that error back to the original sender. The receiving server SHOULD use the sent element in the bounce to determine that an error is from a forked message.</p> <p>The following rules prevent some of the half-failure modes that have been an issue in other prototocols:</p>
<p>This rule is used to prevent some of the half-failure modes that have been an issue in other prototocols.</p> <ul>
<li>When a receiving server attempts to deliver a forked message, and that message bounces with an error for any reason, the receiving server MUST NOT forward that error back to the original sender.</li>
<li>The receiving server SHOULD use the sent element in the bounce to determine that an error is from a forked message.</li>
</ul>
</section2> </section2>
<section2 topic='Auto-responses' anchor='bizrules-autoresponses'> <section2 topic='Auto-responses' anchor='bizrules-autoresponses'>
<p>Clients that automatically respond to messages for any reason (e.g., when in the "dnd" presence show state) MUST take adequate care when enabling Carbons in order to prevent storms or loops. Carbon copies of messages MUST NOT be auto-replied to under any circumstances. Forked inbound messages MUST NOT be auto-replied to unless the client has some way of ensuring no more than one auto-reply is sent from all of its user's resources.</p> <p>Clients that automatically respond to messages for any reason (e.g., when in the "dnd" presence show state) MUST take adequate care when enabling Carbons in order to prevent storms or loops.</p>
<p>Carbon copies of messages MUST NOT be auto-replied to under any circumstances.</p>
<p>Forked inbound messages MUST NOT be auto-replied to unless the client has some way of ensuring no more than one auto-reply is sent from all of its user's resources.</p>
</section2> </section2>
<section2 topic='Mobile Considerations' anchor='bizrules-mobile'> <section2 topic='Mobile Considerations' anchor='bizrules-mobile'>
<p>Enabling this protocol on mobile devices needs to be undertaken with care. This protocol can result in additional bandwidth and power usage, possibly decreasing battery lifetime and increasing monetary costs. Additional mechanisms for controlling the Carbon-copying or forking of individual conversations might need to be added to deal with mobile clients in the future.</p> <p>Enabling this protocol on mobile devices needs to be undertaken with care. This protocol can result in additional bandwidth and power usage, possibly decreasing battery lifetime and increasing monetary costs. Additional mechanisms for controlling the Carbon-copying or forking of individual conversations might need to be added to deal with mobile clients in the future.</p>