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 interaction. 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, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
