145
edits
Difference between revisions of "XMPP 2.0"
Jump to navigation
Jump to search
→Proposed change: Better reflection of RFC6121
(→Proposed change: Better reflection of RFC6121) |
|||
| Line 17: | Line 17: | ||
To make things simpler, routing rules (for messages) could be re-defined to the following (differences to XMPP 1.0 are highlighted in bold): | 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 | ** 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) | ** 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 === | ||