Difference between revisions of "XMPP 2.0"

Jump to navigation Jump to search
15 bytes added ,  10:37, 14 November 2017
 
(One intermediate revision by one other user not shown)
Line 11: Line 11:
The [https://xmpp.org/rfcs/rfc6121.html#rules-localpart-barejid routing rules for stanzas addressed to the bare JID as defined in RFC 6120] are blurry and don’t really match modern "always-online but not necessarily in the view of the user" multi-device use cases. This is why [https://xmpp.org/extensions/xep-0280.html Message Carbons (XEP-0280)] have been invented. They allow a device to tell the server that it wants to receive carbon-copies of all messages received by any resource of an account. This only affects typical chat-related <code>&lt;message/&gt;</code> stanzas (there are exceptions for certain message types; for presence, there is a well-defined broadcast-to-all-resources mechanism; and IQs can only be addressed to a single resource).
The [https://xmpp.org/rfcs/rfc6121.html#rules-localpart-barejid routing rules for stanzas addressed to the bare JID as defined in RFC 6120] are blurry and don’t really match modern "always-online but not necessarily in the view of the user" multi-device use cases. This is why [https://xmpp.org/extensions/xep-0280.html Message Carbons (XEP-0280)] have been invented. They allow a device to tell the server that it wants to receive carbon-copies of all messages received by any resource of an account. This only affects typical chat-related <code>&lt;message/&gt;</code> stanzas (there are exceptions for certain message types; for presence, there is a well-defined broadcast-to-all-resources mechanism; and IQs can only be addressed to a single resource).


However, throughout the history of XMPP, there have been XEPs which use messages to send data which is really only of interest for a single resource. Prime examples are [https://xmpp.org/extensions/xep-0047.html In-Band Bytestreams (XEP-0047)], privacy enhancing protocols such as the (in)famous OTR and (private messages from) [https://xmpp.org/extensions/xep-0045.html Multi-User Chat (XEP-0045)]. This led to Message Carbon rules being hand-wavy and blurry, some of the behaviour being implementation-defined, depending on co-operating clients which do not speak Message Carbons themselves and other unfortunaties.
However, throughout the history of XMPP, there have been XEPs which use messages to send data which is really only of interest for a single resource. Prime examples are [https://xmpp.org/extensions/xep-0047.html In-Band Bytestreams (XEP-0047)], privacy enhancing protocols such as the (in)famous OTR and (private messages from) [https://xmpp.org/extensions/xep-0045.html Multi-User Chat (XEP-0045)]. This led to Message Carbon rules being hand-wavy and blurry, some of the behaviour being implementation-defined, depending on co-operating clients which do not speak Message Carbons themselves and other unfortunate compromises.


=== Proposed change ===
=== Proposed change ===
Line 43: Line 43:
* A stanza with a <code>&lt;xmpp-2/&gt;</code> tag MUST be processed as if it came from an XMPP 2.0 node. Any XMPP 1.0 Routing Modifiers MUST be stripped.
* A stanza with a <code>&lt;xmpp-2/&gt;</code> tag MUST be processed as if it came from an XMPP 2.0 node. Any XMPP 1.0 Routing Modifiers MUST be stripped.
* A message to a ''bare JID'' must be delivered to all online clients (this is allowed by RFC 6120 already).
* A message to a ''bare JID'' must be delivered to all online clients (this is allowed by RFC 6120 already).
* A message to a ''full JID'' with <code>&lt;private/&gt;</code> or <code>&lt;no-copy/&gt;</code> is delivered to the targeted full JID (this matches current Carbons behavior).
* A message to a ''full JID'' with <code>&lt;private/&gt;</code> or <code>&lt;no-copy/&gt;</code> is delivered only to the targeted full JID (this matches current Carbons behavior).
* For a message to a ''full JID'' with no XMPP 1.0 Routing Modifier, a set of rules similar to Carbon copying needs to be applied, to determine if the message must be rerouted to the bare JID:
* For a message to a ''full JID'' with no XMPP 1.0 Routing Modifier, a set of rules similar to Carbon copying needs to be applied, to determine if the message must be rerouted to the bare JID:
** type=normal - needs to detect body presence / special use cases
** type=normal - needs to detect body presence / special use cases
181

edits

Navigation menu