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.

• Large changes SHOULD NOT be required to existing servers
• Clients that do not implement the new protocol MUST be able participate in conversations
• Clients that do not implement the new protocol MUST NOT receive a large number of new partial conversations
• Clients that do not implement the new protocol MUST NOT receive protocol they do not expect
• All clients that turn on the new protocol MUST be able to see all inbound instant messaging messages.
• All clients that turn on the new protocol MUST be able to see all outbound instant messaging messages from all of the resources of the user, regardless of whether the clients for the other resources have implemented the new protocol.

An entity advertises support for this protocol by including the "urn:xmpp:carbons:2" feature in its service discovery information features as specified in &xep0030; or section 6.3 of &xep0115;.

When a client wants to participate in the Carbons protocol, it enables the protocol by sending an IQ-set containing a child element <enable/> qualified by the namespace "urn:xmpp:carbons:2":

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

If the server cannot enable Carbons for this client, it sends an IQ-error to the client, with an appropriate error condition (e.g., <forbidden/> if local policy forbids the client from enabling):

Some clients might want to disable Carbons. To disable Carbons, the client sends an IQ-set containing a child element <disable/> qualified by the namespace "urn:xmpp:carbons:2":

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

If the server cannot disable Carbons for this client, it sends an IQ-error to the client, with an appropriate error condition (e.g., <not-allowed/> if trying to disable another client's Carbons):

The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons.

The following is the set of rules that a server implementation SHOULD use to determine which messages should be carbon-copied. Future specifications MAY add or override rules, though they are generally advised to use the <private/> element.

When the server receives a &MESSAGE; eligible for carbons delivery addressed to a client JID (either bare or full), it delivers the &MESSAGE; according to RFC 6121 § 8.5.3, and then delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient that did not receive it under the RFC 6121 delivery rules.

Each forwarded copy is wrapped using &xep0297; with the following properties:

• The wrapping message SHOULD maintain the same 'type' attribute value;
• the 'from' attribute MUST be the Carbons-enabled user's bare JID (e.g., "localpart@domainpart");
• and the 'to' attribute MUST be the full JID of the resource receiving the copy.
• The content of the wrapping message MUST contain a <received/> element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a <forwarded/> element qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE;.

The receiving server MUST NOT send a forwarded copy to the client(s) the original &MESSAGE; stanza was addressed to, as these recipients receive the original &MESSAGE; stanza.

A client MUST NOT accept Carbons that originate from a different JID than the own account (See Security Considerations).

When a client sends a &MESSAGE; eligible for carbons delivery, its sending server delivers the &MESSAGE; according to RFC 6120 and RFC 6121, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID sender, excluding the sending client. Note that this happens irrespective of whether the sending client has carbons enabled.

Each forwarded copy is wrapped using &xep0297; with the following properties:

• The wrapping message SHOULD maintain the same 'type' attribute value;
• the 'from' attribute MUST be the Carbons-enabled user's bare JID (e.g., "localpart@domainpart");
• 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/> element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a <forwarded/> qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE; stanza.

The sending server SHOULD NOT send a forwarded copy to the sending full JID if it is a Carbons-enabled resource.

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.

• The sending client MAY exclude a &MESSAGE; from being forwarded to other Carbons-enabled resources, by adding a <private/> element qualified by the namespace "urn:xmpp:carbons:2" and a <no-copy/> hint as described in &xep0334; as child elements of the &MESSAGE; stanza.
• The sending server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resources of the sender.
• The receiving server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resource of the recipient,

Interoperability note: earlier versions of this XEP required or recommended the removal of the <private/> element (albeit not of the <no-copy/> hint) by one of the involved servers, but this behavior was considered as a potential security issue as the sender could silently manipulate the delivery of messages, so that the requirement was lifted. However, clients MUST NOT assume that a message without the element was actually routed to all other resources of the account.

Note: Use of the private mechanism might lead to partial conversations on other devices. This is the intended effect. If the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to RFC 6121. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the <private/> element for recipients.

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

• Any forwarded copies received by a Carbons-enabled client MUST be from that user's bare JID;
• any copies that do not meet this requirement MUST be ignored.

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 able to accommodate this protocol.

This document requires no interaction with &IANA;.

The authors wish to thank Patrick Barry, Teh Chang, Jack Erwin, Craig Kaes, Kathleen McMurry, Tory Patnoe, Peter Saint-Andre, Ben Schumacher, and Kevin Smith for their feedback.