See the section Handling Multiple Enable/Disable Requests for considerations when a client attempts to disable Carbons multiple times.
- + + +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. 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. 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:
+Possible delivery rules: +
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.
+Note: 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.
+When the server receives a &MESSAGE; of type "chat" addressed to a bare JID (localpart@domainpart), it delivers a copy to each Carbons-enabled resource for the bare JID – in addition to delivering according to RFC 6121 § 8.5.2. This process is sometimes called "forking".
+When the server receives a &MESSAGE; eligible for carbons delivery addressed to a bare JID (localpart@domainpart), it first delivers it according to RFC 6121 § 8.5.2, and then delivers a copy to each Carbons-enabled resource for the bare JID that did not receive it due to the RFC 6121 delivery rules. This process is sometimes called "forking".
When the server receives a &MESSAGE; of type "chat" addressed to a full JID (localpart@domainpart/resourcepart), it delivers the &MESSAGE; according to RFC 6121 § 8.5.3, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient.
+When the server receives a &MESSAGE; eligible for carbons delivery addressed to a full JID (localpart@domainpart/resourcepart), it delivers the &MESSAGE; according to RFC 6121 § 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. Note that the RFC 6121 delivery rules can cause a &MESSAGE; addressed to a full JID to be delivered using bare JID delivery rules; in this case the server should also apply the bare JID rules for Carbons.
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 <received/> element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a <forwarded/> element qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE;.
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.
+The receiving server MUST NOT send a forwarded copy to the client(s) receiving full JID the original &MESSAGE; stanza was addressed to, as that recipient receives the original &MESSAGE; stanza.
When a client sends a &MESSAGE; of type "chat", its sending server delivers the &MESSAGE; according to RFC 6120 and RFC 6121, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID sender.
+When a client sends a &MESSAGE; eligible for carbons delivery, its sending server delivers the &MESSAGE; according to RFC 6120 and RFC 6121, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID sender. Note that this happens irrespective of whether the sending client has carbons enabled.
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 <sent/> element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a <forwarded/> qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE; stanza.
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.
+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. 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.
Note that &xep0085; recommends sending chat state