XEP-Remarks/XEP-0203: Delayed Delivery

= 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:  '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  attribute implies. Applying the same to delayed delivery makes sense, ie missing  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.