[Standards] Delayed Delivery for CSI and possibly SM

Dave Cridland dave at cridland.net
Wed May 31 09:35:46 UTC 2017


On 31 May 2017 at 10:25, Daniel Gultsch <daniel at gultsch.de> wrote:
> 2017-05-30 23:48 GMT+02:00 Dave Cridland <dave at cridland.net>:
>> On 30 May 2017 at 22:33, Daniel Gultsch <daniel at gultsch.de> wrote:
>>> That subelement could be in the namespace of the XEP that adds it.
>>> I'm fairly certain that this shouldn't cause problems for any half way
>>> decent implementation.
>>
>> It's the less than halfway decent implementations I'm more concerned about.
>>
>> It might be worth giving it a go to see what happens.
>
> It's worth pointing out that this will primarily affect
> implementations that implement SM or CSI. I think it's fair to assume
> that all implementations that implement those are above the 'halfway
> decent' threshold.
>
> I'm willing to create PRs for the following three changes if we hereby
> agree that we want to handle it this way.
>
> 1) Add wording to XEP-0203 that the delay element MAY contain either
> character data that provide a natural language description OR an
> element of a different namespace describing the reason for the delay.

Only the latter, please. I could be persuaded into having a <text/>
element or some such if people *really* want that, but I wouldn't want
text-or-element anywhere if I can avoid it.

> 2) Add a section to XEP-0353 that the server SHOULD add a delay
> element to delayed message and presence stanzas that MUST contain a
> <csi/> element
> 3) Add a section to XEP-0198 that the server SHOULD add a delay
> element to delayed messages and presences which MUST contain a <sm/>
> element
>
> (I think SHOULD wording in doesn't require a namespace bump. But I'm
> willing to go with MAY)

I'd go MAY/SHOULD to avoid a namespace bump.

Is there any reason a client shouldn't add these delay stamps too?
Seems sensible particularly for messages.


More information about the Standards mailing list