Difference between revisions of "XEP-Remarks/XEP-0203: Delayed Delivery"
Jump to navigation
Jump to search
(Talked to Ge0rg) |
(→Missing from attribute: please also mention the privacy leak) |
||
| Line 8: | Line 8: | ||
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. | |||
Revision as of 22:48, 4 November 2019
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.
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.