<abstract>In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources.</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2010 by the XMPP Standards Foundation (XSF).</copyright>
<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.</permissions>
<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. 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. ##</warranty>
<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 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.</liability>
<conformance>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 <<linkurl='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
</legal>
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0030</spec>
<spec>XEP-0085</spec>
</dependencies>
<supersedes>
<spec>XEP-0259</spec>
</supersedes>
<supersededby/>
<shortname>carbons</shortname>
<author>
<firstname>Joe</firstname>
<surname>Hildebrand</surname>
<email>jhildebr@cisco.com</email>
<jid>jhildebr@cisco.com</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2010-02-25</date>
<initials>jjh</initials>
<remark><p>First draft.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2010-04-21</date>
<initials>jjh</initials>
<remark><p>Updated after further analysis of edge cases.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>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.</p>
<p>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
<body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
<sentxmlns='urn:xmpp:carbons:0'/>
</message>]]></example>
</section2>
<section2topic='Avoiding Carbons for a single message'anchor='avoiding'>
<p>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.</p>
<p>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.</p>
<p>Note: use of the private mechanism will lead to partial
conversations on other devices. This is the intended effect.</p>
<examplecaption='Romeo sends to Juliet, avoiding Carbon copies'><![CDATA[
<message
to='juliet@example.com'
from='romeo@example.net/home'
type='chat'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
<privatexmlns='urn:xmpp:carbons:0'/>
</message>]]></example>
<examplecaption='Romeo's server removes the private tag before forwarding, and does NOT send carbon copies to Romeo's other resources'><![CDATA[
<message
to='juliet@example.com'
from='romeo@example.net/home'
type='chat'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>]]></example>
</section2>
</section1>
<section1topic='Business Rules'anchor='rules'>
<section2topic='Interaction with Chat States'anchor='chatstates'>
<p>Clients that implement Carbons MAY take special use of
&xep0085; notifications.</p>
<p>It is RECOMMENDED that upon receiving an outbound <em>gone</em>
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 <em>gone</em> chat states on logout, but
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:carbons:0</li>
</ul>
<p>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;.</p>
