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.
An entity advertises support for this protocol by including the "urn:xmpp:carbons:2" feature in its service discovery information features as specified in Service Discovery (XEP-0030) [2] or section 6.3 of Entity Capabilities (XEP-0115) [3].
<iq xmlns='jabber:client'
from='[email protected]/garden'
id='info1'
to='montague.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq xmlns='jabber:client'
from='montague.example'
id='info1'
to='[email protected]/garden'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:carbons:2'/>
<feature var='urn:xmpp:carbons:rules:0'/>
...
</query>
</iq>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":
<iq xmlns='jabber:client'
from='[email protected]/garden'
id='enable1'
type='set'>
<enable xmlns='urn:xmpp:carbons:2'/>
</iq>The server will respond with an IQ-result when Carbons are enabled:
<iq xmlns='jabber:client'
from='[email protected]'
id='enable1'
to='[email protected]/garden'
type='result'/>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):
<iq xmlns='jabber:client'
from='[email protected]'
id='enable1'
to='[email protected]/garden'
type='error'>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>There are various reasons why a server might not be able to enable Carbons for a client. The RECOMMENDED error conditions to return for some reasons are:
See the section Handling Multiple Enable/Disable Requests for considerations when a client attempts to enable Carbons multiple times.
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":
<iq xmlns='jabber:client'
from='[email protected]/garden'
id='disable1'
type='set'>
<disable xmlns='urn:xmpp:carbons:2'/>
</iq>The server will respond with an IQ-result when Carbons are disabled:
<iq xmlns='jabber:client'
from='[email protected]'
id='disable1'
to='[email protected]/garden'
type='result'/>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):
<iq xmlns='jabber:client'
from='[email protected]'
id='disable1'
to='[email protected]/balcony'
type='error'>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>There are various reasons why a server might not be able to disable Carbons for a client. The RECOMMENDED error conditions to return for some reasons are:
See the section Handling Multiple Enable/Disable Requests for considerations when a client attempts to disable Carbons multiple times.
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.
A <message/> is eligible for carbons delivery if it does not contain a <private/> child element and if at least one of the following is true:
To properly handle messages exchanged with a MUC (or similar service), the server must be able to identify MUC-related messages. This can be accomplished by tracking the clients' presence in MUCs, or by checking for the <x xmlns="http://jabber.org/protocol/muc#user"> element in messages. The following rules apply to MUC-related messages:
As the above is an implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.
Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.
Note: previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.
A server implementation can choose to advertise full support of all the rules in §6.1 by including the "urn:xmpp:carbons:rules:0" feature in its service discovery information. If that feature is advertised, the rules above must be treated as REQUIRED and not merely as RECOMMENDED.
Accordingly, if this feature is advertised, a client MAY rely on the server supporting this exact set of rules.
While future versions of this specification (or other specifications) might use a different set of delivery rules, they would signify this by advertising a namespace other than "urn:xmpp:carbons:rules:0".
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 [9] § 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 Stanza Forwarding (XEP-0297) [10] with the following properties:
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.
<message xmlns='jabber:client'
from='[email protected]/balcony'
to='[email protected]/garden'
type='chat'>
<body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>
<message xmlns='jabber:client'
from='[email protected]'
to='[email protected]/home'
type='chat'>
<received xmlns='urn:xmpp:carbons:2'>
<forwarded xmlns='urn:xmpp:forward:0'>
<message xmlns='jabber:client'
from='[email protected]/balcony'
to='[email protected]/garden'
type='chat'>
<body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>
</forwarded>
</received>
</message>
A client MUST NOT accept Carbons that originate from a different JID than the own account (See Security Considerations).
<message xmlns='jabber:client'
from='[email protected]/home'
to='[email protected]'
type='chat'>
<received xmlns='urn:xmpp:carbons:2'>
<forwarded xmlns='urn:xmpp:forward:0'>
<message xmlns='jabber:client'
from='[email protected]/balcony'
to='[email protected]/garden'
type='chat'>
<body>Thou shall meet me tonite, at our house's hall!</body>
</message>
</forwarded>
</received>
</message>
When a client sends a <message/> eligible for carbons delivery, its sending server delivers the <message/> according to RFC 6120 [11] 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 Stanza Forwarding (XEP-0297) [10] with the following properties:
The sending server SHOULD NOT send a forwarded copy to the sending full JID if it is a Carbons-enabled resource.
<message xmlns='jabber:client'
from='[email protected]/home'
to='[email protected]/balcony'
type='chat'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>
<message xmlns='jabber:client'
from='[email protected]'
to='[email protected]/garden'
type='chat'>
<sent xmlns='urn:xmpp:carbons:2'>
<forwarded xmlns='urn:xmpp:forward:0'>
<message xmlns='jabber:client'
to='[email protected]/balcony'
from='[email protected]/home'
type='chat'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>
</forwarded>
</sent>
</message>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.
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 [9]. 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.
<message xmlns='jabber:client'
from='[email protected]/home'
to='[email protected]/home'
type='chat'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
<private xmlns='urn:xmpp:carbons:2'/>
<no-copy xmlns='urn:xmpp:hints'/>
</message>
<message xmlns='jabber:client'
from='[email protected]/home'
to='[email protected]/home'
type='chat'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
<private xmlns='urn:xmpp:carbons:2'/>
<no-copy xmlns='urn:xmpp:hints'/>
</message>Handling multiple enable/disable request must adhere to the following rules:
Note: Chat State Notifications (XEP-0085) [5] 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 Chat State Notifications (XEP-0085) [5]:
The following rules prevent some of the half-failure modes that have been an issue in other protocols:
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.
Forwarded outbound messages MUST NOT be auto-replied to under any circumstances.
Forwarded 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.
Mobile clients are often connected to the server in parallel to another (desktop) client. Therefore, it is highly recommended for mobile clients to implement this protocol to receive all live traffic, and to generally follow the Mobile Compliance Suite recommendations.
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 able to accommodate this protocol.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [13].
This specification defines the following XML namespace:
Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [14] shall add the foregoing namespace to the registry located at <https://xmpp.org/registrar/namespaces.html>, as described in Section 4 of XMPP Registrar Function (XEP-0053) [15].
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:carbons:2'
xmlns='urn:xmpp:carbons:2'
elementFormDefault='qualified'>
<xs:element name='disable' type='empty'/>
<xs:element name='enable' type='empty'/>
<xs:element name='private' type='empty'/>
<xs:element name='received' type='forward-container'/>
<xs:element name='sent' type='forward-container'/>
<xs:simpleType name='empty' abstract='true'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name='forward-container' abstract='true'>
<xs:choice>
<xs:element name='forwarded'
namespace='urn:xmpp:forward:0'
minOccurs='1'
maxOccurs='1'/>
</xs:choice>
</xs:complexType>
</xs:schema>
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.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2024 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 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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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 can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <[email protected]> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.
Errata can be sent to <[email protected]>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <http://tools.ietf.org/html/rfc2119>.
2. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.
3. XEP-0115: Entity Capabilities <https://xmpp.org/extensions/xep-0115.html>.
4. XEP-0184: Message Delivery Receipts <https://xmpp.org/extensions/xep-0184.html>.
5. XEP-0085: Chat State Notifications <https://xmpp.org/extensions/xep-0085.html>.
6. XEP-0333: Displayed Markers <https://xmpp.org/extensions/xep-0333.html>.
7. XEP-0249: Direct MUC Invitations <https://xmpp.org/extensions/xep-0249.html>.
8. The server SHOULD limit carbon-copying to the clients sharing a Multi-Session Nick in that MUC, and MAY inject the <x/> element into such carbon copies. Clients can not respond to carbon-copies of MUC-PMs related to a MUC they are not joined to. Therefore, they SHOULD either ignore such carbon copies, or provide a way for the user to join the MUC before answering.
9. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.
10. XEP-0297: Stanza Forwarding <https://xmpp.org/extensions/xep-0297.html>.
11. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.
12. XEP-0334: Message Processing Hints <https://xmpp.org/extensions/xep-0334.html>.
13. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
14. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
15. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
Fix indentation in examples.
Advance to Stable as per Council Vote from 2021-09-29. Unbelievable.
Incorporate LC feedback: Remove requirement to remove "private" elements (and add interop note), completely reword mobile considerations to fit modern reality.
Add CVE references
Add Georg as author as discussed on-list.
Typographical fix.
Add clear example on problematic (spoofed) carbon messages and that they need to be handled.
Create more explicit and more binding copying rules under the "urn:xmpp:carbons:rules:0" namespace:
Fix off-by-one in dependencies.
Improved readability by restructuring long sentences (Stefan Haun).
Removed ambiguous "forking" term; forbidden the reliance of error handling on the content of a bounced message.
Added <no-copy/> hint.
Fixed typo in XML Schema ("dx").
Removed distinction between full-JID and bare-JID when receiving messages (Georg Lukas).
Define rules around "eligible messages", and provide reasonable default guidelines (Kevin Smith).
Reorganized to emphasize uses; removed discussion on error conditions required of "non-supporting" entities; relaxed multiple enables/disables to effectively no-ops; removed requirement for <private/> to be stripped from messages processed by the sending server; reworded "Interaction with Chat States" to be consistent with RFC 2119 [1] language; updated mobile considerations to include battery life; changed all examples to use ".example" for the domainpart.
Updated use case text to match schema and examples.
Moved carbons <received/> and <sent/> flags from being a sibling of <forwarded/> to being a parent of <forwarded/>, in compliance with XEP-0297.
Moved carbons flags from being a child of <forwarded/> to being a sibling of <forwarded/>; updating business rules regarding the <gone/> chat state.
Fixed more typos in examples; clarified that each resource only receives one copy of the message (forked or wrapped)
Fixed typos in examples.
Required the wrapping message to use the carbon user's bare JID; added to the security concerns about rejecting carbon copies not from the carbon user's bare JID.
Changed enabling and disabling to use separate elements rather than attributes; ensured all elements in the examples have their namespaces more explicitly defined; used message forwarding for carbon copies.
Initial published version.
Updated after further analysis of edge cases.
First draft.
@report{hildebrand2010carbons,
title = {Message Carbons},
author = {Hildebrand, Joe and Miller, Matthew and Lukas, Georg},
type = {XEP},
number = {0280},
version = {1.0.1},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0280.html},
date = {2010-02-25/2021-12-26},
}END