Re: Three new drafts and a question

[[e-mail]]

> I sent out three new sieve drafts last week that may be of interest:

>  <http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
  	
> 	fileinto :copy, redirect :copy -- keyword parameter that
> 	prevents cancelling the implicit "keep".

This isn't a problem I've seen myself, but it seems like a reasonable
thing to have and the implementation burden should be low.

>  <http://www.ietf.org/internet-drafts/draft-degener-sieve-editheader-00.txt>

>   	Deleting, adding, and changing message header fields.

I see several issues here:

(1) The use of separate field-name/field-value arguments to specify a header
    field matches up nicely with the header test. But it effectively precludes
    specification of more than one header in a single addheader or
    deleteheader command. I prefer the approach of having a single argument,
    which can either be a string specifying a single field or a list
    specifying multiple fields.

(2) I sure wish we'd allowed signed integers as numbers in the base sieve
    specification. If we had them available we could use negative indices
    to represent offsets from the last occurence of a given field. This in
    turn would make it possible to specify ranges of fields in deleteheader
    fairly easily. I wish I had an alternative to suggest here that would
    give us this functionality, but I don't.

(3) I see considerable value in addheader and deleteheader. Replaceheader,
    however, goes a bit too far for my tastes. Do we really need this? Is
    it worth the complexity?

>  <http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
  	
> 	Sequential execution of (unrelated) sieve scripts by the
> 	environment.  A meta-feature -- it doesn't define new sieve
> 	language elements -- that's interesting in particular in
> 	contrast to Cyrus's "include" draft.

Hmm. The approach taken here is very similar but not quite identical to the
approach I've used to combine multiple scripts. We agree in that any script
that ends in an implicit keep in effect cedes control to the next script in the
sequence, and that the explicit actions reject, fileinto, and redirect that
cancel implicit keep prevent subsequent scripts from running.

The place where we differ is in the handling of explicit keep. The draft calls
for subsequent scripts to be called. I don't do that; in my implementation an
explicit keep prevents subsequent scripts from acting.

I don't think this is something I can change at this point either. One of the
things that's often done is to have some kind of filtering in a system-level
sieve script. That script may elect to discard a message. I wanted the ability
for users to override such system-level decisions by issuing an explicit "keep"
in their scripts. This trick got documented and is now in use.

I suppose I could always implement an option to control how explicit keeps
affect the operation of multiple scripts.

There's also one semantics issue I see here: RFC 3028 says that fileinto
"INBOX" and "keep" are equivalent in an IMAP environment. This specification
tweaks that equivalence somewhat.

> There may or may not be another one for fileinto in the wings.
> It's about Kjetil's open issue 0.3 b):

> Some implementations of "fileinto" create IMAP folders on the
> fly if they don't exist; others don't.  (They redirect to
> the inbox instead.)  Sieve doesn't proscribe either way.

> My own implementation used to only reuse existing folders; but now
> that we're thinking about creating them on demand in conjunction
> with the "variables" extension, I'm getting requests for a way
> for a user to express their intention; something like

> 	fileinto :create 	"If it doesn't exist, create it"
> or
> 	fileinto :exists	"If it doesn't exist, redirect to INBOX."

> or something in that area.

> Is anyone hearing similar requests from their users?
> Have you thought about the issue and come to conclusions for
> your own releases?

We opted for the other course: We create new folders on demand. Thus far I
don't believe we've gotten requests for "only file to folders that already
exist", but of course that could change once variables support is available.

I have no problem with implementing such an extension in any case.

				Ned