Date: Mon, 19 Jan 1998 17:43:36 +0100
From: Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
Organization: EuroNetics Operation
Tim Showalter wrote:
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?
I just thought it might be good to define a basic set of useful
information used in failure reports. Compare with DSN/MDN. Like:
Filter agent: filter(_at_)test(_dot_)com // or whatever to identify the
reporter
Status: failed
Reason: syntax error
Ruleset name: test
Line: 3
Position: 35
I believe that it's likely that the user will choose a filtering agent that
uses a language they understand.
Why? Why do a filter agent need to know about languages (other than
filter description languages of course :)? It just complicates things.
No, it really needs to be able to have textual error messages. In the
example you just gave, it was filled with what are *really* plain-text
error messages. I agree with Ned; trying to spell out parser failures is a
waste of time.
Part from that, there have to be pieces of information in a machine
readable form as well. That form should provide information enough for
the UA to be able to guide the user when making corrections.
The user should never have to correct a script in the first place.
Having a direct interaction between a filter agent and the end user (in
the form of human readable freeform text information) is not something I
would recommend. Sure, good for debugging and for a system
administrator, but providing multiple language support at this level?
Why not?
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.
Really? You will run into the same set of considerations currently
discussed in "Sieve extensions" thread. What if not supported... etc.
The alternative is unworkable.
Yeah, okay. I agree that in any case validation should be performed as
close to the originating user as possible.
Validation has to be performed by the interpreter if it wants to ensure
that the code is valid; you can't reasonably trust the other layers.
Anything else is a feature, and all the MUSTs in the world won't make it
so.
But the UA should validate the script, as it's the easiest way to get
errors back.
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.
Maybe. I can't say I have spend too much time analysing that.
I'm not sure what you mean by "magic addresses". I essentially think of
a list processor like behavior with the addition of signed and maybe
encrypted MIME parts. It's not rocket science, as you americans like to
say from time to time... ;-)
By magic addresses I mean Keith's suggestion that I could submit my filter
by mailing to tjs+#filter(_at_)andrew(_dot_)cmu(_dot_)edu or something and,
yeah, some sort
of MIME-based signed security. I haven't thought through this.
--
Tim Showalter
tjs+(_at_)andrew(_dot_)cmu(_dot_)edu