Subject: Re: Sieve extensions

From: "Matthew Wall" <[email-masked]>
Date: Sun, 18 Jan 1998 18:08:19 -0500

--On Sun, Jan 18, 1998 11:43 -0800 "Ned Freed" <[email-masked]>
wrote: 

> Generally speaking the mail server has to assume that invalid scripts will
> appear from time to time. Suppose the ACAP server doesn't validate
properly?
> What then?
> 
> As such, good error handling has to be part of the server, and we need to
> make sure we specify what that is.

OK, there's several approaches we could take here:

0 : relegate syntax checking to end agents, i.e. the generator, storing
agent, and/or interpreting agent, but not place specific requirements on
error conditions as part of the base specification.

1: specify a simple 'yes' or 'no' error be required by one or more agents;
any 'no' response is rejected without articulation for the generating agent
to figure out.

n: do full error/ response codes, which would (I think) require some
discussion of interpreter behavior. This is not completely out of scope, but
I think would require a great deal of attention and care. 

In general, I'd disagree with the notion that the storing or transporting
agent (e.g. ACAP) ought to be involved with validating the code. It seems to
me this is killing the messenger for delivering a BAD message, as it were.
Since generation and interpretation are the responsibility of SIEVE-aware
agents, the error-checking should be strictly handled at those points.
Otherwise you put some pretty severe implementation restrictions on a
storage mechanism that probably out to be (literally) value-neutral.

- mw

---

From: Tim Showalter <[email-masked]>
Date: 18 Jan 1998 18:51:08 -0500

> Date: Sun, 18 Jan 1998 18:08:19 -0500
> From: "Matthew Wall" <[email-masked]>
> 

Typos happen; errors have to be handled or there will be compliant
implementations that do arbitrarily stupid things on error.

I think a yes/no is enough, provided the interpreter can give a text
response explaining why.  Trying to get a list of all the ways an
interpreter can fail is futile.

My only worry is how and when you communicate these back to the user.  If
the ACAP server can't validate the script, when does the error get
returned?  If the ACAP server does validate the script, but then a runtime
error happens, what happens?

I think the transporting agent *should* validate the code, but there's no
way to enforce that.  The filtering agent has to do validation before
running the code so that syntax errors can be weeded out -- make sure that
the filter and the user agree that the script is at least valid before
trying to run it.

Asking the transport to verify the script is good, but not complete; it's
the server's responsibility because there's no other way to even suggest
that the client will get it right.

-- 
                                          Tim Showalter [email-masked]

---

From: Tomas Fasth <[email-masked]>
Date: Mon, 19 Jan 1998 03:31:14 +0100

> interpreter can fail is futile.

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.

> My only worry is how and when you communicate these back to the user.

This has to be solved, and I'm not sure ACAP is part of that solution.

> way to enforce that.

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. Instead of doing intermediate validations, the
transport should provide a two way link between user agent and filter
agent. This is exactly what we should try to find a solution for.
Exchanging MIME messages over the mail transport infrastructure is one
such suggestion.

Tomas

---

From: Tim Showalter <[email-masked]>
Date: 18 Jan 1998 23:21:36 -0500

> Date: Mon, 19 Jan 1998 03:31:14 +0100
> From: Tomas Fasth <[email-masked]>
> 
> 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 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.

> 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.

---

From: Ned Freed <[email-masked]>
Date: Mon, 19 Jan 1998 01:52:46 -0800 (PST)

> 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.

> the script through the transport.

Language support is a crucial part of all this for many of us.

> 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.

				Ned

---

From: Tomas Fasth <[email-masked]>
Date: Mon, 19 Jan 1998 17:43:36 +0100

> 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: [email-masked] // or whatever to identify the reporter
Status: failed
Reason: syntax error
Ruleset name: test
Line: 3
Position: 35

> 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.
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.

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? I
don't think so. Just leave the user interaction to the UA, including how
to present an error condition to the user; the message, the language,
type of dialog etc.

> Providing a way to change the error

Really? You will run into the same set of considerations currently
discussed in "Sieve extensions" thread. What if not supported... etc.

> wasn't the obvious one; sorry.)

Yeah, okay. I agree that in any case validation should be performed as
close to the originating user as possible.

> 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... ;-)

--Tomas

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 19 Jan 1998 14:37:19 -0700 (MST)

> agents, the error-checking should be strictly handled at those points.

Consider also that methods other than ACAP can and will be used to 
store these. Nothing guarantees the non-ACAP ruleset store can do 
syntax checking, therefore the SIEVE agents *must* be prepared to 
validate the scripts. 

--lyndon

---

From: Tim Showalter <[email-masked]>
Date: 20 Jan 1998 00:53:28 -0500

> Date: Mon, 19 Jan 1998 17:43:36 +0100
> Organization: EuroNetics Operation
> 
> Tim Showalter wrote:
> 

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.

> 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.

> administrator, but providing multiple language support at this level?

Why not?

> discussed in "Sieve extensions" thread. What if not supported... etc.

The alternative is unworkable.

> 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.

> say from time to time... ;-)

By magic addresses I mean Keith's suggestion that I could submit my filter
by mailing to [email-masked] or something and, yeah, some sort
of MIME-based signed security.  I haven't thought through this.