[Standards] How many delay elements?

Georg Lukas georg at op-co.de
Tue Jul 19 07:06:59 UTC 2016

* Holger Weiß <holger at zedat.fu-berlin.de> [2016-07-13 21:05]:
> | 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.

> 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?

While the text itself reads to me like #2, I think that #1 would be the
most logical behavior. I am pretty sure that most client developers read
the XEP as #1 and thus only look for one <delay/> element to extract the
original timestamp. At least that's what my client does.

A client would need to iterate over all <delay/> elements and pick the
one with the oldest timestamp, hoping that all entities have
synchronized clocks. This is a behavior that I certainly can not read
from the XEP, so I would be surprised if many clients implement it.

In the IM context, you are usually not so much interested in the
individual delays or their causes (which you can't determine from the
'from' JID anyway), but rather in the total age of the message.

Therefore, I would suggest the following behavior:

If your entity delays a message, only add a <delay/> element if there is
none in the message already.

|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160719/9f8c4bf3/attachment.sig>

More information about the Standards mailing list