moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 10:42:19 -05:00
Code Issues Releases Wiki Activity

Merge branch 'master' of athena.jabber.org:xmpp

Browse Source
This commit is contained in:
Peter Saint-Andre 2013-10-23 12:36:37 -06:00
commit a1749c680f
1 changed files with 154 additions and 156 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

270
xep-0280.xml
View File

@ -39,6 +39,12 @@
<email>linuxwolf@outer-planes.net</email> <email>linuxwolf@outer-planes.net</email>
<jid>linuxwolf@outer-planes.net</jid> <jid>linuxwolf@outer-planes.net</jid>
</author> </author>
<revision>
<version>0.9</version>
<date>2012-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> <revision>
<version>0.8</version> <version>0.8</version>
<date>2012-10-09</date> <date>2012-10-09</date>
@ -124,171 +130,158 @@
have implemented the new protocol.</li> have implemented the new protocol.</li>
</ul> </ul>
</section1> </section1>
<section1 topic='Use Cases' anchor='usecases'> <section1 topic='Discovering Support' anchor='disco'>
<section2 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>
<p>If a server implements the Message Carbons capability, it MUST specify the "urn:xmpp:carbons:2" feature in its service discovery information features as specified in &xep0030; or section 6.3 of &xep0115;. Clients SHOULD NOT attempt to enable or disable Carbons if their server does not support this feature.</p>
<example caption='Client requests information about its own server'><![CDATA[ <example caption='Client requests information about its own server'><![CDATA[
<iq xmlns='jabber:client' <iq xmlns='jabber:client'
type='get' from='romeo@montague.example/garden'
from='romeo@montague.net/orchard' id='info1'
id='info1'> to='montague.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]></example> </iq>]]></example>
<example caption='Server responds with Carbons feature'><![CDATA[ <example caption='Server responds with Carbons feature'><![CDATA[
<iq xmlns='jabber:client' <iq xmlns='jabber:client'
type='get' from='montague.example'
to='romeo@montague.net/home' id='info1'
from='montague.net' to='romeo@montague.example/garden'
id='info1'> type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'> <query xmlns='http://jabber.org/protocol/disco#info'>
... ...
<feature var='urn:xmpp:carbons:2'/> <feature var='urn:xmpp:carbons:2'/>
... ...
</query> </query>
</iq>]]></example> </iq>]]></example>
</section2> </section1>
<section2 topic='Enabling Carbons' anchor='enabling'> <section1 topic='Enabling Carbons' anchor='enabling'>
<p>Servers MUST NOT enable the Carbons protocol for a client by default, since unmodified clients might be confused by the new protocol. When a client wants to participate in the Carbons protocol, it sends an IQ set to enable the protocol.</p> <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[ <example caption='Client enables Carbons'><![CDATA[
<iq xmlns='jabber:client' <iq xmlns='jabber:client'
type='set' from='romeo@montague.example/garden'
id='enable1'> id='enable1'
type='set'>
<enable xmlns='urn:xmpp:carbons:2'/> <enable xmlns='urn:xmpp:carbons:2'/>
</iq>]]></example> </iq>]]></example>
<p>Carbons will generally be enabled before the client sends the first undirected presence, to ensure that all inbound messages will be delivered according to the Carbon rules. The server will respond with an IQ result when Carbons are enabled:</p> <p>The server will respond with an IQ-result when Carbons are enabled:</p>
<example caption='Server acknowledges Carbons enablement'><![CDATA[ <example caption='Server acknowledges enabling Carbons'><![CDATA[
<iq xmlns='jabber:client'
type='result'
id='enable1'/>]]></example>
</section2>
<section2 topic='Disabling Carbons' anchor='disabling'>
<p>Some clients might want to disable Carbons. An example of this might be a mobile client that wants Carbons when the application is in the foreground, and disabled when it is in the background. To disable Carbons, clients send an IQ set:</p>
<example caption='Client disables Carbons'><![CDATA[
<iq xmlns='jabber:client'
type='set'
id='disable1'>
<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 Carbons disablement'><![CDATA[
<iq xmlns='jabber:client'
type='result'
id='disable1'/>]]></example>
</section2>
<section2 topic='Error Cases' anchor='errors'>
<p>Enabling or disabling Carbons may fail in the several ways. If one of these errors is returned, the server MUST keep the previous state, where the initial state is Carbons disabled. For example, if the first enable returns an error, the server MUST NOT enable Carbons.</p>
<section3 topic='bad-request' anchor='bad-request'>
<p>The sender has sent a stanza containing XML that does not conform to the appropriate schema or that cannot be processed. One example is an IQ stanza that includes an unrecognized value of the 'type' attribute. Another is changing to the state that is already in effect (enabling Carbons a second time).</p>
<example caption='Error: bad-request'><![CDATA[
<iq xmlns='jabber:client' <iq xmlns='jabber:client'
from='romeo@montague.example'
id='enable1' id='enable1'
type='error'> to='romeo@montague.example/garden'
<error type='modify'> type='result'/>]]></example>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <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>
</error> <example caption='Server forbids client from enabling Carbons'><![CDATA[
</iq>]]></example>
</section3>
<section3 topic='feature-not-implemented' anchor='feature-not-implemented'>
<p>The sender has sent an enable or disable request to a server
that does not support the protocol. This SHOULD NOT happen in
practice, because clients MUST check for server support before
sending their request.</p>
<example caption='Error: feature-not-implemented'><![CDATA[
<iq xmlns='jabber:client'
id='enable1'
type='error'>
<error type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>]]></example>
</section3>
<section3 topic='forbidden' anchor='forbidden'>
<p>The sender is forbidden by policy from enabling or
disabling Carbons.</p>
<example caption='Error: forbidden'><![CDATA[
<iq xmlns='jabber:client' <iq xmlns='jabber:client'
from='romeo@montague.example'
id='enable1' id='enable1'
to='romeo@montague.example/garden'
type='error'> type='error'>
<error type='auth'> <error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq>]]></example> </iq>]]></example>
</section3> <section2 topic='Recommended Error Conditions' anchor='enabling-errors'>
<section3 topic='not-allowed' anchor='not-allowed'> <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>
<p>The receiver does not allow any entity to turn on Carbons. <ul>
This might occur in a multi-domain deployment, where <li><strong>&lt;forbidden/&gt;</strong> if the server's policy forbids the client from enabling Carbons.</li>
administrators of one domain allow Carbons, but another does <li><strong>&lt;not-allowed/&gt;</strong> if the request is from a client that is not hosted on this server.</li>
not.</p> </ul>
<example caption='Error: not-allowed'><![CDATA[ <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' <iq xmlns='jabber:client'
id='enable1' 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'> type='error'>
<error type='cancel'> <error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq>]]></example> </iq>]]></example>
</section3> <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> </section2>
<section2 topic='Receiving Messages' anchor='inbound'> </section1>
<p>Messages of type chat that are addressed to the bare JID (localpart@domain) MUST be delivered according to RFC 6121 § 8.5.2, and MUST be copied by the receiving server to all of the resources for that user that are carbons-enabled. The process of making copies is known as "forking."</p>
<example caption='Juliet sends Romeo an undirected message, which is forked'><![CDATA[ <section1 topic='Receiving Messages to the Bare JID' anchor='inbound-bare'>
<p>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 <cite>RFC 6121</cite> § 8.5.2. This process is sometimes called "forking".</p>
<example caption='Juliet sends Romeo an undirected message'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='juliet@example.com/balcony' from='juliet@capulet.example/balcony'
to='romeo@example.net' to='romeo@montague.example'
type='chat'> type='chat'>
<body>Wherefore art thou, Romeo?</body> <body>Wherefore art thou, Romeo?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message> </message>]]></example>
]]></example>
<example caption='Message Copied to Each of Romeo&apos;s Available Resources'><![CDATA[ <example caption='Message Forked to each of Romeo&apos;s Carbons-enabled resources'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='juliet@example.com/balcony' from='juliet@capulet.example/balcony'
to='romeo@example.net/garden' to='romeo@montague.example/garden'
type='chat'> type='chat'>
<body>Wherefore art thou, Romeo?</body> <body>Wherefore art thou, Romeo?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message> </message>
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='juliet@example.com/balcony' from='juliet@capulet.example/balcony'
to='romeo@example.net/home' to='romeo@montague.example/home'
type='chat'> type='chat'>
<body>Wherefore art thou, Romeo?</body> <body>Wherefore art thou, Romeo?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message> </message>]]></example>
]]></example>
<p>A carbons-enabled resource MUST NOT receive more than one copy of the message. A carbons-enabled resource that has a negative priority MUST still receive a copy of the message.</p> <p>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;.</p>
</section1>
<p>Messages of type "chat" that are addressed to a full JID (localpart@domain/resource) MUST be sent by the receiving server to the addressed resource. A copy of the message MUST also be sent to all of the Carbons-enabled resources for the receiving user, excluding the original destination (which is sent the original message according to the routing rules in &rfc6120; and &rfc6121;).</p> <section1 topic='Receiving Messages to the Full JID' anchor='inbound-full'>
<p>When the server receives a &MESSAGE; of type "chat" addressed to a full JID (localpart@domainpart/resourcepart), it delivers the &MESSAGE; according to <cite>RFC 6121</cite> § 8.5.3, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient.</p>
<p>Each forwarded copy is wrapped using &xep0297;. 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 &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;.</p>
<example caption='Juliet sends Romeo a directed message'><![CDATA[ <example caption='Juliet sends Romeo a directed message'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='juliet@example.com/balcony' from='juliet@capulet.example/balcony'
to='romeo@example.net/garden' to='romeo@montague.example/garden'
type='chat'> type='chat'>
<body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body> <body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message> </message>
]]></example> ]]></example>
<p>The copies sent to the Carbon-enabled resources are wrapped using &xep0297;. The wrapping message SHOULD maintain the same 'type' attribute value; the 'from' attribute MUST be the Carbon-enabled user's bare JID (e.g. "localpart@domain"); and the 'to' attribute SHOULD be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a &lt;received xmlns='urn:xmpp:carbons:2'/&gt; element, which itself contains a &lt;forwarded xmlns='urn:xmpp:forward:0'/&gt; that contains the original message (properly namespaced as "jabber:client"):</p>
<example caption='Server sends carbon to Romeo&apos;s other clients'><![CDATA[ <example caption='Server sends carbon to Romeo&apos;s other clients'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='romeo@example.net' from='romeo@montague.example'
to='romeo@example.net/home' to='romeo@montague.example/home'
type='chat'> type='chat'>
<received xmlns='urn:xmpp:carbons:2'> <received xmlns='urn:xmpp:carbons:2'>
<forwarded xmlns='urn:xmpp:forward:0'> <forwarded xmlns='urn:xmpp:forward:0'>
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='juliet@example.com/balcony' from='juliet@capulet.example/balcony'
to='romeo@example.net/garden' to='romeo@montague.example/garden'
type='chat'> type='chat'>
<body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body> <body>What man art thou that, thus bescreen'd in night, so stumblest on my counsel?</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
@ -297,32 +290,32 @@
</received> </received>
</message> </message>
]]></example> ]]></example>
</section2>
<section2 topic='Sending Messages' anchor='outbound'>
<p>Carbons clients want to have copies of messages going in <em>both</em> directions for other resources associated with the same user. To that end, messages of type "chat" that are sent from any resource MUST be copied by the sending server to each of the resources that have enabled Carbons, but are not the sending resource.</p>
<p>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.</p>
</section1>
<section1 topic='Sending Messages' anchor='outbound'>
<p>When a client sends a &MESSAGE; of type "chat", 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.</p>
<p>Each forwarded copy is wrapped using &xep0297;. 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 &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.</p>
<example caption='Romeo responds to Juliet'><![CDATA[ <example caption='Romeo responds to Juliet'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
to='juliet@example.com/balcony' from='romeo@montague.example/home'
from='romeo@example.net/home' to='juliet@capulet.example/balcony'
type='chat'> type='chat'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
</message>]]></example> </message>]]></example>
<p>The copies sent to the Carbon-enabled resources are wrapped using &xep0297;. The wrapping message SHOULD maintain the same 'type' attribute value; the 'from' attribute MUST be the Carbon-enabled user's bare JID (e.g. "localpart@domain"); and the 'to' attribute SHOULD be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a &lt;sent xmlns='urn:xmpp:carbons:2'/> element, which itself contains a &lt;forwarded xmlns='urn:xmpp:forward:0'/&gt; that contains the original message (properly namespaced as "jabber:client"):</p>
<example caption='Romeo&apos;s other Carbons-enabled clients <example caption='Romeo&apos;s other Carbons-enabled clients
receive a copy'><![CDATA[ receive a copy'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='romeo@example.net' from='romeo@montague.example'
to='romeo@example.net/garden' to='romeo@montague.example/garden'
type='chat'> type='chat'>
<sent xmlns='urn:xmpp:carbons:2'> <sent xmlns='urn:xmpp:carbons:2'>
<forwarded xmlns='urn:xmpp:forward:0'> <forwarded xmlns='urn:xmpp:forward:0'>
<message xmlns='jabber:client' <message xmlns='jabber:client'
to='juliet@example.com/balcony' to='juliet@capulet.example/balcony'
from='romeo@example.net/home' from='romeo@montague.example/home'
type='chat'> type='chat'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
@ -331,59 +324,64 @@
</sent> </sent>
</message>]]></example> </message>]]></example>
</section2> <p>The sending server SHOULD NOT send a forwarded copy to the sending full JID if it is a Carbons-enabled resource.</p>
<section2 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, 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:2" 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> </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, for example. To exclude a &MESSAGE; from being forwarded to other Carbons-enabled resources, the sending client add a &lt;private/&gt; element qualified by the namespace "urn:xmpp:carbons:2" as a child content element to the &MESSAGE; stanza.</p>
<p><strong>Note:</strong> use of the private mechanism will lead to partial conversations on other devices. This is the intended effect.</p> <p><strong>Note:</strong> use of the private mechanism might lead to partial conversations on other devices. This is the intended effect.</p>
<example caption='Romeo sends to Juliet, avoiding Carbon copies'><![CDATA[ <example caption='Romeo sends to Juliet, excluding Carbons'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
to='juliet@example.com' from='romeo@montague.example/home'
from='romeo@example.net/home' to='juliet@capulet.example/home'
type='chat'> type='chat'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
<private xmlns='urn:xmpp:carbons:2'/> <private xmlns='urn:xmpp:carbons:2'/>
</message>]]></example> </message>]]></example>
<example caption='Romeo&apos;s server removes the private tag before forwarding, and does NOT send carbon copies to Romeo&apos;s other resources'><![CDATA[ <example caption='Romeo&apos;s server delivers original message, without creating Carbon copies'><![CDATA[
<message xmlns='jabber:client' <message xmlns='jabber:client'
to='juliet@example.com' from='romeo@montague.example/home'
from='romeo@example.net/home' to='juliet@capulet.example/home'
type='chat'> type='chat'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread> <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
<private xmlns='urn:xmpp:carbons:2'/>
</message>]]></example> </message>]]></example>
</section2> <p>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 &lt;private/&gt; element before delivering to the recipient.</p>
<p><strong>Note:</strong> 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>
</section1> </section1>
<section1 topic='Business Rules' anchor='rules'> <section1 topic='Business Rules' anchor='bizrules'>
<section2 topic='Interaction with Chat States' anchor='chatstates'> <section2 topic='Handling Multiple Enable/Disalble Requests' anchor='bizrules-multi'>
<p>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.</p>
</section2>
<section2 topic='Interaction with Chat States' anchor='bizrules-chatstates'>
<p>Note that &xep0085; recommends sending chat state <p>Note that &xep0085; recommends sending chat state
notifications as chat type messages, which means that they will be notifications as chat type messages, which means that they will be
subject to Carbon-copying. This is intentional.</p> subject to Carbon-copying. This is intentional.</p>
<p>Additionally, clients that implement Carbons MAY take special use of chat state notifications:</p> <p>Additionally, there are other considerations for clients that implement Carbons and <cite>XEP-0085</cite>:</p>
<ul> <ul>
<li>Upon receiving an inbound or outbound <em>gone</em> chat state (as a carbon copy) for a given conversation, the client SHOULD visually indicate the conversation is terminated. It is suggested that the conversation be removed from user display as if the user on the copied client had terminated the conversation.</li> <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 <em>gone</em> chat states on logout, but instead SHOULD count on the unavailable presence to convey the change in attention.</li> <li>In order to prevent unwanted termination of conversations on other resources, clients SHOULD NOT send &lt;gone/&gt; chat states on logout, but instead 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 <em>gone</em>, 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> <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> </ul>
</section2> </section2>
<section2 topic='Handling of errors' anchor='errors'> <section2 topic='Handling of Errors' anchor='bizrules-errors'>
<p>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.</p> <p>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.</p>
<p>This rule is used to prevent some of the half-failure modes that have been an issue in other prototocols.</p> <p>This rule is used to prevent some of the half-failure modes that have been an issue in other prototocols.</p>
</section2> </section2>
<section2 topic='Auto-responses' anchor='auto-responses'> <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. Carbon copies of messages MUST NOT be auto-replied to under any circumstances. Forked inbound messages SHOULD 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> <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. 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.</p>
</section2> </section2>
<section2 topic='Mobile Considerations' anchor='mobile'> <section2 topic='Mobile Considerations' anchor='bizrules-mobile'>
<p>Since mobile devices often must pay for network traffic based on usage, the enablement of Carbons for such devices should be undertaken advisedly. More complicated mechanisms for controlling the Carbon-copying or forking of individual conversations may need to be added to deal with mobile clients in the future.</p> <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 or forking of individual conversations might need to be added to deal with mobile clients in the future.</p>
</section2> </section2>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <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. Any forwarded copies received by a Carbon-enabled client MUST be from that user's bare JID; any copies that do not meet this requirement MUST be ignored.</p> <p>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.</p>
<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> <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>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>