[Standards] Delayed Delivery for CSI and possibly SM
flo at geekplace.eu
Wed May 31 09:46:39 UTC 2017
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.
> 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/>
I'd made it entirely optional though recommended.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 642 bytes
Desc: OpenPGP digital signature
More information about the Standards