If a server implements the Message Carbons capability, it MUST specify the "urn:xmpp:carbons:2" feature in its service discovery information features as specified in &xep0030; or section 6.3 of &xep0115;. Clients SHOULD NOT attempt to 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.

Messages of type chat that are addressed to the bare JID (localpart@domain) MUST be delivered according to RFC 6121 § 8.5.2, and MUST be copied by the receiving server to all of the resources for that user that are carbons-enabled. The process of making copies is known as "forking."

A carbons-enabled resource MUST NOT receive more than one copy of the message. A carbons-enabled resource that has a negative priority MUST still receive a copy of the message.

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. A copy of the message MUST also be sent to all of the Carbons-enabled resources for the receiving user, excluding the original destination (which is sent the original message according to the routing rules in &rfc6120; and &rfc6120;).

The copies sent to the Carbon-enabled resources are wrapped using &xep0297;. The wrapping message SHOULD maintain the same 'type' attribute value; the 'from' attribute MUST be the Carbon-enabled user's bare JID (e.g. "localpart@domain"); and the 'to' attribute SHOULD be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a <received xmlns='urn:xmpp:carbons:2'/> element and a <forwarded xmlns='urn:xmpp:forward:0'/> which contains the original message (properly namespaced as "jabber:client"):

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.

The copies sent to the Carbon-enabled resources are wrapped using &xep0297;. The wrapping message SHOULD maintain the same 'type' attribute value; the 'from' attribute MUST be the Carbon-enabled user's bare JID (e.g. "localpart@domain"); and the 'to' attribute SHOULD be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a <sent xmlns='urn:xmpp:carbons:2'/> element and a <forwarded xmlns='urn:xmpp:forward:0'/> which contains the original message (properly namespaced as "jabber:client"):

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:2" 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.

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.

Additionally, clients that implement Carbons MAY take special use of chat state notifications:

• 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. It is suggested that the 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 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.

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

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.

This specification defines the following XML namespace:

• urn:xmpp:carbons:2

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