[Standards] Delayed Delivery for CSI and possibly SM

Dave Cridland dave at cridland.net
Tue May 30 14:02:03 UTC 2017


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.
>
> So,
> 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. :-)

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.

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.

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.

Dave.


More information about the Standards mailing list