[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