[Standards] Proposed XMPP Extension: Reminders
jonas at wielicki.name
Mon Mar 2 16:18:40 UTC 2020
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
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards