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

Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")

1997-03-28 16:38:36
At 5:24 PM -0500 3/28/97, Jack De Winter wrote:

ACAP does not verify syntax on options.  There really isn't any "mapping"
when storing filters in ACAP.  The way I see the filter dataset, it is very
simple: just a set of entries, each entry consists of an entry (name)
attribute and a filter attribute.  The entry attribute is any unique handle
assigned by the filter generator (probably the client), and the filter
attribute is just a text string.  For example:

Well, to be precise, ACAP does not enforce any syntax, but the gatweway
between ACAP and the data store may.  For example, ACAP will accept the
data, pass it to the routines to store that data, and those routines may
cause the data to be rejected.  This was dicussed at the ACAP meeting,
where I believe the consensus was that the ACAP datasets did not actively
do syntax checking but the backend was allowed to reject data.

As I recall it, there was general rejection of the idea that ACAP, as a
protocol, would enforce syntax.  There was some agreement that one could
have an implementation that would apply some syntax or content rules, but
it should be pretty exceptional.  Your example was using ACAP to store
server configuration, where you wanted to be sure not to let anyone store
"Hi Mom!" in the "Maximum number of threads" attribute.  That might be OK,
but having an ACAP server apply all sorts of rules to the data would mean
that you then have to invent a way for clients to discover the rules, and
you end up with a very complex mess.  If syntax enforcement is required,
then it needs to be in the protocol.  I think we've decided it doesn't need
to be in ACAP.  Maybe I was jet-lagged and wasn't following the discussion,
but that's how I remember it.  I suppose this is a question for the ACAP
list.


... I took mail I wanted to deal with and do something, and as the default
bounce the message.  These would be hard to convey with an entry by
entry basis, as would any idea of including other files.

I really think we need to keep the filtering spec as simple and bare-bones
as possible, otherwise it will never get consensus.  I recall the BOF in
San Jose saying explicit inclusion of other filters was too complex for now.



...and have the backend verify the script when the script is set up.
For example, my backend verifies the script and only generates and
updates the 'compiled' script when it detects no errors.

I don't think the ACAP back-end should do anything except store and
retrieve the data.  No syntax checking.