[Standards] Delayed Delivery for CSI and possibly SM

Dave Cridland dave at cridland.net
Wed May 31 09:59:43 UTC 2017

On 31 May 2017 at 10:46, Florian Schmaus <flo at geekplace.eu> wrote:
> On 31.05.2017 11:25, Daniel Gultsch 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.
> I think a cleaner approach would be to extend <delay/> with an optional
> <reason/> element, which has an attribute whose value is defined by an
> registry established in xep203.
> There are multiple namespaces of SM, CSI and potentially other existing
> and future delay causing XEPs. Having the indirection via an registry
> avoids the confusion and complexity when processing <delay/> elements.

This seems reasonable.

>> 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'd made it entirely optional though recommended.

How about "MAY", and "New implementations are encouraged" or something
similar? "optional" and "recommended" are both defined keywords in RFC
2119, and despite using them in a non-capitalised manner, I'd rather
avoid using both in the same sentence...

> - Florian
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list