I don't think a yes/no with textual explaination will do.
I suggest we use yes/no together with a formally defined error
code/word. And why not line and column pointers as well.
The reason is to give the user agent a fair chance to guide the user
when trying to correct the error. Also, we can not assume the text
resonse is understood by the user, and I dont think we want to force UAs
to do language translations of free text messages. It has to be some
formality in that regard.
So you're saying that we can deliniate the failure conditions, assigning
each a failure code? What happens when you miss one? What happens when
the reporting agent can't understand one of them?
Exactly. And in addition, what happens when, given the parsing methodology I
choose, I end up not being able to distinguish between two error conditions
that happen to have been assigned different codes in the specification? And
what happens when my operational experience shows that a particular error needs
to be broken down further to clarify matters to users, but as an implementor
I'm prevented from doing so by the define set of failure conditions?
Now, to be sure we can get around some of these problems by defining a flexible
set of codes along the lines of the SMTP enhanced status codes. But this is a
huge amount of work for very little gain.
I believe that it's likely that the user will choose a filtering agent that
uses a language they understand. Providing a way to change the error
language would be necessary, and it's one more thing that has to go with
the script through the transport.
Language support is a crucial part of all this for many of us.
I think *NOT*. I think the transport should be done transparently. A
responsibility for validation should *ONLY* exist at both ends of a
filter exchange. [...]
I think that the agent submitting code to the filtering agent should
validate code. (The meaning I meant to attach to "transporting agent"
wasn't the obvious one; sorry.)
Exchanging MIME messages over the mail transport infrastructure is one
Standardizing on magic addresses worries me a little, but it's a
possibility. I'll note that if you have any problems with ACAP, you have
all the same problems with this -- impossible to validate the script.
I think the larger problem here is that many Sieve scripts will be machine
generated. This will make script errors far less likely. But the flip side
is that if there's a script error it will probably be the result of a bug
in the script generator, and that's way beyond the ability of the average
user to fix. Pointing out an error to a user who's written their own
script is one thing, pointing out an error to a user who used a bunch of
forms and is now presented with a vast pile of program not of their own
devising is quite another.