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

RE: List of expected changes for sieve 05 draft

1998-11-06 19:53:35
4.  Question: Should i;ascii-casemap be the default?

I vote for that.

6.  Request: A non-present comparator is considered to be basically a syntax
    error.

7.  Request: Implementations are required to decode header charsets.

Since these requests came from comments by me, I should state clearly
that I agree with these two.

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.  I want to be able to test "envelope-sender"
too, and we have that in our implementation... but I understand why
people don't want it as a required function.

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".  In some sense,
though, it's not a problem: "contains xxx" is basically just
"matches *xxx*", but for the fact that "contains x*x" is *not*
the same as "matches *x*x*".  If we put in an escape character for
the wildcards, then we can get rid of "contains" and "is", and 
just use "matches" for everything:
   :is "abc" ...becomes... :matches "abc"
   :contains "abc" ...becomes... :matches "*abc*"
   :is "a*c" ...becomes... :matches "a\*c"
   :contains "a*c" ...becomes... :matches "*a\*c*"

I guess I'm not really stating much of an opinion on this; I think
it's fine the way it is, with "is", "contains", and "matches".  But
if we're going to make a change here, I suppose we should think about
this.

2a. Can we keep tagged arguments?

Sure, why not?

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.


Barry Leiba, Multimedia Messaging  (leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba