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

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.