88
edits
Difference between revisions of "XMPP 2.0"
Jump to navigation
Jump to search
→Proposed change: Highlight differences to XMPP 1.0
(→Proposed change: Highlight differences to XMPP 1.0) |
|||
| Line 15: | Line 15: | ||
=== 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 is addressed to a ''bare account JID'', it is delivered to '''all''' online resources of the JID. | ||
* If a message is addressed to a ''full JID'': | * If a message is addressed to a ''full JID'': | ||
** 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 applies)''' | ||
** 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 or 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-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-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, since it interferes with these rules. See below for considerations on resource locking. | ||