[Standards] Proposed XMPP Extension: Reminders

Jonas Schäfer jonas at wielicki.name
Mon Mar 2 16:18:40 UTC 2020

On Montag, 2. März 2020 11:56:58 CET Marcos wrote:
> Hi,
> 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 

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.

And this specification needs timestamps, which are a kind of structured data. 
For a naive Ad-Hoc client, specifying the timestamp in XEP-0082 format will be 
massively annoying for 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 -- given that it saves converting the Data Form data into something 
sensible to work with (including handling of unknown/unexpected fields, random 
field order, fields not adhering to the schema etc.).

Thus, no strong opinion. It needs a fixed Ad-Hoc command node name though so 
that clients can easily provide a more sophisticated layer (with proper date 
picker and stuff) on top of it.

> > 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.

I do not think that XEP-0082 date-time supports this at all, though; it 
requires to give a fixed UTC offset, which is only partially useful. A 
separate timestamp attribute alongside that would help to clarify with which 
timezone the reminder shall wander, but allows for ambiguous cases (e.g. if a 
reminder is set for one hour from now in Europe/Berlin timezone, but specified 
with a +00:00 or +02:00 offset).

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200302/45d3df82/attachment.sig>

More information about the Standards mailing list