145
edits
(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. |