[Standards] Proposed XMPP Extension: Reminders
jonas at wielicki.name
Tue Mar 3 14:00:14 UTC 2020
On 3 March 2020 14:49:13 CET, Florian Schmaus <flo at geekplace.eu> wrote:
>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
>>>> and not an IQ. This way, clients do not need to implement another
>>>> protocol-flow, but can re-use their (potentially) existing ad-hoc
>>> This probably escapes from my current understandings of the
>>> thanks for pointing it out and I'll try to have a read over IQ
>>> logic, specially at client side (an issue Andrew already exposed).
>> Ad-Hoc commands would definitely be a way to do this. Using a
>> command name (like XEP-0401 does) would allow for automated entities
>> interact with this and also gives immediate basic client support for
>> which already support Ad-Hoc commands.
>> For clients which do not, and which also do not support Data Forms at
>> this will be more of a pain to implement even without offering
>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
>> forms a bad thing to have due to their lack of supporting arbitrary
>> 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
>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
>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.
>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
>> 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
>>>> <body/>, and not invent another <body/>-like extension element
>>> Makes sense.
>>>> The 'timezone' attribute in <date/> is not necessary, xep82
>>>> profiles already encode the timezone (the 'Z' at the end of the
>>> 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,
>> generally better to use localtime+timezone specifier instead of a UTC
>> timestamp. After all, if you are in the Europe/Berlin timezone and
>> reminder for a year from now and Europe switches to UTC+2 all year
>> 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.
No, because the timezone definitions may (and they often enough do, look at the tzdata version history) change between when the client sets the reminder and the reminder fires. Hence my example about EU deciding to abolish DST.
>Standards mailing list
>Unsubscribe: Standards-unsubscribe at xmpp.org
Sent from my mobile device. Please excuse my brevity.
More information about the Standards