181
edits
(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><message/></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><message/></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 | 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><xmpp-2/></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><xmpp-2/></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><private/></code> or <code><no-copy/></code> is delivered to the targeted full JID (this matches current Carbons behavior). | * A message to a ''full JID'' with <code><private/></code> or <code><no-copy/></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 |
edits