XEP-0280: Message Carbons

Abstract:In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources.
Authors:Joe Hildebrand, Matthew Miller
Copyright:© 1999 - 2015 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Proposed
Type:Standards Track
Version:0.9
Last Updated:2013-10-17

NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process. The Last Call ends on 2015-08-28. Please send your feedback to the standards@xmpp.org discussion list.

Table of Contents


1. Introduction
2. Requirements
3. Discovering Support
4. Enabling Carbons
    4.1. Recommended Error Conditions
5. Disabling Carbons
    5.1. Recommended Error Conditions
6. Receiving Messages to the Bare JID
7. Receiving Messages to the Full JID
8. Sending Messages
9. Avoiding Carbons for a single message
10. Business Rules
    10.1. Handling Multiple Enable/Disalble Requests
    10.2. Interaction with Chat States
    10.3. Handling of Errors
    10.4. Auto-responses
    10.5. Mobile Considerations
11. Security Considerations
12. IANA Considerations
13. XMPP Registrar Considerations
    13.1. Protocol Namespaces
    13.2. Protocol Versioning
14. XML Schema
15. Acknowledgements

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

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.

2. Requirements

3. Discovering Support

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) [1] or section 6.3 of Entity Capabilities (XEP-0115) [2].

Example 1. Client requests information about its own server

<iq xmlns='jabber:client'
    from='romeo@montague.example/garden'
    id='info1'
    to='montague.example'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
  </iq>

Example 2. Server responds with Carbons feature

  <iq xmlns='jabber:client'
    from='montague.example'
    id='info1'
    to='romeo@montague.example/garden'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:carbons:2'/>
    ...
  </query>
</iq>

4. Enabling Carbons

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

Example 3. Client enables Carbons

<iq xmlns='jabber:client'
    from='romeo@montague.example/garden'
    id='enable1'
    type='set'>
  <enable xmlns='urn:xmpp:carbons:2'/>
</iq>

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

Example 4. Server acknowledges enabling Carbons

  <iq xmlns='jabber:client'
      from='romeo@montague.example'
      id='enable1'
      to='romeo@montague.example/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):

Example 5. Server forbids client from enabling Carbons

  <iq xmlns='jabber:client'
      from='romeo@montague.example'
      id='enable1'
      to='romeo@montague.example/garden'
      type='error'>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

4.1 Recommended Error Conditions

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.

5. Disabling Carbons

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

Example 6. Client disables Carbons

<iq xmlns='jabber:client'
    from='romeo@montague.example/garden'
    id='disable1'
    type='set'>
  <disable xmlns='urn:xmpp:carbons:2'/>
</iq>

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

Example 7. Server acknowledges disabling Carbons

<iq xmlns='jabber:client'
    from='romeo@montague.example'
    id='disable1'
    to='romeo@montague.example/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):

Example 8. Server informs client cannot disable Carbons

<iq xmlns='jabber:client'
    from='romeo@montague.example'
    id='disable1'
    to='juliet@capulet.example/balcony'
    type='error'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

5.1 Recommended Error Conditions

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.

6. Receiving Messages to the Bare JID

When the server receives a <message/> of type "chat" addressed to a bare JID (localpart@domainpart), it delivers a copy to each Carbons-enabled resource for the bare JID – in addition to delivering according to RFC 6121 § 8.5.2. This process is sometimes called "forking".

Example 9. Juliet sends Romeo an undirected message

<message xmlns='jabber:client'
         from='juliet@capulet.example/balcony'
         to='romeo@montague.example'
         type='chat'>
  <body>Wherefore art thou, Romeo?</body>
  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>

Example 10. Message Forked to each of Romeo's Carbons-enabled resources

<message xmlns='jabber:client'
         from='juliet@capulet.example/balcony'
         to='romeo@montague.example/garden'
         type='chat'>
  <body>Wherefore art thou, Romeo?</body>
  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>

<message xmlns='jabber:client'
         from='juliet@capulet.example/balcony'
         to='romeo@montague.example/home'
         type='chat'>
  <body>Wherefore art thou, Romeo?</body>
  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>

The receiving server MUST deliver a copy to every Carbons-enabled resource, even if that resource normally would not receive <message/> stanzas addressed to the bare JID (e.g., resources which have broadcast <presence/> with a negative priority). A Carbons-enabled resource MUST NOT receive more than one copy of the <message/>.

7. Receiving Messages to the Full JID

When the server receives a <message/> of type "chat" addressed to a full JID (localpart@domainpart/resourcepart), it delivers the <message/> according to RFC 6121 § 8.5.3, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient.

Each forwarded copy is wrapped using Stanza Forwarding (XEP-0297) [3]. 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/>.

Example 11. Juliet sends Romeo a directed message

<message xmlns='jabber:client'
         from='juliet@capulet.example/balcony'
         to='romeo@montague.example/garden'
         type='chat'>
  <body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body>
  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>

Example 12. Server sends carbon to Romeo's other clients

<message xmlns='jabber:client'
         from='romeo@montague.example'
         to='romeo@montague.example/home'
         type='chat'>
  <received xmlns='urn:xmpp:carbons:2'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <message xmlns='jabber:client'
               from='juliet@capulet.example/balcony'
               to='romeo@montague.example/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>

The receiving server MUST NOT send a forwarded copy to the full JID the original <message/> stanza was addressed to, as that recipient receives the original <message/> stanza.

8. Sending Messages

When a client sends a <message/> of type "chat", 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.

Each forwarded copy is wrapped using Stanza Forwarding (XEP-0297) [4]. 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.

Example 13. Romeo responds to Juliet

<message xmlns='jabber:client'
         from='romeo@montague.example/home'
         to='juliet@capulet.example/balcony'
         type='chat'>
  <body>Neither, fair saint, if either thee dislike.</body>
  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>

Example 14. Romeo's other Carbons-enabled clients receive a copy

<message xmlns='jabber:client'
        from='romeo@montague.example'
        to='romeo@montague.example/garden'
        type='chat'>
  <sent xmlns='urn:xmpp:carbons:2'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <message xmlns='jabber:client'
               to='juliet@capulet.example/balcony'
               from='romeo@montague.example/home'
               type='chat'>
        <body>Neither, fair saint, if either thee dislike.</body>
        <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
      </message>
    </forwarded>
  </sent>
</message>

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

9. Avoiding Carbons for a single 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, for example. To exclude a <message/> from being forwarded to other Carbons-enabled resources, the sending client add a <private/> element qualified by the namespace "urn:xmpp:carbons:2" as a child content element to the <message/> stanza.

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

Example 15. Romeo sends to Juliet, excluding Carbons

<message xmlns='jabber:client'
         from='romeo@montague.example/home'
         to='juliet@capulet.example/home'
         type='chat'>
  <body>Neither, fair saint, if either thee dislike.</body>
  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  <private xmlns='urn:xmpp:carbons:2'/>
</message>

Example 16. Romeo's server delivers original message, without creating Carbon copies

<message xmlns='jabber:client'
         from='romeo@montague.example/home'
         to='juliet@capulet.example/home'
         type='chat'>
  <body>Neither, fair saint, if either thee dislike.</body>
  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  <private xmlns='urn:xmpp:carbons:2'/>
</message>

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, and SHOULD remove the <private/> element before delivering to the recipient.

Note: 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.

10. Business Rules

10.1 Handling Multiple Enable/Disalble Requests

If a client is permitted to enable Carbons during its login session, the server MUST allow the client 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.

10.2 Interaction with Chat States

Note that 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 XEP-0085:

10.3 Handling of Errors

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.

10.4 Auto-responses

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.

10.5 Mobile Considerations

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.

11. Security Considerations

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.

12. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [6].

13. XMPP Registrar Considerations

13.1 Protocol Namespaces

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 [7] shall add the foregoing namespace to the registry located at <http://xmpp.org/registrar/namespaces.html>, as described in Section 4 of XMPP Registrar Function (XEP-0053) [8].

13.2 Protocol Versioning

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.

14. XML Schema

<?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='foward-container' abstract='true'>
    <xs:choice>
      <xs:element name='forwarded'
                  namespace='urn:xmpp:forward:0'
                  minOccurs='1'
                  maxOccurs='1'/>
    </xs:choice>
  </xs:complexType>

</xs:schema>

15. Acknowledgements

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.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0280
Publisher: XMPP Standards Foundation
Status: Proposed
Type: Standards Track
Version: 0.9
Last Updated: 2013-10-17
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0001, XEP-0030, XEP-0085, XEP-0296
Supersedes: XEP-0259
Superseded By: None
Short Name: carbons
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Joe Hildebrand

Email: jhildebr@cisco.com
JabberID: jhildebr@cisco.com

Matthew Miller

Email: linuxwolf@outer-planes.net
JabberID: linuxwolf@outer-planes.net

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2014 by the XMPP Standards Foundation (XSF).

Permissions

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.

Disclaimer of Warranty

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

Limitation of Liability

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.

IPR Conformance

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 <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

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

Appendix G: Notes

1. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

2. XEP-0115: Entity Capabilities <http://xmpp.org/extensions/xep-0115.html>.

3. XEP-0297: Stanza Forwarding <http://xmpp.org/extensions/xep-0297.html>.

4. XEP-0297: Stanza Forwarding <http://xmpp.org/extensions/xep-0297.html>.

5. XEP-0085: Chat State Notifications <http://xmpp.org/extensions/xep-0085.html>.

6. 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/>.

7. 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 <http://xmpp.org/registrar/>.

8. XEP-0053: XMPP Registrar Function <http://xmpp.org/extensions/xep-0053.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.9 (2013-10-17)

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 language; updated mobile considerations to include battery life; changed all examples to use ".example" for the domainpart.

(mm)

Version 0.8 (2012-10-09)

Updated use case text to match schema and examples.

(mm)

Version 0.7 (2012-10-08)

Moved carbons <received/> and <sent/> flags from being a sibling of <forwarded/> to being a parent of <forwarded/>, in compliance with XEP-0297.

(mm)

Version 0.6 (2012-01-06)

Moved carbons flags from being a child of <forwarded/> to being a sibling of <forwarded/>; updating business rules regarding the <gone/> chat state.

(mm)

Version 0.5 (2011-10-31)

Fixed more typos in examples; clarified that each resource only receives one copy of the message (forked or wrapped)

(mm)

Version 0.4 (2011-08-29)

Fixed typos in examples.

(mm)

Version 0.3 (2011-07-11)

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.

(mm)

Version 0.2 (2011-07-10)

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.

(mm)

Version 0.1 (2010-05-03)

Initial published version.

(psa)

Version 0.0.2 (2010-04-21)

Updated after further analysis of edge cases.

(jjh)

Version 0.0.1 (2010-02-25)

First draft.

(jjh)

END