[Standards] How many delay elements?

Tobias Markmann tmarkmann at googlemail.com
Tue Jul 19 07:07:04 UTC 2016

On Wed, Jul 13, 2016 at 9:04 PM, Holger Weiß <holger at zedat.fu-berlin.de>

> Does this mean that
> 1. a given stanza should never contain more than a single direct <delay/>
>    child element, or that
> 2. a given server or component should never add more than a single
>    direct <delay/> child element to a given stanza, or that
> 3. no more than a single direct <delay/> child element should be added
>    to a given stanza for a given delay cause?
> For example, if a groupchat message delivery is delayed because the
> sending client was offline when it was written, and then because the MUC
> service sends it as part of the discussion history, and then because
> it's queued by CSI¹, and then because it's queued by stream manegement;
> how many <delay/> elements should the stanza end up with?

Well. Do you trust delay annotation by user clients? This opens up to a lot
manipulation by end users, compared to a single MUC server that would have
to be trusted.

Then again other current messengers allow users to see times when a message
was sent, received and read. So the info could be shown to the user but the
message should probably not be inserted into the chat log based on the
delay info when it was originally sent.

CSI or SM queued messages are also under server control though and I'd say
more than one delay tag per unique from attribute does not make sense.

This sounds like the XEP could need a better wording, especially in light
of CIS and SM.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160719/0face6be/attachment.html>

More information about the Standards mailing list