145
edits
Difference between revisions of "XMPP 2.0"
Jump to navigation
Jump to search
m
→Proposed change
m (→TODO: two notes to think about, mentioned by dave) |
|||
| Line 21: | Line 21: | ||
** 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 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 and the message is not delievered to any resource or stored''' (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 | ** 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, since it interferes with these rules. See below for considerations on resource locking. | ||