Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)

[Alexey Melnikov <[e-mail]>]

Dave Cridland wrote:
> On Fri May 23 16:40:57 2008, Ned Freed wrote:
>>> Alexey Melnikov wrote:
>>> > While this is a Lemonade WG document, this document is of 
>>> relevance to
>>> > the Sieve WG mailing list and should be reviewed here.
>>> >
>>> > So please review
>>> > 
>>> <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-05.txt> 
>>>
>>> > before May 5th.
>>> I haven't seen any reviews of this. Can you please send me a quick 
>>> "I've
>>> reviewed it and it looks fine" or "this needs more work" to me, if
>>> you've done a review.
>> I finally had a chance to look at this. Having done so, the question 
>> I really
>> want to ask is has anyone implemented this, and if they  did, how 
>> well did it
>> work? And if the answer to that is "no implementations yet", I'd then 
>> like to
>> hear if anyone is planning to implement this, and if so, when and for 
>> what
>> puropse?
> The whole thing just leaves me a quivering mess, whimpering in a 
> corner and yearning for the good old days, when if one APPENDed 
> message literal in a MULTAPPEND set was accepted, one could breathe a 
> sigh of relief and use LITERAL+ to do heavy pipelining on the rest.
>
> I'm still not entirely sure how IMAP-SIEVE would signal *which* 
> message failed in a MULTIAPPEND set, actually
Dave, I don't understand how is this different from MULTIAPPEND without 
IMAP Sieve: an IMAP Sieve script can't "fail" append. It can only 
discard message after it gets appended (see section 3.6).
> - I did look, and Section 2.2.2's coverage of this particular problem 
> is, well, exceedingly economic.
>
> But this is a specific issue, rather than the more general problem.
 [...]
> This ignores the interesting cases of whether an implementation 
> ignores, for the purposes of Sieve, events caused by Sieve scripts, 
> since otherwise two mailboxes could have conflicting scripts that 
> cheerfully bounced an APPENDed message backwards and forwards for all 
> eternity.
Sieve fileinto caused by IMAP Sieve is not the same as IMAP COPY, but in 
order to avoid any doubts I agree that the Security Considerations 
should also mention that.
> The Security Considerations section clearly states that 
> implementations might choose to do so, maybe, but only for flagchanges 
> on Tuesdays in Summer during non-leap years.