181
edits
(20 intermediate revisions by 2 users not shown) | |||
Line 9: | Line 9: | ||
=== Current situation === | === Current situation === | ||
The routing rules for stanzas addressed to the bare JID in | 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 === | ||
To make things simpler, routing rules (for messages) could be re-defined to the following: | To make things simpler, routing rules (for messages) could be re-defined to the following (differences to XMPP 1.0 are highlighted in bold): | ||
* If a message is addressed to a ''bare account JID'', it is delivered to all online resources of the JID. | * If a message (of type "normal", "chat" or "headline") is addressed to a ''bare account JID'', it is delivered to '''all''' online resources of the JID (this is one of the allowed options in [https://xmpp.org/rfcs/rfc6121.html#rules-localpart-barejid-resource RFC6121 §8.5.2.1.1], modulo negative resource priorities). | ||
* If a message is addressed to a ''full JID'': | * If a message is addressed to a ''full JID'', the normal [https://xmpp.org/rfcs/rfc6121.html#rules-localpart-fulljid RFC6121] rules are applied: | ||
** if an online resource exists at that full JID, the message is delivered to that resource | ** if an online resource exists at that full JID, the message is delivered to that resource, and to that resource only ('''no message carbon copying is performed''') | ||
** if no online resource exists, an error is returned (NOTE: privacy implications and possible resource scanning need to be thought through) | ** if no online resource exists, an error is returned and the message is not delievered to any resource nor stored (NOTE: privacy implications and possible resource scanning need to be thought through) | ||
** these ''full JID'' messages are ''transient'', '''they are never stored in an archive'''. This affects OTR (which had to use private/no-archive before), MUC messages/PMs (which are client-specific anyway and should be rather persisted by MUC MAM), IBB messages (works as desgined) | |||
In addition, resource locking as described in RFC 6121 would be discouraged and deprecated, since it interferes with these rules. See below for considerations on resource locking. | In addition, resource locking as described in RFC 6121 would be discouraged and deprecated for chat messages, since it interferes with these rules. See below for considerations on resource locking. | ||
=== Migration path in a hypothetical XMPP 2.0 Session === | === Migration path in a hypothetical XMPP 2.0 Session === | ||
Since routing rules are changed, a definition of what happens to stanzas which transition between XMPP 2.0 and XMPP 1.0 nodes is needed. These rules would normally be implemented by servers. Client libraries which support both XMPP 2.0 and XMPP 1.0 could apply those rules when talking to an XMPP 1.0 server. Relevant definitions: | |||
* | ;XMPP 1.0 Routing Modifiers | ||
:XML elements which modify routing behaviour in XMPP 1.0: | |||
:* <code><private/></code> ([https://xmpp.org/extensions/xep-0280.html Message Carbons]) | |||
:* <code><no-copy/></code> ([https://xmpp.org/extensions/xep-0334.html Message Processing Hints]) | |||
Rules for stanzas leaving the XMPP 2.0 realm (to an XMPP 1.0 node): | |||
* If a message is addressed to a ''full JID'', an XMPP 1.0 Routing Modifier to prevent carbon copying and a <code><no-archive/></code> ''transient'' tag MUST be injected. | |||
* The stanza MUST be marked with a to-be-defined <code><xmpp-2/></code> tag so that XMPP 2.0 nodes further downstream can recognize that the XMPP 2.0 routing semantics shall apply. | |||
Rules for stanzas entering the XMPP 2.0 realm (from an XMPP 1.0 node): | |||
* 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 ''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: | |||
** type=normal - needs to detect body presence / special use cases | |||
** type=chat - reroute to bare JID, deliver to all clients (alternatively: deliver Carbons); store in archive | |||
** type=groupchat - treat as ''transient'', deliver to single resource | |||
** type=headline - treat as ''transient'', deliver to single resource | |||
* The stanza MUST be marked with a to-be-defined <code><xmpp-1/></code> tag so that XMPP 2.0 nodes further downstream can recognize that the XMPP 1.0 routing semantics shall apply. | |||
== Resource locking == | == Resource locking == | ||
Line 39: | Line 59: | ||
The intent was that messages would always arrive at the device currently used by the conversation partner (since Message Carbons were not there), because the routing rules for message stanzas did not enforce that behaviour. | The intent was that messages would always arrive at the device currently used by the conversation partner (since Message Carbons were not there), because the routing rules for message stanzas did not enforce that behaviour. | ||
Furthermore the features offered to a user are limited based on the | Furthermore, the features offered to a user are often limited by clients based on the capabilities (e.g. [https://xmpp.org/extensions/xep-0308.html Last Message Correction]) of the locked-to resource. This introduces race conditions and incompatibility when the chat partner switches devices or reads up the conversation from an offline storage / archive. | ||
=== Proposed change === | === Proposed change === | ||
Eliminate resource locking in | Eliminate resource locking in XMPP 2.0 entirely. Instead, always send conversational content to the bare JID. Messages sent to the full JID in XMPP 2.0 are specifically addressed to the resource and will not be carbon-copied, as described in the previous section. | ||
It needs to be evaluated whether a limited resource locking mechanism is needed to appropriately route IQs, and which IQs are actually meant for the chat partner's account vs. a specific device. | |||
=== Migration path in a hypothetical XMPP 2.0 Session === | === Migration path in a hypothetical XMPP 2.0 Session === | ||
None. | None needed. Chat conversations work fine without any resource locking today. | ||
== Client Session Setup == | |||
=== Current situation === | |||
A client that (re)connects to its server needs to perform these steps: | |||
# Authenticate (actually: establish an XML stream, convert to TLS, establish a new XML stream, perform SCRAM or some other multi-step auth mechanism) | |||
# Attempt [https://xmpp.org/extensions/xep-0198.html#resumption Stream Resumption]. On success the connection is established, on failure the client needs to continue: | |||
# bind a new session | |||
# Enable Carbons | |||
# Send initial presence | |||
# Obtain offline messages | |||
# (optionally) query the MAM archive and deduplicate with offline messages | |||
# Join MUCs | |||
There is a race condition between enabling Carbons and synchronizing MAM, and the number of steps and round-trips is tremendous. | |||
=== XMPP 2.0 Session Initiation === | |||
The client and server must coordinate the required information for a sync as soon as possible: | |||
# Authenticate | |||
# Client sends a bind2 request containing: | |||
#* stream resumption id (optional, to faciliate Stream Resumption) | |||
#* last-known MAM message-id (optional, to achieve full synchronization) | |||
#* MAM request with a time-delta (optional, alternative to message-id if only the history of the last N time units is needed) | |||
#* initial presence (maybe?) | |||
#* MUCs to join (maybe?) | |||
# The server automagically figures out whether to do a stream resumption or a MAM sync and provides according data to the client, generates presence broadcast accordingly | |||
The new session automatically feeds the client all stanzas directed at the client's bare JID, resource, and Carbons of sent messages from other resources. This is a change of routing rules in comparison to core rules and Carbons, and it sends all "persistent" messages to the client. | |||
= TODO = | |||
* The MAM subscription thing? | |||
* Sent carbons | |||
* clarify routing rules with respect to message type | |||
* are there protocols between clients mixing messages and IQs? are they affected in any way by the routing rules? |
edits