[Standards] Proposed XMPP Extension: Reminders

marcos at tenak.net marcos at tenak.net
Fri Feb 28 15:05:14 UTC 2020


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" <xmpp at larma.de> 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 <reminder> element that specifies the 'id' of the created reminder.

<iq id='abc123'
    to='juliet at capulet.net/balcony'
    from='capulet.net'
    type='result'>
  <reminder xmlns='urn:xmpp:reminders:0' id='d414cec2-5369-11ea-9455-8b8d265047d9' />
</iq>
```

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


More information about the Standards mailing list