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

From XMPP WIKI
Jump to navigation Jump to search
(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:

  1. delay element without a from attribute or from a full JID - from the original message sender
  2. delay element from a bare JID - from a MUC (MUC history) or a user account
  3. delay element from a domain JID - server wasn't able to forward message immediately
  4. Forwarded message: <forwarded>'s delay element] - messages from MAM or Carbons
  5. Forwarded message: message payload: outer message's delay element] - fallback for when the forwarder didn't add a timestamp
  6. 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.