Tim Showalter <tjs(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
I agree with Ned completely, but want to add some things.
On 26 Apr 1997 kjj(_at_)primenet(_dot_)com 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