From 1ddda5dc97ca1bfe7e13845373f87fc82d3afbcf Mon Sep 17 00:00:00 2001 From: Stefan Haun Date: Fri, 10 Feb 2017 22:18:18 +0100 Subject: [PATCH] XEP-0280: Restructure Section 10: Business Rules --- xep-0280.xml | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/xep-0280.xml b/xep-0280.xml index 4ff05214..714d0766 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -396,25 +396,36 @@ -

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.

+

Handling multiple enable/disable request must adhere to the following rules:

+
    +
  • 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;
    • +
  • 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.
    • +
  • Similarly, the server SHOULD NOT treat multiple disable requests (without an intermediate enable request) as an error;
    • +
  • 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.
    • +
-

Note that &xep0085; recommends sending chat state - notifications as chat type messages, which means that they will be - subject to Carbon-copying. This is intentional.

+

Note: &xep0085; recommends sending chat state notifications as chat type messages, which means that they will be subject to Carbon-copying. This is intentional.

Additionally, there are other considerations for clients that implement Carbons and XEP-0085:

  • Upon receiving an inbound or outbound <gone/> chat state (as a carbon copy) for a given conversation, the client SHOULD visually indicate the conversation is terminated.
    • -
  • In order to prevent unwanted termination of conversations on other resources, clients SHOULD NOT send <gone/> chat states on logout, but instead SHOULD count on the broadcast of unavailable presence to convey the change in attention.
    • +
  • In order to prevent unwanted termination of conversations on other resources, clients SHOULD NOT send <gone/> chat states on logout, instead
    • +
  • clients SHOULD count on the broadcast of unavailable presence to convey the change in attention.
  • Upon receiving an outbound notification of any chat state other than <gone/>, 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.
 -

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.

-

This rule is used to prevent some of the half-failure modes that have been an issue in other prototocols.

+

The following rules prevent some of the half-failure modes that have been an issue in other prototocols:

+
    +
  • 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.
    • +
-

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.

+

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.

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.