[Standards] How many delay elements?

Guus der Kinderen guus.der.kinderen at gmail.com
Tue Jul 19 07:04:19 UTC 2016

When more than one delay element is added - assuming that only the defined
attributes are used - is there a way to distinguish what element was added
for what purpose?

The delay element should reference the timestamp on which the stanza was
originally send. Is there reason that for one stanza, that time changes? As
in, would multiple delay stanzas, if allowed, be anything other than exact


On 13 July 2016 at 21:04, Holger Weiß <holger at zedat.fu-berlin.de> wrote:

> This came up before, but I fail to find a clarification.
> XEP-0203 says:
> | Information about the delivery delay is communicated by adding to the
> | <message/> or <presence/> stanza one and only one <delay/> child
> | [...].  This information is added by the server or component that
> | delivers the stanza.
> 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?
> Holger
> ¹ Queueing groupchat messages might be weird, but XEP-0352 permits the
>   server to do weird things, AFAIK.
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160719/0be8bdd1/attachment.html>

More information about the Standards mailing list