Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
2008-05-24 00:33:57
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.
|
|