ietf-mta-filters
[Top] [All Lists]

Re: List of expected changes for sieve 05 draft

1998-11-10 14:26:14
From: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
Date: Fri, 6 Nov 1998 21:56:26 -0500

13. Request: Reject should be optional.

At one level I agree with this, but at another level (and this applies
to optional "fileinto" also) I think that making the basic features 
optional hurts interopreability -- that is, it hurts portability of
scripts.  That said, I understand *why* people want to make "fileinto"
and "reject" optional.

Reject, fileinto, and envelope-sender commands all have problems that
not all systems can actually implement them, so I think we're pretty
much screwed here, although perhaps reject and envelope-sender need to
be added to the draft.

I want to be able to test "envelope-sender" too, and we have that in
our implementation...

What does the command look like?  If you've got a working syntax, we
might as well use it.

1.  "Matches" should be just another comparator, in my opinion.

Sort of.  The problem with that is that it introduces a whole set
of comparators: matches-ascii, matches-ascii-casemap, and so on,
one for each comparator that's used for "contains".

Okay.  I withdraw this, and will put :matches back into the next draft.
That's clearly better than having comparators all over the place.

I think that's probably the general opinion, too.

I think having :changes, :is, and :matches is useful, but we could do it 
all with :matches if people really wanted to.

2a. Can we keep tagged arguments?

Sure, why not?

There was a complaint about the change from "is" to ":is", but I'm
rather attached to :is for reasons I stated.  

2b. Arbitrarily, I allowed tagged arguments to be in any order and freely
...
    What do people want?  The dominant stated opinion is that they should 
    only happen after the keyword, and that's fine with me.

Yes, I'm of that opinion.

Ok, I'll plan on changing things this way.

-- 
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>