Difference between revisions of "XEP-Remarks/XEP-0203: Delayed Delivery"

Jump to navigation Jump to search
no edit summary
(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.

Navigation menu