145
edits
Difference between revisions of "XMPP 2.0"
Jump to navigation
Jump to search
→Resource locking
| Line 35: | Line 35: | ||
=== Current situation === | === Current situation === | ||
[https:// | [https://xmpp.org/rfcs/rfc6121.html#message-chat RFC 6121, Section 5.1] and [https://xmpp.org/extensions/xep-0296.html XEP-0296] describe the process of resource locking for one-on-one chats. In essence, once a response is received from a peer resource, the following messages must be sent to that resource. | ||
The intent was that messages would always arrive at the device currently used by the conversation partner (since Message Carbons were not there), | 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 resource capabilities of the chat partner (i.e. [https://xmpp.org/extensions/xep-0308.html Last Message Correction]). 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 entirely. Instead, always send conversational content to the bare JID. | Eliminate resource locking in XMPP2 entirely. Instead, always send conversational content to the bare JID. Messages sent to the full JID in XMPP2 are specifically addressed to the resource and will not be carbon-copied. | ||
=== Migration path in a hypothetical XMPP 2.0 Session === | === Migration path in a hypothetical XMPP 2.0 Session === | ||
None. | None. | ||