mirror of https://github.com/moparisthebest/xeps
0.2
This commit is contained in:
stpeter
parent
bfab91b9cc
commit
7d4f99b5a6
357
xep-0280.xml
357
xep-0280.xml
|
|
@ -10,7 +10,7 @@
|
||||||
<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>
|
<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;
|
&LEGALNOTICE;
|
||||||
<number>0280</number>
|
<number>0280</number>
|
||||||
<status>Deferred</status>
|
<status>Experimental</status>
|
||||||
<type>Standards Track</type>
|
<type>Standards Track</type>
|
||||||
<sig>Standards</sig>
|
<sig>Standards</sig>
|
||||||
<approver>Council</approver>
|
<approver>Council</approver>
|
||||||
|
|
@ -19,6 +19,7 @@
|
||||||
<spec>XEP-0001</spec>
|
<spec>XEP-0001</spec>
|
||||||
<spec>XEP-0030</spec>
|
<spec>XEP-0030</spec>
|
||||||
<spec>XEP-0085</spec>
|
<spec>XEP-0085</spec>
|
||||||
|
<spec>XEP-0296</spec>
|
||||||
</dependencies>
|
</dependencies>
|
||||||
<supersedes>
|
<supersedes>
|
||||||
<spec>XEP-0259</spec>
|
<spec>XEP-0259</spec>
|
||||||
|
|
@ -31,6 +32,18 @@
|
||||||
<email>jhildebr@cisco.com</email>
|
<email>jhildebr@cisco.com</email>
|
||||||
<jid>jhildebr@cisco.com</jid>
|
<jid>jhildebr@cisco.com</jid>
|
||||||
</author>
|
</author>
|
||||||
|
<author>
|
||||||
|
<firstname>Matthew</firstname>
|
||||||
|
<surname>Miller</surname>
|
||||||
|
<email>linuxwolf@outer-planes.net</email>
|
||||||
|
<jid>linuxwolf@outer-planes.net</jid>
|
||||||
|
</author>
|
||||||
|
<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>
|
<revision>
|
||||||
<version>0.1</version>
|
<version>0.1</version>
|
||||||
<date>2010-05-03</date>
|
<date>2010-05-03</date>
|
||||||
|
|
@ -51,23 +64,10 @@
|
||||||
</revision>
|
</revision>
|
||||||
</header>
|
</header>
|
||||||
<section1 topic='Introduction' anchor='intro'>
|
<section1 topic='Introduction' anchor='intro'>
|
||||||
<p>At the time of original writing of this XEP, many XMPP servers
|
<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
|
||||||
handle message stanzas sent to a user@host (or "bare") JID with no
|
switches devices, parts of the conversation may end up on the alternate device, causing the user to be confused, misled, or annoyed.</p>
|
||||||
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
|
<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>
|
||||||
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>
|
||||||
|
|
||||||
<section1 topic='Requirements' anchor='reqs'>
|
<section1 topic='Requirements' anchor='reqs'>
|
||||||
|
|
@ -89,74 +89,65 @@
|
||||||
</section1>
|
</section1>
|
||||||
<section1 topic='Use Cases' anchor='usecases'>
|
<section1 topic='Use Cases' anchor='usecases'>
|
||||||
<section2 topic='Discovering Support' anchor='disco'>
|
<section2 topic='Discovering Support' anchor='disco'>
|
||||||
<p>If a server implements the Message Carbons capability, it MUST specify the
|
<p>If a server implements the Message Carbons capability, it MUST specify the "urn:xmpp:carbons:1" 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>
|
||||||
'urn:xmpp:carbons:0' feature in its service discovery
|
|
||||||
information features as specified in &xep0030; or section 6.3 of &xep0115;.
|
|
||||||
Clients MUST NOT 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 type='get'
|
<iq xmlns='jabber:client'
|
||||||
|
type='get'
|
||||||
from='romeo@montague.net/orchard'
|
from='romeo@montague.net/orchard'
|
||||||
id='info1'>
|
id='info1'>
|
||||||
<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 type='get'
|
<iq xmlns='jabber:client'
|
||||||
|
type='get'
|
||||||
to='romeo@montague.net/home'
|
to='romeo@montague.net/home'
|
||||||
from='montague.net'
|
from='montague.net'
|
||||||
id='info1'>
|
id='info1'>
|
||||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||||
...
|
...
|
||||||
<feature var='urn:xmpp:carbons:0'/>
|
<feature var='urn:xmpp:carbons:1'/>
|
||||||
...
|
...
|
||||||
</query>
|
</query>
|
||||||
</iq>]]></example>
|
</iq>]]></example>
|
||||||
</section2>
|
</section2>
|
||||||
|
|
||||||
<section2 topic='Enabling Carbons' anchor='enabling'>
|
<section2 topic='Enabling Carbons' anchor='enabling'>
|
||||||
<p>Servers MUST NOT enable the Carbons protocol for a client by
|
<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>
|
||||||
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>
|
|
||||||
<example caption='Client enables Carbons'><![CDATA[
|
<example caption='Client enables Carbons'><![CDATA[
|
||||||
<iq type='set' id='enable1'>
|
<iq xmlns='jabber:client'
|
||||||
<carbons var='urn:xmpp:carbons:0' mode='enable'/>
|
type='set'
|
||||||
|
id='enable1'>
|
||||||
|
<enable var='urn:xmpp:carbons:1'/>
|
||||||
</iq>]]></example>
|
</iq>]]></example>
|
||||||
<p>Carbons will generally be enabled before the client sends the
|
<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>
|
||||||
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>
|
|
||||||
<example caption='Server acknowledges Carbons enablement'><![CDATA[
|
<example caption='Server acknowledges Carbons enablement'><![CDATA[
|
||||||
<iq type='result' id='enable1'/>]]></example>
|
<iq xmlns='jabber:client'
|
||||||
|
type='result'
|
||||||
|
id='enable1'/>]]></example>
|
||||||
</section2>
|
</section2>
|
||||||
|
|
||||||
<section2 topic='Disabling Carbons' anchor='disabling'>
|
<section2 topic='Disabling Carbons' anchor='disabling'>
|
||||||
<p>Some clients might want to disable Carbons. An example of this
|
<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>
|
||||||
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[
|
<example caption='Client disables Carbons'><![CDATA[
|
||||||
<iq type='set' id='disable1'>
|
<iq xmlns='jabber:client'
|
||||||
<carbons var='urn:xmpp:carbons:0' mode='disable'/>
|
type='set'
|
||||||
|
id='disable1'>
|
||||||
|
<disable var='urn:xmpp:carbons:1'/>
|
||||||
</iq>]]></example>
|
</iq>]]></example>
|
||||||
<p>The server will respond with an IQ result when Carbons are disabled:</p>
|
<p>The server will respond with an IQ result when Carbons are disabled:</p>
|
||||||
<example caption='Server acknowledges Carbons enablement'><![CDATA[
|
<example caption='Server acknowledges Carbons enablement'><![CDATA[
|
||||||
<iq type='result' id='disable1'/>]]></example>
|
<iq xmlns='jabber:client'
|
||||||
|
type='result'
|
||||||
|
id='disable1'/>]]></example>
|
||||||
</section2>
|
</section2>
|
||||||
|
|
||||||
<section2 topic='Error Cases' anchor='errors'>
|
<section2 topic='Error Cases' anchor='errors'>
|
||||||
<p>Enabling or disabling Carbons may fail in the several ways. If
|
<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>
|
||||||
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'>
|
<section3 topic='bad-request' anchor='bad-request'>
|
||||||
<p>The sender has sent a stanza containing XML that does not
|
<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>
|
||||||
conform to the appropriate schema or that cannot be processed.
|
<example caption='Error: bad-request'><![CDATA[
|
||||||
One example is an IQ stanza that includes an unrecognized value
|
<iq xmlns='jabber:client'
|
||||||
of the 'type' attribute. Another is changing to the state that
|
id='enable1'
|
||||||
is already in effect (enabling Carbons a second time).</p>
|
|
||||||
<example caption='Error: bad-request'><![CDATA[<iq id='enable1'
|
|
||||||
type='error'>
|
type='error'>
|
||||||
<error type='modify'>
|
<error type='modify'>
|
||||||
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||||
|
|
@ -168,7 +159,9 @@
|
||||||
that does not support the protocol. This SHOULD NOT happen in
|
that does not support the protocol. This SHOULD NOT happen in
|
||||||
practice, because clients MUST check for server support before
|
practice, because clients MUST check for server support before
|
||||||
sending their request.</p>
|
sending their request.</p>
|
||||||
<example caption='Error: feature-not-implemented'><![CDATA[<iq id='enable1'
|
<example caption='Error: feature-not-implemented'><![CDATA[
|
||||||
|
<iq xmlns='jabber:client'
|
||||||
|
id='enable1'
|
||||||
type='error'>
|
type='error'>
|
||||||
<error type='cancel'>
|
<error type='cancel'>
|
||||||
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||||
|
|
@ -178,7 +171,9 @@
|
||||||
<section3 topic='forbidden' anchor='forbidden'>
|
<section3 topic='forbidden' anchor='forbidden'>
|
||||||
<p>The sender does is forbidden by policy from enabling or
|
<p>The sender does is forbidden by policy from enabling or
|
||||||
disabling Carbons.</p>
|
disabling Carbons.</p>
|
||||||
<example caption='Error: forbidden'><![CDATA[<iq id='enable1'
|
<example caption='Error: forbidden'><![CDATA[
|
||||||
|
<iq xmlns='jabber:client'
|
||||||
|
id='enable1'
|
||||||
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'/>
|
||||||
|
|
@ -190,7 +185,9 @@
|
||||||
This might occur in a multi-domain deployment, where
|
This might occur in a multi-domain deployment, where
|
||||||
administrators of one domain allow Carbons, but another does
|
administrators of one domain allow Carbons, but another does
|
||||||
not.</p>
|
not.</p>
|
||||||
<example caption='Error: not-allowed'><![CDATA[<iq id='enable1'
|
<example caption='Error: not-allowed'><![CDATA[
|
||||||
|
<iq xmlns='jabber:client'
|
||||||
|
id='enable1'
|
||||||
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'/>
|
||||||
|
|
@ -198,21 +195,14 @@
|
||||||
</iq>]]></example>
|
</iq>]]></example>
|
||||||
</section3>
|
</section3>
|
||||||
</section2>
|
</section2>
|
||||||
|
<section2 topic='Receiving Messages' anchor='inbound'>
|
||||||
<section2 topic='Inbound Messages' anchor='inbound'>
|
<p>Messages of type chat that are addressed to the bare JID (localpart@domain) MUST be copied by the receiving server to all of the resources for that user that have non-negative presence priority and have not filtered messages through some other means. The process of making copies is known as "forking."</p>
|
||||||
<p>Messages of type chat that are addressed to the bare JID
|
|
||||||
(localpart@domain) MUST be copied by the receiving server to all of the
|
|
||||||
resources for that user that have non-negative presence priority
|
|
||||||
and have not filtered messages through some other means. The
|
|
||||||
process of making copies is known as "forking." The receiving
|
|
||||||
server SHOULD NOT modify the 'to' address of the forked
|
|
||||||
messages.</p>
|
|
||||||
|
|
||||||
<example caption='Juliet sends Romeo an undirected message, which is forked'><![CDATA[
|
<example caption='Juliet sends Romeo an undirected message, which is forked'><![CDATA[
|
||||||
<message
|
<message xmlns='jabber:client'
|
||||||
from='juliet@example.com/balcony'
|
from='juliet@example.com/balcony'
|
||||||
to='romeo@example.net'
|
to='romeo@example.net'
|
||||||
type='chat'>
|
type='chat'>
|
||||||
<body>Wherefore art thou, Romeo?</body>
|
<body>Wherefore art thou, Romeo?</body>
|
||||||
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
|
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
|
||||||
</message>
|
</message>
|
||||||
|
|
@ -220,99 +210,90 @@
|
||||||
... each of romeo@example.net's resources receives this stanza verbatim
|
... each of romeo@example.net's resources receives this stanza verbatim
|
||||||
]]></example>
|
]]></example>
|
||||||
|
|
||||||
<p>Messages of type "chat" that are addressed to a full JID
|
<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, and MUST also be sent to all of the Carbons-enabled resources for the receiving user. The goal of the copies to Carbons-enabled resources is to allow those clients to have both halves of <strong>*all*</strong> IM conversations, including messages that are sent from clients that lock in to particular resources.</p>
|
||||||
(localpart@domain/resource) MUST be sent by the receiving server to the
|
|
||||||
addressed resource, and MUST also be sent to all of the
|
<p>The copies sent to the Carbon-enabled resources are wrapped using &xep0297;. The wrapping message SHOULD maintain the same 'type', 'from', and 'id' attribute values (if any), while the 'to' attribute SHOULD be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a <forwarded xmlns='urn:xmpp:forward:0'/> which contains the original message (properly namespaced as "jabber:client") and a <received xmlns='urn:xmpp:carbons:1'/> element:</p>
|
||||||
Carbons-enabled resources for the receiving user. The goal of
|
<example caption='Juliet sends Romeo a directed message'><![CDATA[
|
||||||
the copies to Carbons-enabled resources is to allow those clients
|
<message xmlns='jabber:client'
|
||||||
to have both halves of *all* IM conversations, including messages
|
from='juliet@example.com/balcony'
|
||||||
that are sent from clients that lock in to particular resources.</p>
|
to='romeo@example.net/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's other clients'><![CDATA[
|
||||||
|
<message xmlns='jabber:client'
|
||||||
|
from='juliet@example.com/balcony'
|
||||||
|
to='romeo@example.net/home'
|
||||||
|
type='chat'>
|
||||||
|
<forwarded xmlns='urn:xmpp:forward:0'>
|
||||||
|
<received xmlns='urn:xmpp:carbons:1'/>
|
||||||
|
<message xmlns='jabber:client'
|
||||||
|
from='juliet@example.com/balcony'
|
||||||
|
to='romeo@example.net/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>
|
||||||
|
</message>
|
||||||
|
]]></example>
|
||||||
</section2>
|
</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 copies sent to the Carbon-enabled resources are wrapped using Message Forwarding. The wrapping message SHOULD maintain the same 'type', 'from', and 'id' attribute values, while the 'to' attribute SHOULD be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a <forwarded xmlns='urn:xmpp:forward:0'/> which contains the original message (properly namespaced as "jabber:client") and a <sent xmlns='urn:xmpp:carbons:1'/> element:</p>
|
||||||
|
|
||||||
<section2 topic='Sending Messages' anchor='sending'>
|
<example caption='Romeo responds to Juliet'><![CDATA[
|
||||||
<p>Once most of the clients that are deployed have implemented
|
<message xmlns='jabber:client'
|
||||||
Carbons, clients MAY choose to always send chat type messages to
|
to='juliet@example.com/balcony'
|
||||||
the bare JID. Until then, traditional resource locking is
|
from='romeo@example.net/home'
|
||||||
RECOMMENDED. (Note: another XEP might be written to document
|
type='chat'>
|
||||||
traditional resource locking, if the documentation in &xmppim;
|
|
||||||
is not sufficient.)</p>
|
|
||||||
|
|
||||||
<p>Also note that &xep0085; recommends sending chat state
|
|
||||||
notifications as chat type messages, which means that they will be
|
|
||||||
subject to Carbon-copying. This is intentional.</p>
|
|
||||||
</section2>
|
|
||||||
|
|
||||||
<section2 topic='Outbound Message Carbon Copies' 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. Note that the 'to' address will be the original target of
|
|
||||||
the message (bare JID, as above), and the 'from' address will
|
|
||||||
contain the full JID (localpart@domain/resource) of the sending
|
|
||||||
resource. The 'to' address not matching the JID of the session is
|
|
||||||
somewhat unprecedented in XMPP, which is why Carbons must be
|
|
||||||
explicitly enabled.</p>
|
|
||||||
|
|
||||||
<p>Messages that have carbon copies sent back to Carbons-enabled
|
|
||||||
resources MUST NOT be copied back to the originating client. The
|
|
||||||
copies MUST have the full JID (localpart@domain/resource) of the sender
|
|
||||||
as the 'from' address. The copies MUST include a sent element in
|
|
||||||
the urn:xmpp:carbons:0 namespace.</p>
|
|
||||||
|
|
||||||
<example caption='Romeo responds to Juliet, which is Carboned'><![CDATA[
|
|
||||||
<message
|
|
||||||
to='juliet@example.com/balcony'
|
|
||||||
from='romeo@example.net/home'
|
|
||||||
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>
|
||||||
|
|
||||||
<example caption='Romeo's OTHER Carbons-enabled clients
|
<example caption='Romeo's other Carbons-enabled clients
|
||||||
receive a copy'><![CDATA[
|
receive a copy'><![CDATA[
|
||||||
<message
|
<message xmlns='jabber:client'
|
||||||
to='juliet@example.com/balcony'
|
from='romeo@example.net/home'
|
||||||
from='romeo@example.net/home'
|
to='romeo@example.net/garden'
|
||||||
type='chat'>
|
type='chat'>
|
||||||
<body>Neither, fair saint, if either thee dislike.</body>
|
<forwarded xmlns='urn:xmpp:forward:0'>
|
||||||
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
|
<sent xmlns='urn:xmpp:carbons:1'/>
|
||||||
<sent xmlns='urn:xmpp:carbons:0'/>
|
<message xmlns='jabber:client'
|
||||||
|
to='juliet@example.com/balcony'
|
||||||
|
from='romeo@example.net/home'
|
||||||
|
type='chat'>
|
||||||
|
<body>Neither, fair saint, if either thee dislike.</body>
|
||||||
|
<thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
|
||||||
|
</message>
|
||||||
</message>]]></example>
|
</message>]]></example>
|
||||||
|
|
||||||
</section2>
|
</section2>
|
||||||
|
|
||||||
<section2 topic='Avoiding Carbons for a single message' anchor='avoiding'>
|
<section2 topic='Avoiding Carbons for a single message' anchor='avoiding'>
|
||||||
<p>Some clients might want to avoid carbons on a single message,
|
<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>
|
||||||
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,
|
<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:1" 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>
|
||||||
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
|
<p><strong>Note:</strong> use of the private mechanism will lead to partial conversations on other devices. This is the intended effect.</p>
|
||||||
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, avoiding Carbon copies'><![CDATA[
|
||||||
<message
|
<message xmlns='jabber:client'
|
||||||
to='juliet@example.com'
|
to='juliet@example.com'
|
||||||
from='romeo@example.net/home'
|
from='romeo@example.net/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:0'/>
|
<private xmlns='urn:xmpp:carbons:1'/>
|
||||||
</message>]]></example>
|
</message>]]></example>
|
||||||
|
|
||||||
<example caption='Romeo's server removes the private tag before forwarding, and does NOT send carbon copies to Romeo's other resources'><![CDATA[
|
<example caption='Romeo's server removes the private tag before forwarding, and does NOT send carbon copies to Romeo's other resources'><![CDATA[
|
||||||
<message
|
<message xmlns='jabber:client'
|
||||||
to='juliet@example.com'
|
to='juliet@example.com'
|
||||||
from='romeo@example.net/home'
|
from='romeo@example.net/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>
|
||||||
</message>]]></example>
|
</message>]]></example>
|
||||||
|
|
@ -320,56 +301,29 @@
|
||||||
</section1>
|
</section1>
|
||||||
<section1 topic='Business Rules' anchor='rules'>
|
<section1 topic='Business Rules' anchor='rules'>
|
||||||
<section2 topic='Interaction with Chat States' anchor='chatstates'>
|
<section2 topic='Interaction with Chat States' anchor='chatstates'>
|
||||||
<p>Clients that implement Carbons MAY take special use of
|
<p>Note that &xep0085; recommends sending chat state
|
||||||
&xep0085; notifications.</p>
|
notifications as chat type messages, which means that they will be
|
||||||
<p>It is RECOMMENDED that upon receiving an outbound <em>gone</em>
|
subject to Carbon-copying. This is intentional.</p>
|
||||||
chat state (as a carbon copy) for a given conversation, that
|
<p>Additionally, clients that implement Carbons MAY take special use of chat state notifications:</p>
|
||||||
conversation be removed from user display as if the user on the
|
<ul>
|
||||||
copied client had terminated the conversation. In order to
|
<li>Upon receiving an inbound or outbound <em>gone</em> chat state (as a carbon copy) for a given conversation, that conversation SHOULD 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 instead SHOULD count on the unavailable presence to convey the change in attention.</li>
|
||||||
prevent unwanted termination of conversations on other resources,
|
<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>
|
||||||
clients SHOULD NOT send <em>gone</em> chat states on logout, but
|
</ul>
|
||||||
instead SHOULD count on the unavailable presence to convey the change
|
|
||||||
in attention.</p>
|
|
||||||
<p>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 muted on non-primary devices.</p>
|
|
||||||
</section2>
|
</section2>
|
||||||
<section2 topic='Handling of errors' anchor='errors'>
|
<section2 topic='Handling of errors' anchor='errors'>
|
||||||
<p>When a receiving server attempts to deliver a forked message,
|
<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>
|
||||||
and that message bounces with an error for any reason, the
|
<p>This rule is used to prevent some of the half-failure modes that have been an issue in other prototocols.</p>
|
||||||
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>
|
|
||||||
</section2>
|
</section2>
|
||||||
<section2 topic='Auto-responses' anchor='auto-responses'>
|
<section2 topic='Auto-responses' anchor='auto-responses'>
|
||||||
<p>Clients that automatically respond to messages for any reason
|
<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>
|
||||||
(e.g. when in DND presence state) MUST take adequate care when
|
|
||||||
enabling Carbons in order to prevent storms or loops. Carbon
|
|
||||||
copies of outbound 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 knowing that the receiver
|
|
||||||
will not receive more than one auto-reply from other similar
|
|
||||||
clients for the same user.</p>
|
|
||||||
</section2>
|
</section2>
|
||||||
<section2 topic='Mobile Considerations' anchor='mobile'>
|
<section2 topic='Mobile Considerations' anchor='mobile'>
|
||||||
<p>Since mobile devices often must pay for network traffic based
|
<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>
|
||||||
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>
|
|
||||||
</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
|
<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>
|
||||||
resources for a single user are in the same trust boundary.</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 <private/> 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
|
|
||||||
private element specified above to avoid such copying, unless the
|
|
||||||
encryption mechanism is adjusted to have knowledge of Carbons.</p>
|
|
||||||
</section1>
|
</section1>
|
||||||
<section1 topic='IANA Considerations' anchor='iana'>
|
<section1 topic='IANA Considerations' anchor='iana'>
|
||||||
<p>This document requires no interaction with &IANA;.</p>
|
<p>This document requires no interaction with &IANA;.</p>
|
||||||
|
|
@ -378,7 +332,7 @@
|
||||||
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||||||
<p>This specification defines the following XML namespace:</p>
|
<p>This specification defines the following XML namespace:</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li>urn:xmpp:carbons:0</li>
|
<li>urn:xmpp:carbons:1</li>
|
||||||
</ul>
|
</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>
|
<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>
|
||||||
</section2>
|
</section2>
|
||||||
|
|
@ -392,31 +346,20 @@
|
||||||
|
|
||||||
<xs:schema
|
<xs:schema
|
||||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||||
targetNamespace='urn:xmpp:carbons:0'
|
targetNamespace='urn:xmpp:carbons:1'
|
||||||
xmlns='urn:xmpp:carbons:0'
|
xmlns='urn:xmpp:carbons:1'
|
||||||
elementFormDefault='qualified'>
|
elementFormDefault='qualified'>
|
||||||
|
|
||||||
<xs:element name='carbons'>
|
<xs:element name='disable' type='empty'/>
|
||||||
<xs:complexType>
|
|
||||||
<xs:simpleContent>
|
<xs:element name='enable' type='empty'/>
|
||||||
<xs:extension base='empty'>
|
|
||||||
<xs:attribute name='mode' use='required'>
|
|
||||||
<xs:simpleType>
|
|
||||||
<xs:restriction base="xs:string">
|
|
||||||
<xs:enumeration value="enable"/>
|
|
||||||
<xs:enumeration value="disable"/>
|
|
||||||
</xs:restriction>
|
|
||||||
</xs:simpleType>
|
|
||||||
</xs:attribute>
|
|
||||||
</xs:extension>
|
|
||||||
</xs:simpleContent>
|
|
||||||
</xs:complexType>
|
|
||||||
</xs:element>
|
|
||||||
|
|
||||||
<xs:element name='sent' type='empty'/>
|
|
||||||
|
|
||||||
<xs:element name='private' type='empty'/>
|
<xs:element name='private' type='empty'/>
|
||||||
|
|
||||||
|
<xs:element name='received' type='empty'/>
|
||||||
|
|
||||||
|
<xs:element name='sent' type='empty'/>
|
||||||
|
|
||||||
<xs:simpleType name='empty'>
|
<xs:simpleType name='empty'>
|
||||||
<xs:restriction base='xs:string'>
|
<xs:restriction base='xs:string'>
|
||||||
<xs:enumeration value=''/>
|
<xs:enumeration value=''/>
|
||||||
|
|
@ -427,6 +370,6 @@
|
||||||
]]></code>
|
]]></code>
|
||||||
</section1>
|
</section1>
|
||||||
<section1 topic='Acknowledgements' anchor='ack'>
|
<section1 topic='Acknowledgements' anchor='ack'>
|
||||||
<p>The author wishes to thank Patrick Barry, Teh Chang, Jack Erwin, Craig Kaes, Kathleen McMurry, Matt Miller, Tory Patnoe, Peter Saint-Andre, and Ben Schumacher for their feedback.</p>
|
<p>The authors wish to thank Patrick Barry, Teh Chang, Jack Erwin, Craig Kaes, Kathleen McMurry, Tory Patnoe, Peter Saint-Andre, and Ben Schumacher for their feedback.</p>
|
||||||
</section1>
|
</section1>
|
||||||
</xep>
|
</xep>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue