Difference between revisions of "XEP-Remarks/XEP-0203: Delayed Delivery"
(Talked to Ge0rg) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{remarks}} | |||
= Multiple delay tags = | = Multiple delay tags = | ||
| Line 4: | Line 6: | ||
Thus it makes sense to allow multiple delayed delivery payloads on a stanza. | Thus it makes sense to allow multiple delayed delivery payloads on a stanza. | ||
Suggested order of precedence, pick the first one that's available: | |||
# delay element without a <tt>from</tt> attribute or from a full JID - from the original message sender | |||
# delay element from a bare JID - from a MUC (MUC history) or a user account | |||
# delay element from a domain JID - server wasn't able to forward message immediately | |||
# [https://xmpp.org/extensions/xep-0297.html Forwarded] message: <tt><forwarded></tt>'s delay element] - messages from [https://xmpp.org/extensions/xep-0313.html MAM] or [https://xmpp.org/extensions/xep-0280.html Carbons] | |||
# Forwarded message: message payload: outer message's delay element] - fallback for when the forwarder didn't add a timestamp | |||
# Local timestamp taken on receiving the message | |||
= Missing from attribute = | = Missing from attribute = | ||
A stanza sent without a <code>from</code> attribute implies <code>from=senders full JID</code>. Applying the same to delayed delivery makes sense, ie missing <code>from</code> means that it was the original sender that had a delay. | A stanza sent without a <code>from</code> attribute implies <code>from=senders full JID</code>. Applying the same to delayed delivery makes sense, ie missing <code>from</code> means that it was the original sender that had a delay. | ||
Including ones own full JID would also be a privacy leak in the context of (semi-)anonymous MUC. | |||
Latest revision as of 13:30, 28 January 2021
|
This is a page for information about XEP-Remarks/XEP-0203: Delayed Delivery, including errata, comments, questions, and implementation experience. |
Multiple delay tags
There are multiple hops involved in delivery of a stanza, multiple points where it may be delayed. It may even be delayed multiple times, e.g. because the users client had to resume their XEP-0198 session and their server took its sweet time to get s2s up and running.
Thus it makes sense to allow multiple delayed delivery payloads on a stanza.
Suggested order of precedence, pick the first one that's available:
- delay element without a from attribute or from a full JID - from the original message sender
- delay element from a bare JID - from a MUC (MUC history) or a user account
- delay element from a domain JID - server wasn't able to forward message immediately
- Forwarded message: <forwarded>'s delay element] - messages from MAM or Carbons
- Forwarded message: message payload: outer message's delay element] - fallback for when the forwarder didn't add a timestamp
- Local timestamp taken on receiving the message
Missing from attribute
A stanza sent without a from attribute implies from=senders full JID. Applying the same to delayed delivery makes sense, ie missing from means that it was the original sender that had a delay.
Including ones own full JID would also be a privacy leak in the context of (semi-)anonymous MUC.