Re: some input on sieve-00

[kjj@xxxxxxxxxxxx]

Tim Showalter <tjs@xxxxxxxxxxxxxx> writes:
>I agree with Ned completely, but want to add some things.

>On 26 Apr 1997 kjj@xxxxxxxxxxxx wrote:

>> 1. Introduction

>> The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking
>> about sorting mailboxes.  Maybe something like 'autofile' or something.
>> Not a big point, just a comment.

>I won't change the word "sort" to "autofile" as I find that to be worse, but
>I think the section might be a little vague.  Can someone give me a wrong
>interpretation of the section?  Or is it better to change "sort" to
>"filter"?

Filter tends to imply altering something.  That might not be appropriate
in this context.

Maybe 'sift'.  It is a sieve, after all :-)

>> 2.7 Evaluation

>> The second paragraph mentions the possibility that implementations may
>> impose restrictions on the number of actions per message.

>> I think this is a bad thing. [...]

>Implementations are free to disallow the limits, but I want those limits.
>We have too many creative users.

>> With a restriction like this, the sieve becomes significantly less useful
>> for many of the users that are most likely to use it the first place -
>> users adept at email.

>Can you give an example?  Mailing lists and bizarre autoresponders are best
>handled on private machines or by administrators.  If sites need things like
>this, and can trust their users, they should turn the limits off.  However,
>in order for this to be useful here, or for an ISP, there must be some way
>to keep users from writing instant automated mailbombs.

>> 6. Errors in Processing a Script

>> The stipulation that implementations SHOULD NOT try to recover from a
>> script with errors is a problem for me.  Aborting within an 'if' clause
>> makes sense to me, but to totally stop filtering if any error is encountered
>> is the wrong thing to do.  I would venture a guess that most users would
>> consider this a very bad characteristic of the mechanism.

>Can you offer a counterproposal?  I can't see another good way to do it; the
>syntax errors falling through cause too many problems.  Furthermore, the
>design of the language allows one if clause to stop processing; aborting out
>of that if clause to allow the rest of the script to run would make it
>very difficult to predict control flow during a syntax error.

Expressed in this way, I'm willing to agree that it's acceptable
behaviour.  If that's the goal of the statement in the document, I would
like to see verbage in the document stating the reasoning. Without such
an explanation, I think the behaviour would be viewed in a poor light.
It might also serve to inhibit non-compliant implementations.

In general, I'd like to see more of the rationale of the design decisions
documented in the spec.
-- 
thx,
kjj