ietf-mta-filters
[Top] [All Lists]

Re: Establish communication between UA and FA

1998-01-19 02:48:58
I think using ACAP as the middle man between UA and the FA (filter
agent) is not a particularly good solution. It seem like doing things
halfway somehow.

I happen to think it would be a great solution. Unfortunately I also happen to
think that people will use all sorts of mechanisms to send these things around
and we need to be prepared to deal with different ones.

We need to focus of documenting what a suitable mechanism is rather than
assuming that some specific mechanism will always be used. We can, if we think
it necessary, define something very specific, but doing so does not obviate
the need to lay down some general requirements.

Using ACAP to store UA preferences and configuration, inclusive filter
rules, is one thing. Especially when working truly disconnected and at
different locations. Then it's a great thing.

Using ACAP as a mediator between an UA and remote functionality may
work, unsaid how the security model looks like, but not something we
should put up as a primary recommendation. And even if we do, a user
have to provide the filter agent some form of direction how to dig out
an entry from an ACAP repositary. How exactly is this provided?

The ACL facilities in ACAP are more than flexible enough to do this.

So,
maybe it's not within the scope to ask such a question. Still, the
question is related to the question about how the FA will be able to
communicate error conditions and status information. If we find an
answer to either of the questions, we might actually have answered both.

I think we need to assume that all sorts of paths will exist with varying
capabilities. Mind you, this doesn't mean we cannot standardize a set of errors
for Sieve programs as part of laying out what the minimal capabilities have to
be. However, I think the notion of standardizing a very precise set of errors
and mandating when they are to be produced goes much too far. For one thing,
people are going to use all sorts of different parsers and requiring that
certain errors be detected in certain ways is far too limiting. And for
another, I do not believe that doing stuff like this actually results in a more
useful and user friendly facility. As it happens my initial compiler
experiences were with languages set up with sets of errors along these lines,
and that experience was anything but good.

                                Ned





<Prev in Thread] Current Thread [Next in Thread>