Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt

From: Stephan Bosch <[email-masked]>
Date: Thu, 22 Oct 2020 16:20:13 +0200

On 10/08/2020 13:11, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF.
> 
>          Title           : Sieve Email Filtering: Snooze Extension
>          Authors         : Kenneth Murchison
>                            Ricardo Signes
>                            Neil Jenkins
> 	Filename        : draft-ietf-extra-sieve-snooze-00.txt
> 	Pages           : 12
> 	Date            : 2020-08-07
> 
> Abstract:
>     This document describes the "snooze" extension to the Sieve email
>     filtering language.  The "snooze" extension gives Sieve the ability
>     to postpone the filing of an incoming into a target mailbox until a
>     later point in time.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00
> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

I have one question about this:

Why does this add a new command? Why can't it just extend both keep and 
fileinto with new arguments?

Regards,

Stephan.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 22 Oct 2020 12:16:45 -0400

On 10/22/20 10:20 AM, Stephan Bosch wrote:
> Why does this add a new command? Why can't it just extend both keep 
> and fileinto with new arguments?

Hi Stephan,

I suppose we could extend these commands as we are really just delaying 
the keep/fileinto until a future (awaken) time.

So, it could look something like:

fileinto [:snooze <times: string-list> [:tzid <string>] [:weekdays 
<stringlist>]] <mailbox: string>

If we don't like having multiple tagged arguments, we could use a single 
string with some kind of ISO or iCalendar recurrence rule, but that 
might be more restrictive (I haven't actually sat down and worked out 
various examples).

The only issue would be whether we want/need flags to be set at snooze 
time and then set/unset again at awaken time, which the current spec allows.

How do others feel about extending keep/fileinto vs. a new command?

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 26 Oct 2020 16:22:54 +1100

> How do others feel about extending keep/fileinto vs. a new command?

I have no objection to extending fileinto rather than a new command, but for our use case we need to preserve the ability to set flags separately both on delivery and at awaken time.

Neil.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Oct 2020 07:58:03 +0100

On Monday 26 October 2020 06:22:54 CET, Neil Jenkins wrote:
> I have no objection to extending fileinto rather than a new 
> command, but for our use case we need to preserve the ability to 
> set flags separately both on delivery and at awaken time.

Could you elaborate? I'm just curious here.

Arnt

---

From: Ken Murchison <[email-masked]>
Date: Tue, 27 Oct 2020 10:00:03 -0400

On 10/22/20 12:16 PM, Ken Murchison wrote:
> I suppose we could extend these commands as we are really just 
> delaying the keep/fileinto until a future (awaken) time.
>
> If we don't like having multiple tagged arguments, we could use a 
> single string with some kind of ISO or iCalendar recurrence rule, but 
> that might be more restrictive (I haven't actually sat down and worked 
> out various examples).
>

As I think about this more, and look at how :fcc became kind of a mess 
with a bunch of add-on tagged args, I wonder if using a single 
structured string for a :snooze option to keep/fileinto might be 
better.  E.g.:

keep :snooze text:
{
   "until": [ "08:00:00", "12:00:00" ],
   "days": [ "1", "3", "5" ],
   "tzid": "America/New_York",
   "addflags": [ "\\\\Flagged" ],
   "removeflags": [ "\\\\Seen" ]
}
.
;

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Oct 2020 17:36:29 +0000

Hi Ken,

On 27/10/2020 14:00, Ken Murchison wrote:
>> that might be more restrictive (I haven't actually sat down and 
>> worked out various examples).
>>
>> The only issue would be whether we want/need flags to be set at 
>> snooze time and then set/unset again at awaken time, which the 
>> current spec allows.
>>
 From the point of view of making sure that extensions work with each 
other, not multiplying number of commands is a good thing. But I can 
also see attraction for [manual] script writers for shorter/different 
commands.
>   "removeflags": [ "\\\\Seen" ]
This would mean that you have 2 levels of parsing: first you use a 
generic Sieve parser to parse a Sieve script and then you would have to 
selectively parse certain recognized parameters using a different 
parser. I think this would unnecessarily increase complexity for both 
implementors and script writers, because there are now special cases of 
syntax.

Best Regards,

Alexey

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 27 Oct 2020 10:45:47 -0700

If you don't mind a stupid question on this..

The idea of a 'snooze' feature is something lot's of people are working 
on, and maybe it should be a higher level than in 'sieve'?

Maybe it would be helpful to set solicit feedback on other industry 
implementations of this feature.. possibly this should be in IMAP itself?

On 2020-10-27 10:36 a.m., Alexey Melnikov wrote:
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 27 Oct 2020 14:07:06 -0400

On 10/27/20 1:36 PM, Alexey Melnikov wrote:
>>> single string with some kind of ISO or iCalendar recurrence rule, 
>>> but that might be more restrictive (I haven't actually sat down and 

Agree on both points and I don't have a string preference either way.  
Although extending keep/fileinto is a lot less to document than a new 
snooze command and then having to document how fileinto extensions work 
with it (which is what the current draft had to do).

>> As I think about this more, and look at how :fcc became kind of a 
>> mess with a bunch of add-on tagged args, I wonder if using a single 
> generic Sieve parser to parse a Sieve script and then you would have 
> to selectively parse certain recognized parameters using a different 
> implementors and script writers, because there are now special cases 
> of syntax.

Sure, but don't we already have that now with existing structured 
strings that need to be parsed/verified?  We have email addresses, time 
and date formats, full MIME parts, URIs, and even regex.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 27 Oct 2020 14:36:40 -0400

On 10/27/20 2:07 PM, Ken Murchison wrote:
>>>>> Why does this add a new command? Why can't it just extend both 
>>>>> keep and fileinto with new arguments?
>>>>
>>>>
>>>> Hi Stephan,
>>>>
> snooze command and then having to document how fileinto extensions 
> work with it (which is what the current draft had to do).
>
>
>>>   "days":  "3[ "1",", "5" ],
> strings that need to be parsed/verified?  We have email addresses, 
> time and date formats, full MIME parts, URIs, and even regex.

FWIW, this looks like it MAY be valid (using a test-list as the final 
argument):

fileinto :create "INBOX.foo" (snooze :removeflags [ "\\Seen" ] :weekdays 
[ "1", "3", "5" ] :tzid "America/New_York" [ "08:00:00", "12:00:00" ])

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Oct 2020 10:22:13 +0000

Hi Michael,

On 27/10/2020 17:45, Michael Peddemors wrote:
> The idea of a 'snooze' feature is something lot's of people are 
> working on, and maybe it should be a higher level than in 'sieve'?
>

IMHO, I think it depends on how and where the snooze functionality is 
invoked:

1) If it is a set of static rules, such as "snooze all messages between 
7am and 9am till 11am" or "snooze all messages from X till 3pm", then 
Sieve is absolutely the right place for this. Ken's draft doesn't 
mandate how this is done, but it has 2 reasonable suggestions (one using 
SMTP and one using IMAP).

2) if snooze is initiated by a user on ad-hoc basis through IMAP, then a 
separate mechanism would be needed.

Best Regards,

Alexey

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Oct 2020 06:12:03 -0700 (PDT)

> If you don't mind a stupid question on this..

Far from being stupid; it cuts to the heart of the purpose of this extension.

> on, and maybe it should be a higher level than in 'sieve'?

I guess future release in SMTP (RFC 4865) qualifies as a "higher level"
mechanism, and as the draft notes, it can be leveraged by the sieve
implementation to implement snooze.

> implementations of this feature.. possibly this should be in IMAP itself?

Possibly. But the how very much depends on the why.

The draft states that the purpose of this extension is to avoid having messages
appear in a mailbox until "a more convenient time for the user to act upon
them".

This begs the question (yes, I'm using the phrase in the sense it has recently
acquired) of why a user would be incapable of simply ignoring or otherwise
dealing with the message, without the need for any delay. After all, delaying
delivery has potentially serious consequences: Suppose a user sets up a delay,
some messages are then delayed, and then then for whatever reason the user
urgently needs to access these messages. Depending on the way this is
implemented, tney may have no means of determining whether or not there are
messages in this state, let alone accessing them. [1]

So why would someone be willing to accept these consequences? The draft doesn't
say, but I think answer is that some clients fail in the most fundamental way
imagineable: They make it difficult, if not impossible, for the user to
exercise proper control of how they handle their email. And there  are several
failure modes a delay can address: The lack of a, "Don't sound an alarm for
nonurgent messages delivered between 10PM and 6AM" setting, inadequate and/or
inconvenient filtering options for displaying recent arrivals, etc.

Add to this the fact that users often make use of multiple clients, which
invokes a variant of Einar Stefferud's three body problem: When multiple
clients are used you end up with the union of the bugs and the intersection of
their features.

So how does this relate to an IMAP based alternative? Such an alternative is it
requires client support to configure. And if clients are going to have to
change to support this wouldn't it be better to address the underlying client
issue that makes this extension necessary?

In contrast, it only takes support in one client to set up sieve filters. And
filter configuration is something you already need for other reasons. Finally,
if need be it can be an entirely separate client.

				Ned

{1] This is, at a minumum, a security consideration that needs to be
documented.

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 29 Oct 2020 22:00:54 +1100

> messages in this state, let alone accessing them. [1]

The draft is intentionally a bit generic to try to allow for different implementations; perhaps that is a mistake. To give more specifics about what *we* implemented and why:
 * Users can explicitly snooze email using our interface. This moves the message to a Snoozed mailbox, then moves it back to the original mailbox at the time appointed by the user. The API for this is a custom JMAP extension.
 * We also added the `snooze` sieve command to allow users to set up rules to do this on delivery. This allows you to, for example, batch all marketing email so it only arrives in the inbox once a day but other email comes through immediately. The message is delivered to the Snoozed mailbox, so is immediately available via search or browsing if the user needs it before the snooze time, but it doesn't interrupt their workflow.
Since the Snooze action is now fairly widespread, it would be great to standardise an API so different clients can interoperate on this. The difficulty, as always, lies in working out what features and nuances are common enough to be standardised, and what's best left as vendor-specific extensions.

Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 29 Oct 2020 22:02:53 +1100

> Could you elaborate? I'm just curious here.

Sure. On delivery the users normal rules apply, so they may want to flag the message or mark it as read. When the message is unsnoozed we set a `$new` keyword at the awaken time and use this in our interface to mark it out specially to the user until the message is opened (when we clear the keyword).

Neil.

---

From: Ned Freed <[email-masked]>
Date: Thu, 29 Oct 2020 04:13:41 -0700 (PDT)

> The draft is intentionally a bit generic to try to allow for different
> implementations; perhaps that is a mistake.

Perhaps. OTOH, nailing down the mechanism makes widespread implementation far
less likely, and as noted below, doesn't really address the issue I raised.

> To give more specifics about what *we* implemented and why:

>  * Users can explicitly snooze email using our interface. This moves the
> message to a Snoozed mailbox, then moves it back to the original mailbox at the
> time appointed by the user. The API for this is a custom JMAP extension.

If you do it this way it's possible for a user to find the snoozed messages
and "unsnooze" them, even with an unextended client. Which is good.

>  * We also added the `snooze` sieve command to allow users to set up rules to
> do this on delivery. This allows you to, for example, batch all marketing email
> so it only arrives in the inbox once a day but other email comes through
> immediately.

I have to say I still regard it as something of a client issue that it cannot
classify and present messages in the INBOX without having to hide them
somewhere else. Heck, the client I'm using right now has this ability, and it
was coded in the 1990s.

> The message is delivered to the Snoozed mailbox, so is immediately
> available via search or browsing if the user needs it before the snooze time,
> but it doesn't interrupt their workflow.

But there's still an issue: Most users won't know how to do this. So this still
has to be called out as a security consideration.

> Since the Snooze action is now fairly widespread, it would be great to
> standardise an API so different clients can interoperate on this. The
> difficulty, as always, lies in working out what features and nuances are common
> enough to be standardised, and what's best left as vendor-specific extensions.

Implementability also enters into it. Depending on a JMAP extension at tihs
point may be... premature.

				Ned