%ents; ]>
Message Carbons In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources. This XMPP Extension Protocol is copyright (c) 1999 - 2010 by the XMPP Standards Foundation (XSF). Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). xxxx ProtoXEP Standards Track Standards Council XMPP Core XEP-0001 XEP-0030 XEP-0085 XEP-0259 carbons Joe Hildebrand jhildebr@cisco.com jhildebr@cisco.com 0.0.1 2010-02-25 jjh

First draft.

0.0.2 2010-04-21 jjh

Updated after further analysis of edge cases.

At the time of original writing of this XEP, many XMPP servers handle message stanzas sent to a user@host (or "bare") JID with no resource by delivering that message only to the resource with the highest priority for the target user. Some server implementations, however, have chosen to send these messages to all of the online resources for the target user. If the target user is online with multiple resources when the original message is sent, a conversation ensues on one of the user's devices; if the user subsequently switches devices, parts of the conversation may end up on the alternate device, causing the user to be confused, misled, or annoyed.

This XEP defines an approach for ensuring that all of my devices get both sides of all conversations in order to avoid user confusion. As a pleasant side-effect, information about the current state of a conversation is shared between all of a user's clients that implement this protocol.

If a server implements the Message Carbons capability, it MUST specify the 'urn:xmpp:carbons:0' feature in its service discovery information features as specified in &xep0030; or section 6.3 of &xep0115;. Clients MUST NOT enable or disable Carbons if their server does not support this feature.

]]> ... ... ]]>

Servers MUST NOT enable the Carbons protocol for a client by default, since unmodified clients might be confused by the new protocol. When a client wants to participate in the Carbons protocol, it sends an IQ set to enable the protocol.

]]>

Carbons will generally be enabled before the client sends the first undirected presence, to ensure that all inbound messages will be delivered according to the Carbon rules. The server will respond with an IQ result when Carbons are enabled:

]]>

Some clients might want to disable Carbons. An example of this might be a mobile client that wants Carbons when the application is in the foreground, and disabled when it is in the background. To disable Carbons, clients send an IQ set:

]]>

The server will respond with an IQ result when Carbons are disabled:

]]>

Enabling or disabling Carbons may fail in the several ways. If one of these errors is returned, the server MUST keep the previous state, where the initial state is Carbons disabled. For example, if the first enable returns an error, the server MUST NOT enable Carbons.

The sender has sent a stanza containing XML that does not conform to the appropriate schema or that cannot be processed. One example is an IQ stanza that includes an unrecognized value of the 'type' attribute. Another is changing to the state that is already in effect (enabling Carbons a second time).

]]>

The sender has sent an enable or disable request to a server that does not support the protocol. This SHOULD NOT happen in practice, because clients MUST check for server support before sending their request.

]]>

The sender does is forbidden by policy from enabling or disabling Carbons.

]]>

The receiver does not allow any entity to turn on Carbons. This might occur in a multi-domain deployment, where administrators of one domain allow Carbons, but another does not.

]]>

Messages of type chat that are addressed to the bare JID (localpart@domain) MUST be copied by the receiving server to all of the resources for that user that have non-negative presence priority and have not filtered messages through some other means. The process of making copies is known as "forking." The receiving server SHOULD NOT modify the 'to' address of the forked messages.

Wherefore art thou, Romeo? 0e3141cd80894871a68e6fe6b1ec56fa ... each of romeo@example.net's resources receives this stanza verbatim ]]>

Messages of type "chat" that are addressed to a full JID (localpart@domain/resource) MUST be sent by the receiving server to the addressed resource, and MUST also be sent to all of the Carbons-enabled resources for the receiving user. The goal of the copies to Carbons-enabled resources is to allow those clients to have both halves of *all* IM conversations, including messages that are sent from clients that lock in to particular resources.

Once most of the clients that are deployed have implemented Carbons, clients MAY choose to always send chat type messages to the bare JID. Until then, traditional resource locking is RECOMMENDED. (Note: another XEP might be written to document traditional resource locking, if the documentation in &rfc3921bis; is not sufficient.)

Also 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.

Carbons clients want to have copies of messages going in both directions for other resources associated with the same user. To that end, messages of type chat that are sent from any resource MUST be copied by the sending server to each of the resources that have enabled Carbons, but are not the sending resource. Note that the 'to' address will be the original target of the message (bare JID, as above), and the 'from' address will contain the full JID (localpart@domain/resource) of the sending resource. The 'to' address not matching the JID of the session is somewhat unprecedented in XMPP, which is why Carbons must be explicitly enabled.

Messages that have carbon copies sent back to Carbons-enabled resources MUST NOT be copied back to the originating client. The copies MUST have the full JID (localpart@domain/resource) of the sender as the 'from' address. The copies MUST include a sent element in the urn:xmpp:carbons:0 namespace.

Neither, fair saint, if either thee dislike. 0e3141cd80894871a68e6fe6b1ec56fa ]]> Neither, fair saint, if either thee dislike. 0e3141cd80894871a68e6fe6b1ec56fa ]]>

Some clients might want to avoid carbons on a single message, while still keeping all of the other semantics of Carbon support. This might be useful for clients sending end-to-end encrypted messages, for example.

To avoid a message being Carbon-copied to its other resources, the sending client MUST add a private element in the urn:xmpp:carbons:0 namespace. When the sending server receives the message, it MUST NOT make carbon copies to the other Carbons-enabled resources, and MUST remove the private element before forwarding the message to the intended recipient.

Note: use of the private mechanism will lead to partial conversations on other devices. This is the intended effect.

Neither, fair saint, if either thee dislike. 0e3141cd80894871a68e6fe6b1ec56fa ]]> Neither, fair saint, if either thee dislike. 0e3141cd80894871a68e6fe6b1ec56fa ]]>

Clients that implement Carbons MAY take special use of &xep0085; notifications.

It is RECOMMENDED that upon receiving an outbound gone chat state (as a carbon copy) for a given conversation, that conversation be removed from user display as if the user on the copied client had terminated the conversation. 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 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 muted on non-primary devices.

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.

Clients that automatically respond to messages for any reason (e.g. when in DND presence state) MUST take adequate care when enabling Carbons in order to prevent storms or loops. Carbon copies of outbound messages MUST NOT be auto-replied to under any circumstances. Forked inbound messages SHOULD NOT be auto-replied to, unless the client has some way of knowing that the receiver will not receive more than one auto-reply from other similar clients for the same user.

Since mobile devices often must pay for network traffic based on usage, the enablement of Carbons for such devices should be undertaken advisedly. More complicated mechanisms for controlling the Carbon-copying or forking of individual conversations may need to be added to deal with mobile clients in the future.

The security model assumed by this document is that all of the resources for a single user are in the same trust boundary.

Outbound chat messages that are encrypted end-to-end are not often useful to receive on other resources. As such, they should use the private element specified above to avoid such copying, unless the encryption mechanism is adjusted to have knowledge of Carbons.

This document requires no interaction with &IANA;.

This specification defines the following XML namespace:

  • urn:xmpp:carbons:0

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

&NSVER;
]]>