On Wed, Jul 13, 2016 at 9:04 PM, Holger Weiß <[email protected]> wrote:
> > 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. Cheers, Tobi
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
