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

From: "Jack De Winter" <[email-masked]>
Date: Fri, 28 Mar 1997 19:11:00 -0500

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

It was my understanding that the ACAP protocol itself would not impose
any limitations, but any backend coudl reject the data.  If this is not
the case, I will strongly bring this up in Memphis.  If I have to accept
anything that is thrown at me in any case, then ACAP's usefulness for
me goes downhill approaching terminal velocity.

For example, what happens if someone tries to set the value of one of
the fields of an address book to a GIF image that is over 200K?  Am I,
as an ACAP server implementor, supposed to not accept that image and
store it?  If so, its pretty brain dead.

I think Steve Hole's big concern was on checking every piece of data,
and mine was that we were just acting as a generic data store with
absolutely no format.

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

I recall that it would be too complex for a first pass, but there was no
objection to having it included.

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

In that case, I will bring up this point at the ACAP WG meeting in
Memphis, against some of the positions expressed at the conference
we just had in Pittsburg.  Not having ACAP enforcing the data, I can
live with.  Not having any checking of the data I cannot.  Having to
accept "Hi Mom!" for a numeric field is stupid.  Not putting the
focus on the ACAP server, no problems... but not allowing any feedback
to the client that there is a problem or that there may be a problem is
inviting too many problems.

regards,
Jack

p.s. just my own 2 cents, and I am a strong proponent for the ACAP protocol.
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

---

From: Randall Gellens <[email-masked]>
Date: Fri, 28 Mar 1997 17:34:34 -0800

At 7:11 PM -0500 3/28/97, Jack De Winter wrote:

> the fields of an address book to a GIF image that is over 200K?

As I see it:

(1) If the GIF contains nulls, and the attribute name doesn't end in ".bin"
the STORE can be rejected, I think.

(2) The 200k might exceed the quota, in which case the STORE would be rejected.