On Thu, 11 Mar 2004 ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
But regardless of the expiration model, this proposal seems to me to be
putting the cart before the horse - we'd need to define an IMAP expiration
extension before it is reasonable to extend sieve to support it. And such a
sieve extension only makes sense if the model chosen for expirations is
per-message.
There's nothing that says we need an IMAP extension for expiration before
defining a sieve extension for expiration. Sieve can work in enviornments
other than IMAP.
Perhaps, but if we decide on this course it will be the first time we've
created an action in sieve that isn't bound to a well understand protocol
semantic defined elsewhere. Every existing action (keep, reject, fileinto,
discard, redirect, and even addheader and refuse) depends normatively
on these sorts of semantics.
For example, folders exist independent of IMAP, but having IMAP there to define
the essential semantics of folders is very useful. Failing to capture the
semantics of message expiration outside the context of sieve would IMO be a
mistake.
You could also have a sieve implementation that ran against the current
contents of a mailbox iteratively, and threw out (or refiled) all messages
older than the expiration date, for example [though I suppose this relies
more on a date comparison extension than any particular "Expire"
extension].
Sure, and I'm reasonably comfortable with this, although to be fair it does
extent the applicability of sieve past the use on or around the time of
delivery.
Ned