jmapio / jmap

JSON Meta Application Protocol Specification (JMAP)
http://jmap.io
Apache License 2.0
1.25k stars 82 forks source link

Scheduled / delayed sending is not documented? #373

Open nekohayo opened 1 year ago

nekohayo commented 1 year ago

Scheduled sending has otherwise been a luxury only available to non-standard implementations with custom interfaces, such as GMail, or Novell Groupwise (if I recall correctly). For me, the usecase for such a feature is this:

It seems to me that a key selling point for JMAP could be a standardized way to "schedule send" individual emails, server side via the email client, without resorting to silly client-side hacks like what we've been seeing in the POP+IMAP world. As part of this, the intended UX would also include the ability to edit the scheduled time or cancel the sending, reverting it to a draft, or editing the email's contents before it is sent (all things that I can do with GMail's web UI, which is one of the reasons I'm stuck with GMail).

Surely you must have thought of this, but so far I'm unsure to which extent; I Ctrl+F'ed for "schedul" or "delay" in:

...and only found a single mention, in the "Mail Specification" page, a maxDelayedSend variable. There does not seem to be other similarly-named variables or explanations with the two keywords I used.

So is this part of the spec from the start, and if yes, is it just not well documented? Otherwise, shouldn't it be part of it?

This would probably make for a more compelling protocol pitch to email clients (like Evolution) if you could say "...and you get clean, standardized scheduled sending in Evolution (or Cypht) for free! The docs about that feature are there..."

mdecimus commented 1 year ago

Hi,

Scheduled sending is indeed supported by the JMAP Mail specification, the feature is referred to as future release and is covered on page 74 of RFC8621.

In order to schedule a message for delivery at a given time, the EmailSubmission/set request has to include in the envelope the parameter FUTURERELEASE with the syntax described in RFC4865. Once the message has been accepted, the date when the message will be released for delivery can be obtained from the sendAt property with a EmailSubmission/get.

Please note that future release may only be used if the JMAP server advertises the urn:ietf:params:jmap:submission capability and includes the FUTURERELEASE keyword in the submissionExtensions property.

chibenwa commented 1 year ago

Maybe we could add this interesting thread on jmap.io in the FAQ section?

nekohayo commented 1 year ago

The only mention of futurerelease I could find was in https://jmap.io/spec-mail.html where there is a sendAt variable (?), which, presuming it is relevant, I would never have found because it does not mention "delaying", "delayed", "scheduled", "scheduling", or "later" delivery.

If possible, I would recommend you pepper the texts with such keywords (without necessarily sounding unnatural, you can use these variations through multiple sentences) wherever possible to make it easier for people and indexers to discover. Currently, even a search engine couldn't find it. "futurerelease" or "sendAt" are not what most people naturally think of when they speak of this functionality, in terms of naming.

I think it would be beneficial to augment the documentation with terminology that most humans expect (and even robots, i.e. SEO). It might be a tiny bit more verbose but it would be clearer and facilitate adoption by being more discoverable.