[Standards] Proposed XMPP Extension: Reminders

Florian Schmaus flo at geekplace.eu
Tue Mar 3 13:49:13 UTC 2020

On 3/2/20 5:18 PM, Jonas Schäfer wrote:
> On Montag, 2. März 2020 11:56:58 CET Marcos wrote:
>> thanks for your comments, Florian.
>> Florian Schmaus writes:
>>> I think creating/canelling a reminder should rather be an ad-hoc command
>>> and not an IQ. This way, clients do not need to implement another IQ
>>> protocol-flow, but can re-use their (potentially) existing ad-hoc
>>> infrastructure.
>> This probably escapes from my current understandings of the protocol, so
>> thanks for pointing it out and I'll try to have a read over IQ handling
>> logic, specially at client side (an issue Andrew already exposed).
> Ad-Hoc commands would definitely be a way to do this. Using a specified 
> command name (like XEP-0401 does) would allow for automated entities to 
> interact with this and also gives immediate basic client support for clients 
> which already support Ad-Hoc commands.
> For clients which do not, and which also do not support Data Forms at all, 
> this will be more of a pain to implement even without offering extensive user 
> interaction.

I doubt that it will be much pain, and even if, I would consider
implementing data forms and ad-hoc commands are worth the pain.

> This is always a trade-off, and I’ve stated elsewhere that I consider data 
> forms a bad thing to have due to their lack of supporting arbitrary structured 
> and dynamic data.

I don't think I agree with that. They are flexible enough to serve a
large portion of data-exchange use-cases. I am also not sure why they
shouldn't support dynamic data.

> And this specification needs timestamps, which are a kind of structured data.

Right. I would suggest to use xep122 "data forms validation" to provide
a client with the hint that this form field is a xep82 data time format.
Clients could use this to show a data/time picker UI when this form
field is selected.

> For a naive Ad-Hoc client, specifying the timestamp in XEP-0082 format will be 
> massively annoying for the user.

Agreed, especially if no xep112 hint (cf. xep112 example 2) is used. But
still better than a naive client not being able to participate at all
IMHO. Not sure how massive the annoyance for the user would be, though.
Guess it depends on the user.

> For a client which adds specific support for 
> this ProtoXEP, the cost of doing so is likely less high than adding a custom 
> IQ support

Correct: For a client (library) already supporting data forms,
implementing an ad-hoc/data-form based protocol is far easier then
implementing a pure IQ based protocol.
>>> Also  § 5.2 / Example 7 "Server sends a reminder" should include just a
>>> <body/>, and not invent another <body/>-like extension element (<text/>).
>> Makes sense.
>>> The 'timezone' attribute in <date/> is not necessary, xep82 data-time
>>> profiles already encode the timezone (the 'Z' at the end of the String).
>> Indeed, this slipped in from an early write up where no reference to
>> XEP-0082 was yet present.  It has been already amended.
> Actually, timezones is a good keyword.For timestamps in the future, it is 
> generally better to use localtime+timezone specifier instead of a UTC 
> timestamp. After all, if you are in the Europe/Berlin timezone and set a 
> reminder for a year from now and Europe switches to UTC+2 all year round, you 
> don’t want your reminder to fire at the wrong hour.

Fair point, but I believe the timezone is unnecessary and hence
contributes to protocol bloat and potentially causes confusion. Clients
could just set the right future timestamp taking the timezone into
account. A note about this in the XEP sure would be sensible.

- Florian

More information about the Standards mailing list