[lemonade] Should Sieve extensions be included into Profile Bis?

[Alexey Melnikov <[e-mail]>]

Hi everyone,
I hope if I am starting another rant it is going to be a short one ;-).

Just to be clear, I am currently stating no opinion on whether this 
should be a part of Lemonade Profile Bis document or not. But looking at 
the list of requirements from OMA MEM I can see that several of them can 
be addressed by Sieve (invoked on message delivery) + some existing 
Sieve extensions:

USAB-9: When connectivity is not available or drops, email events on the 
client that may take place MUST be stored on the client until 
connectivity becomes available and then sent to the email server as soon 
as possible.
The mobile email enabler MUST allow the user to set filtering rules based on
      Email header fields
      Mailbox folder options.
      Spam score.
USAB-10: The mobile email enabler MUST allow the user to change 
filtering rules on his mobile email client.
USAB-11: The mobile email enabler MUST support:
      Different methods for notifying the client about new emails based 
on capabilities of the network
      The ability for the user to select the transport method based on 
the capabilities of the client and network (e.g. SMS, Push, MMS etc)
      The ability for the user to select if, when and how events are 
accessed by the client
USAB-12: The mobile email enabler MUST support the use of a number of 
different means to transport notifications this could include SMS, MMS, 
WAP Push, SIP Notification, UDP, in band, polled)
USAB-27: The mobile email enabler SHOULD support definition of 
auto-reply messages for each filtered messages.  Automatically generated 
replies SHOULD avoid mail loops (RFC 2821 and related RFCs)

And also possibly:
SEC-10: The mobile email enabler MUST support spam protection
SEC-11: The mobile email enabler MUST support virus protection

========
Here is my take on how these requirements can be addressed:
USAB-9 can be satisfied by the base Sieve 
(draft-ietf-sieve-3028bis-13.txt, soon to become a new RFC). The last 
point is also related to draft-ietf-sieve-spamtestbis-05.txt (soon to 
become a new RFC).
USAB-10 can be satisfied by the base Sieve 
(draft-ietf-sieve-3028bis-13.txt) + by a Sieve management protocol 
(multiple choices).
USAB-11 and USAB-12 can be satisfied by the Sieve notify framework 
(draft-ietf-sieve-notify-11.txt, in IESG review now) and possibly by 
draft-melnikov-sieve-imapext-metadata-02.txt.
USAB-27 can be satisfied by the Sieve vacation extension 
(draft-ietf-sieve-vacation-07.txt, soon to become a new RFC)
And finally SEC-10 and SEC-11 can be partially satisfied by 
draft-ietf-sieve-spamtestbis-05.txt

========
So, if the WG decides to defined Sieve related requirements in the 
Lemonade Profile Bis document, here is my suggestion:

Sieve email filtering language (draft-ietf-sieve-3028bis-13.txt)
Sieve vacation extension (draft-ietf-sieve-vacation-07.txt)
Sieve notify extension (draft-ietf-sieve-notify-11.txt)

But to be more useful for clients (in particular to allow clients to 
control vacation auto-replies without rewriting Sieve scripts, etc.) I 
would also recommend the following:

Sieve variables extension (draft-ietf-sieve-variables-08, soon to be a 
new RFC)
Sieve extension for accessing IMAP METADATA  
(draft-melnikov-sieve-imapext-metadata-02.txt)
Sieve relational test (draft-ietf-sieve-3431bis-04.txt)

If there is a decision to include this into Lemonade Profile Bis, then 
this list would become a new section titled "Requirements on 
Lemonade-compliant Sieve engines".

Regards,
Alexey

P.S. At this point I don't see any need for IMAP Sieve (i.e. invocation 
of Sieve scripts on flag change, IMAP APPEND/COPY or message expunge 
events). I think IMAP Sieve is important, but not for Lemonade purposes.



_______________________________________________
lemonade mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade