xeps/xep-0280.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Message Carbons</title>
  <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>
  &LEGALNOTICE;
  <number>0280</number>
  <status>Proposed</status>
  <lastcall>2017-03-28</lastcall>
  <lastcall>2017-03-01</lastcall>
  <lastcall>2017-02-22</lastcall>
  <lastcall>2015-08-28</lastcall>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XMPP IM</spec>
    <spec>XEP-0001</spec>
    <spec>XEP-0030</spec>
    <spec>XEP-0085</spec>
    <spec>XEP-0296</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>
  <author>
    <firstname>Matthew</firstname>
    <surname>Miller</surname>
    <email>linuxwolf@outer-planes.net</email>
    <jid>linuxwolf@outer-planes.net</jid>
  </author>
  <revision>
    <version>0.12.0</version>
    <date>2017-02-16</date>
    <initials>gl</initials>
    <remark>
      <p>Improved readability by restructuring long sentences (Stefan Haun).</p>
      <p>Removed ambiguous "forking" term; forbidden the reliance of error handling on the content of a bounced message.</p>
    </remark>
  </revision>
  <revision>
    <version>0.11.0</version>
    <date>2017-01-27</date>
    <initials>gl (XEP Editor: ssw)</initials>
    <remark>
      <p>Added &lt;no-copy/&gt; hint.</p>
    </remark>
  </revision>
  <revision>
    <version>0.10.1</version>
    <date>2016-02-16</date>
    <initials>mm (editor)</initials>
    <remark>
      <p>Fixed typo in XML Schema ("dx").</p>
    </remark>
  </revision>
  <revision>
    <version>0.10</version>
    <date>2015-08-24</date>
    <initials>mm (editor)</initials>
    <remark>
      <p>Removed distinction between full-JID and bare-JID when receiving messages (Georg Lukas).</p>
      <p>Define rules around "eligible messages", and provide reasonable default guidelines (Kevin Smith).</p>
    </remark>
  </revision>
  <revision>
    <version>0.9</version>
    <date>2013-10-17</date>
    <initials>mm</initials>
    <remark><p>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 &lt;private/&gt; to be stripped from messages processed by the sending server; reworded "Interaction with Chat States" to be consistent with <cite>RFC 2119</cite> language; updated mobile considerations to include battery life; changed all examples to use ".example" for the domainpart.</p></remark>
  </revision>
  <revision>
    <version>0.8</version>
    <date>2012-10-09</date>
    <initials>mm</initials>
    <remark><p>Updated use case text to match schema and examples.</p></remark>
  </revision>
  <revision>
    <version>0.7</version>
    <date>2012-10-08</date>
    <initials>mm</initials>
    <remark><p>Moved carbons &lt;received/&gt; and &lt;sent/&gt; flags from being a sibling of &lt;forwarded/&gt; to being a parent of &lt;forwarded/&gt;, in compliance with XEP-0297.</p></remark>
  </revision>
  <revision>
    <version>0.6</version>
    <date>2012-01-06</date>
    <initials>mm</initials>
    <remark><p>Moved carbons flags from being a child of &lt;forwarded/&gt; to being a sibling of &lt;forwarded/&gt;; updating business rules regarding the &lt;gone/&gt; chat state.</p></remark>
  </revision>
  <revision>
    <version>0.5</version>
    <date>2011-10-31</date>
    <initials>mm</initials>
    <remark><p>Fixed more typos in examples; clarified that each resource only receives one copy of the message (forked or wrapped)</p></remark>
  </revision>
  <revision>
    <version>0.4</version>
    <date>2011-08-29</date>
    <initials>mm</initials>
    <remark><p>Fixed typos in examples.</p></remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2011-07-11</date>
    <initials>mm</initials>
    <remark><p>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.</p></remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2011-07-10</date>
    <initials>mm</initials>
    <remark><p>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.</p></remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2010-05-03</date>
    <initials>psa</initials>
    <remark><p>Initial published version.</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>
  <revision>
    <version>0.0.1</version>
    <date>2010-02-25</date>
    <initials>jjh</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic='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 state of a conversation is shared between all of a user's clients that implement this protocol.</p>
</section1>

<section1 topic='Requirements' anchor='reqs'>
  <ul>
    <li>Large changes SHOULD NOT be required to existing servers</li>
    <li>Clients that do not implement the new protocol MUST be able
    participate in conversations</li>
    <li>Clients that do not implement the new protocol MUST NOT
    receive a large number of new partial conversations</li>
    <li>Clients that do not implement the new protocol MUST NOT
    receive protocol they do not expect</li>
    <li>All clients that turn on the new protocol MUST be able to see
    all inbound instant messaging messages.</li>
    <li>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.</li>
  </ul>
</section1>
<section1 topic='Discovering Support' anchor='disco'>
  <p>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;.</p>
  <example caption='Client requests information about its own server'><![CDATA[
<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>
    <example caption='Server responds with Carbons feature'><![CDATA[
  <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>]]></example>
</section1>

<section1 topic='Enabling Carbons' anchor='enabling'>
  <p>When a client wants to participate in the Carbons protocol, it enables the protocol by sending an IQ-set containing a child element &lt;enable/&gt; qualified by the namespace "urn:xmpp:carbons:2":</p>
  <example caption='Client enables Carbons'><![CDATA[
<iq xmlns='jabber:client'
    from='romeo@montague.example/garden'
    id='enable1'
    type='set'>
  <enable xmlns='urn:xmpp:carbons:2'/>
</iq>]]></example>
    <p>The server will respond with an IQ-result when Carbons are enabled:</p>
    <example caption='Server acknowledges enabling Carbons'><![CDATA[
  <iq xmlns='jabber:client'
      from='romeo@montague.example'
      id='enable1'
      to='romeo@montague.example/garden'
      type='result'/>]]></example>
  <p>If the server cannot enable Carbons for this client, it sends an IQ-error to the client, with an appropriate error condition (e.g., &lt;forbidden/&gt; if local policy forbids the client from enabling):</p>
    <example caption='Server forbids client from enabling Carbons'><![CDATA[
  <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>]]></example>
  <section2 topic='Recommended Error Conditions' anchor='enabling-errors'>
    <p>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:</p>
    <ul>
      <li><strong>&lt;forbidden/&gt;</strong> if the server's policy forbids the client from enabling Carbons.</li>
      <li><strong>&lt;not-allowed/&gt;</strong> if the request is from a client that is not hosted on this server.</li>
    </ul>
    <p>See the section <link url='#bizrules-multi'>Handling Multiple Enable/Disable Requests</link> for considerations when a client attempts to enable Carbons multiple times.</p>
  </section2>
</section1>

<section1 topic='Disabling Carbons' anchor='disabling'>
  <p>Some clients might want to disable Carbons.  To disable Carbons, the client sends an IQ-set containing a child element &lt;disable/&gt; qualified by the namespace "urn:xmpp:carbons:2":</p>
  <example caption='Client disables Carbons'><![CDATA[
<iq xmlns='jabber:client'
    from='romeo@montague.example/garden'
    id='disable1'
    type='set'>
  <disable xmlns='urn:xmpp:carbons:2'/>
</iq>]]></example>
  <p>The server will respond with an IQ-result when Carbons are disabled:</p>
  <example caption='Server acknowledges disabling Carbons'><![CDATA[
<iq xmlns='jabber:client'
    from='romeo@montague.example'
    id='disable1'
    to='romeo@montague.example/garden'
    type='result'/>]]></example>
  <p>If the server cannot disable Carbons for this client, it sends an IQ-error to the client, with an appropriate error condition (e.g., &lt;not-allowed/&gt; if trying to disable another client's Carbons):</p>
  <example caption='Server informs client cannot disable Carbons'><![CDATA[
<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>]]></example>
  <section2 topic='Recommended Error Conditions' anchor='disabling-errors'>
    <p>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:</p>
    <ul>
      <li><strong>&lt;not-allowed/&gt;</strong> if the request is from a client that is not hosted on this server.</li>
    </ul>
    <p>See the section <link url='#bizrules-multi'>Handling Multiple Enable/Disable Requests</link> for considerations when a client attempts to disable Carbons multiple times.</p>
  </section2>
</section1>

<section1 topic='Messages Eligible for Carbons Delivery' anchor='which-messages'>
  <p>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.</p>

  <p>Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers.</p>
  <p>The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules:</p>
    <ul>
      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "chat".</li>
      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a &lt;body&gt; element.</li>
      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).</li>
      <li>A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).</li>
      <li>A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.</li>
    </ul>
    <p>As this is a 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.</p>
    <p>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.</p>
    <p><strong>Note:</strong> 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.</p>
</section1>

<section1 topic='Receiving Messages' anchor='inbound'>
  <p>When the server receives a &MESSAGE; <link url='#which-messages'>eligible for carbons delivery</link> addressed to a client JID (either bare or full), it delivers the &MESSAGE; according to <cite>RFC 6121</cite> § 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.</p>
  <p>Each forwarded copy is wrapped using &xep0297; with the following properties:</p>
  <ul>
    <li>The wrapping message SHOULD maintain the same 'type' attribute value;</li>
    <li>the 'from' attribute MUST be the Carbons-enabled user's bare JID (e.g., "localpart@domainpart");</li>
    <li>and the 'to' attribute MUST be the full JID of the resource receiving the copy.</li>
    <li>The content of the wrapping message MUST contain a &lt;received/&gt; element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a &lt;forwarded/&gt; element qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE;.</li>
  </ul>

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

  <example caption='Juliet sends Romeo a directed message'><![CDATA[
<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>
  <example caption='Server sends carbon to Romeo&apos;s other clients'><![CDATA[
<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>
]]></example>

</section1>
<section1 topic='Sending Messages' anchor='outbound'>
  <p>When a client sends a &MESSAGE; <link url='#which-messages'>eligible for carbons delivery</link>, its sending server delivers the &MESSAGE; according to <cite>RFC 6120</cite> and <cite>RFC 6121</cite>, 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.</p>
  <p>Each forwarded copy is wrapped using &xep0297; with the following properties:</p>
  <ul>
    <li>The wrapping message SHOULD maintain the same 'type' attribute value;</li>
    <li>the 'from' attribute MUST be the Carbons-enabled user's bare JID (e.g., "localpart@domainpart");</li>
    <li>and the 'to' attribute SHOULD be the full JID of the resource receiving the copy.</li>
    <li>The content of the wrapping message MUST contain a &lt;sent/&gt; element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a &lt;forwarded/&gt; qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE; stanza.</li>
  </ul>

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

  <example caption='Romeo responds to Juliet'><![CDATA[
<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>

  <example caption='Romeo&apos;s other Carbons-enabled clients
                    receive a copy'><![CDATA[
<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>]]></example>


</section1>
<section1 topic='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.
  </p>

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

  <p><strong>Note:</strong>
    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 <cite>RFC 6121</cite>. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the &lt;private/&gt; element for recipients.</p>

  <example caption='Romeo sends to Juliet, excluding Carbons'><![CDATA[
<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'/>
  <no-copy xmlns='urn:xmpp:hints'/>
</message>]]></example>

  <example caption='Romeo&apos;s server delivers original message, without creating Carbon copies'><![CDATA[
<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'/>
  <no-copy xmlns='urn:xmpp:hints'/>
</message>]]></example>
</section1>
<section1 topic='Business Rules' anchor='bizrules'>
  <section2 topic='Handling Multiple Enable/Disable Requests' anchor='bizrules-multi'>
    <p>Handling multiple enable/disable request must adhere to the following rules:</p>
    <ul>
      <li>If a client is permitted to enable Carbons during its login session, the server MUST allow the client to enable and disable the protocol multiple times within a session.</li>
      <li>The server SHOULD NOT treat multiple enable requests (without an intermediate disable request) as an error;</li>
      <li>the server 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.</li>
      <li>Similarly, the server SHOULD NOT treat multiple disable requests (without an intermediate enable request) as an error;</li>
      <li>the server 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.</li>
    </ul>
  </section2>
  <section2 topic='Interaction with Chat States' anchor='bizrules-chatstates'>
    <p><strong>Note: </strong>&xep0085; recommends sending chat state notifications as chat type messages, which means that they will be subject to Carbon-copying.  This is intentional.</p>
    <p>Additionally, there are other considerations for clients that implement Carbons and <cite>XEP-0085</cite>:</p>
    <ul>
      <li>Upon receiving an inbound or outbound &lt;gone/&gt; chat state (as a carbon copy) for a given conversation, the client SHOULD visually indicate the conversation is terminated.</li>
      <li>In order to prevent unwanted termination of conversations on other resources, clients SHOULD NOT send &lt;gone/&gt; chat states on logout, instead</li>
      <li>clients SHOULD count on the broadcast of unavailable presence to convey the change in attention.</li>
      <li>Upon receiving an outbound notification of any chat state other than &lt;gone/&gt;, 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.</li>
    </ul>
  </section2>
  <section2 topic='Handling of Errors' anchor='bizrules-errors'>
    <p>The following rules prevent some of the half-failure modes that have been an issue in other protocols:</p>
    <ul>
      <li>When a server attempts to deliver a (locally generated) carbon copy, and that carbon copy bounces with an error for any reason, the server MUST NOT forward that error back to the original sender.</li>
      <li>The server MUST NOT rely on the &lt;sent/&gt; or &lt;received/&gt; elements in the bounce to determine that an error is from a carbon-copied message, because entities are not required to include the original XML in their error replies as per <cite>RFC 6120</cite>, §8.3.1.</li>
    </ul>
  </section2>
  <section2 topic='Auto-responses' anchor='bizrules-autoresponses'>
    <p>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.</p>
    <p>Forwarded outbound messages MUST NOT be auto-replied to under any circumstances.</p>
    <p>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.</p>
  </section2>
  <section2 topic='Mobile Considerations' anchor='bizrules-mobile'>
    <p>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 of individual conversations might need to be added to deal with mobile clients in the future.</p>
  </section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>The security model assumed by this document is that all of the resources for a single user are in the same trust boundary.</p>
  <ul>
    <li>Any forwarded copies received by a Carbons-enabled client MUST be from that user's bare JID;</li>
    <li>any copies that do not meet this requirement MUST be ignored.</li>
  </ul>
  <p>Outbound chat messages that are encrypted end-to-end are not often useful to receive on other resources.  As such, they should use the &lt;private/&gt; element specified above to avoid such copying, unless the encryption mechanism is able to accommodate this protocol.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'>
  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
    <p>This specification defines the following XML namespace:</p>
    <ul>
      <li>urn:xmpp:carbons:2</li>
    </ul>
    <p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
  </section2>
  <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
    &NSVER;
  </section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
  <code><![CDATA[
<?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>
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
  <p>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.</p>
</section1>
</xep>