Re: [Standards] Proposed XMPP Extension: Reminders
Hi, thanks for your feedback Georg, really appreciated. Georg Lukas writes: > I could imagine an ad-hoc command for adding reminders, and otherwise > just regular PEP access to a node, with backend server logic to "expire" > reminders when they are due and to convert them into messages. I can see that a solution based on PEP makes listing your reminders a matter of checking some well-known node. But, maybe I just misread your message, why would you use an ad-hoc command for adding reminders instead of PEP's publish mechanism? > For groupchat reminders, it might be a little bit more complicated, > because the occupant who triggered the message might have left. However, > a reminder might well be sent from the room's bare JID. I had the idea (unspecified in the ProtoXEP, though) that in the case of groupchats the reminder shall be sent to the room's bare JID. I'll try to sum up the feedback received up to now. I wanted to send this earlier, but last weeks, unsurprisingly, have been hectic, to say the least. So, I think there's agreement at least on: * a way of retrieving current reminders must be provided * not using IQ stanzas but, probably, ad-hoc commands (now also maybe PEP?) * use the more common element for the reminder's text instead of And som kind of agreement on using XEP-0004, but given that datatypes are not well defined in there, XEP-0122 may be useful for both validation and display hints for clients. Lastly, I found interesting Jonas' comment on possible changes on the tzdata information and how this can be handled by providing both the localtime and the timezone indication. I think this can be worth having. Any feedback would be appreciated. Thanks for your attention, -- Marcos ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
Hello, I agree with the sentiments that there should be a way to query for existing reminders, and also that ad-hoc command syntax is probably not too bad for this kind of use case. However, I think we have yet another mechanism that might be used / useful for that kind of data, and it's PEP. I could imagine an ad-hoc command for adding reminders, and otherwise just regular PEP access to a node, with backend server logic to "expire" reminders when they are due and to convert them into messages. Indeed I'd say that for a personal reminder, the message should have a with the string value and be sent to the own bare JID. For groupchat reminders, it might be a little bit more complicated, because the occupant who triggered the message might have left. However, a reminder might well be sent from the room's bare JID. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
On 3 March 2020 14:49:13 CET, Florian Schmaus 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 >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 , and not invent another -like extension element >(). >>> >>> Makes sense. >>> The 'timezone' attribute in 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. 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. > >- Florian >___ >Standards mailing list >Info: https://mail.jabber.org/mailman/listinfo/standards >Unsubscribe: standards-unsubscr...@xmpp.org >___ -- Sent from my mobile device. Please excuse my brevity. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
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 >>> , and not invent another -like extension element (). >> >> Makes sense. >> >>> The 'timezone' attribute in 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 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
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 > > , and not invent another -like extension element (). > > Makes sense. > > > The 'timezone' attribute in 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: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
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). > Also § 5.2 / Example 7 "Server sends a reminder" should include just a > , and not invent another -like extension element (). Makes sense. > The 'timezone' attribute in 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. Best regards, -- Marcos ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
On 2/27/20 5:43 PM, Jonas Schäfer (XSF Editor) wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Reminders > Abstract: > This specification provides a way to set up reminders. > > URL: https://xmpp.org/extensions/inbox/reminders.html 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. Also § 5.2 / Example 7 "Server sends a reminder" should include just a , and not invent another -like extension element (). The 'timezone' attribute in is not necessary, xep82 data-time profiles already encode the timezone (the 'Z' at the end of the String). - Florian ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
пн, 2 мар. 2020 г. в 04:10, Marcos : > > Just build a bot that would send you reminders. No need to bloat the > > already huge number of extensions, > > Having the reminder implemented with a bot doesn't eliminate the need of > defining (somewhere) how would you tell such a bot to set up a reminder. > I think that having the format of the requests specified can be > interesting, specially to XMPP clients so they can interoperate with any > "reminder bot" available out there. > > I don't see "bloat", I see convenience. Convenience for whom? For developers of 50+ XMPP clients, who would have to consider support for yet another obscure XEP? Speaking of bots, clients can interact with them in a very convenient way using Data Forms (a long-neglected XEP-0004, which actually has a lot of potential for lots of various things, we definitely plan to build good support for them). -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
Hi, thanks for your comments. Andrew Nenakhov writes: > пт, 28 февр. 2020 г. в 20:05, : >> While thinking on this, being able to set arbitrary content into the reminder >> idea crossed my mind (specifically something along the lines of "please, >> remind me of this message in 20m" and then the reminder actually store the >> referenced message), but in the end I rather preferred to keep it simple. > > Just build a bot that would send you reminders. No need to bloat the > already huge number of extensions, Having the reminder implemented with a bot doesn't eliminate the need of defining (somewhere) how would you tell such a bot to set up a reminder. I think that having the format of the requests specified can be interesting, specially to XMPP clients so they can interoperate with any "reminder bot" available out there. I don't see "bloat", I see convenience. Best regards, -- Marcos ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
пт, 28 февр. 2020 г. в 20:05, : > While thinking on this, being able to set arbitrary content into the reminder > idea crossed my mind (specifically something along the lines of "please, > remind me of this message in 20m" and then the reminder actually store the > referenced message), but in the end I rather preferred to keep it simple. Just build a bot that would send you reminders. No need to bloat the already huge number of extensions, -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
Hi, first of all thanks for the comments, being it my first proposal I really appreciate them. February 28, 2020 3:41 PM, "Marvin W" wrote: > While I do like the idea, I think this could be done more elegantly > using a generic "send a message later" functionality. That way the > reminder can also be send to others and can also have arbitrary message > content. However such feature would require the own server to implement > that feature (whereas the proposed reminder spec can be implemented on > remote domains) While thinking on this, being able to set arbitrary content into the reminder idea crossed my mind (specifically something along the lines of "please, remind me of this message in 20m" and then the reminder actually store the referenced message), but in the end I rather preferred to keep it simple. > Regarding this specification: > - I think it is weird that the server acknowledges the reminder creation > by sending the full reminder. Yes, this was already pointed out in xsf@ and I do agree that this might be weird. I've already amended this. ```The server MUST inform the user of the success. The response MUST include an empty element that specifies the 'id' of the created reminder. ``` > - This specification lacks the feature to request a list of all pending > active reminders. You're right. I think it could be added. I left it out because for the use case I had in mind does not apply, but I understand this can be desirable. > - It is unclear what happens to reminders when the creating resource > (that would normally receive the reminder) is not online. I believe > current servers will route it to some other resource that is online at > that time, but the message is not carbon copied or stored in MAM. I assumed the existing routing logic of the resource's server will apply and that it's not an aspect this specification should care. Nonetheless, may it be desirable to add some text indicating that implementations MAY add storing hints? Although I still have not a strong use case in my mind where a user might want to received outdated reminders... Best regards, -- Marcos ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Reminders
While I do like the idea, I think this could be done more elegantly using a generic "send a message later" functionality. That way the reminder can also be send to others and can also have arbitrary message content. However such feature would require the own server to implement that feature (whereas the proposed reminder spec can be implemented on remote domains) Regarding this specification: - I think it is weird that the server acknowledges the reminder creation by sending the full reminder. - This specification lacks the feature to request a list of all pending active reminders. - It is unclear what happens to reminders when the creating resource (that would normally receive the reminder) is not online. I believe current servers will route it to some other resource that is online at that time, but the message is not carbon copied or stored in MAM. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
