Re: Three new drafts and a question

[Jutta Degener <[e-mail]>]

On Thu, Apr 24, 2003 at 11:08:49AM -0700, [e-mail] wrote:
[editheader]
>     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.

Hm, you mean a real ["foo", "bar"] list, or a chunk of text
that becomes the header?

If you're using ["foo", "bar"], you'll quickly run into the
lack of list operations and -variables.

If you're using a big chunk of text, I think it will still have
to be parsed into names and values and checked or, more likely,
reformatted.  I don't like doing that, not so much for efficiency
reasons but because it pretends to the script writer that they're
touching the true outgoing header when I really can't let them
do that.

Do you have a usage scenario where a single string vs. multiple
makes a big difference?

> (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.

Yeah, that would be nice, but I couldn't get it to work either.

> (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?

The "replaceheader" command started out as a "tagheader" command
that just gave its user a choice of adding a prefix or a suffix.

The original audience for this was users with message stores that
don't support direct fileinto.  They can tag their messages by adding
or changing the Subject: line, and then filter based on the Subject
line in their browsers.

Then people wanted an "untagheader" command, and didn't generally
respond well to the complexity of picking a header vs. the simplicity
of what I let them do it once they had it, so "replaceheader"
replaced the "tag" and "untag" versions and got a little more solid.

We can argue whether :newname has any business being there, though.

> > <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.

Interesting.  I've had some push-back about that, too, where colleagues
felt (and probably still feel) uncomfortable that the system would react
to an explicit command with this big-brotheresque "well, you're saying you
want to keep the message, but what you _really_ may want is to give it the
default trailing script treatment".

> 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.

We'd just have used "fileinto "INBOX"" for that, but okay.  And of
course you might not have "fileinto".

> 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.

Yeah, I know...

I guess the alternative here is to make explicit keep and implicit
keep once again behave differently.  That's ugly, but it does seem
to be closer to expectations.

Did you ever run into a situation where that gave you trouble --
where you wished you could have an explicit implicit keep?

Jutta