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

[Alexey Melnikov <[e-mail]>]

Hi Michael,

On 27/10/2020 17:45, Michael Peddemors wrote:
> 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?

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

> On 2020-10-27 10:36 a.m., Alexey Melnikov wrote:
>> Hi Ken,
>>
>> On 27/10/2020 14:00, Ken Murchison wrote:
>>>
>>> On 10/22/20 12:16 PM, Ken Murchison wrote:
>>>>
>>>> On 10/22/20 10:20 AM, Stephan Bosch wrote:
>>>>>
>>>>>
>>>>> On 10/08/2020 13:11, [e-mail] 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?
>>>>
>>>>
>>>> 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?
>>  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.
>>> 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" ]
>>> }
>>> .
>>> ;
>>>
>> 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
>>
>> _______________________________________________
>> Extra mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/extra
>
>
>