[Standards] Delayed Delivery for CSI and possibly SM
kevin.smith at isode.com
Tue May 30 14:27:40 UTC 2017
On 30 May 2017, at 15:02, Dave Cridland <dave at cridland.net> wrote:
> On 30 May 2017 at 14:48, Kevin Smith <kevin.smith at isode.com> wrote:
>> On 30 May 2017, at 14:00, Daniel Gultsch <daniel at gultsch.de> wrote:
>>> I noticed that some CSI implementations (and maybe some SM
>>> implementations as well) add a delayed delivery tag where the from is
>>> set to their own domain.
>> Before making spec changes, it’d probably be a good idea to work out why they’re doing this, and what it buys us.
>> 1) Why is it good to shove <delayed/> on CSI?
>> 2) Why is it good to shove <delayed/> on SM resumption? (198 talks about stamping already, but in the context of failed delivery).
>> My first thought for both is that <delayed/> has some traditional semantics and that putting it on 198/352 would be unhelpful, but I’m open to being wrong.
> I think you're wrong. :-)
Yes, so do I. :)
> The semantic of delayed is:
> a) To indicate that a stanza was delayed deliberately by an
> appreciable timespan.
> b) To indicate when the stanza would have been delivered, absent that delay.
> c) To indicate which entity is responsible for the delay.
> It doesn't, for better or worse, indicate the reason for the delay
> (I'm open to adding a subelement to indicate that, but I can imagine
> that might cause problems). Instead, that reason is currently derived
> from the entity delaying.
I wonder if it really would cause problems?
> In the case of a 198 resumption, the stanzas have been delayed, and
> it's useful to know whether a message is just now or dating from
> before you jumped onto the tube.
Yes, you (and Daniel) are obviously right here…for messages. I’m not sure if it matters whether it’s server or bareJID stamped here, though. At least one train of thought is that this is a delay very much like offline message, so stamping consistently makes sense.
> Presence, mind, I'm not so sold on - I think it's significantly less
> important, since presence is stateful rather than an event. But I'm
> not averse to it - I'd just argue that if it causes problems, just
> don't bother delay-stamping.
I think not stamping presence makes a lot of sense, unless there’s a use case for this that I’ve similarly missed.
More information about the Standards