Subject: mailstore independence

From: Eric Horst <[email-masked]>
Date: Wed, 3 Jun 1998 11:29:19 -0700 (PDT)

I've been thinking about filtering for some time but not been following
the Sieve discussions.  Hopefully I've read enough of the archive to not
sound like a total schmuck. 

After reading the -03 draft my issue is with "fileinto".  I don't think
the description of fileinto is as independent of mail architecture as it
could be.  The main issue is the wording "drops the message in to a named
folder."  While this are general terms they do carry some baggage.  
Rather than attempt a discussion I'll give a counter proposal:

    Syntax:      fileinto <location>

    The "fileinto" action inserts the mesage into the mail store at the
    specified location.

This avoids the loaded terms and hints of a specific implementation.  By
contrast I should point out that "keep" is quite nicely defined avoiding
these pitfalls.

Likewise, I think that any places in the draft that use the wording "the
message would be filed into INBOX" (notably in the examples for "replay"
and "support") should be rewritten as "the message would be filed into the
default location."  Even though they are examples "INBOX" brings some
baggage into the spec.

Hopefully this is productive.

--Eric

---

From: Matthew Wall <[email-masked]>
Date: Wed, 10 Jun 1998 13:01:27 -0400

Howdy,

just got the call for scheduling WG/BOF meetings for the Chicago IETF today
from Marcia.

My inclination is to NOT schedule a BOF at Chicago. Here's my reasoning:

- the pushback from the meeting at LA was that there was plenty of interest,
but before proceeding, the rough edges had to be worked out and a revised
version of the spec worked out on the list.

As we've had only about 20 posts to the list since the LA BOF, I think we
have a lot more work to do on the list.

FYI, the official (blue sheet) attendance at the BOF was 87, though I
head-counted about 100.

- my personal feeling on this is we should "finish" SIEVE more or less as is
as "SIEVE1" without opening up ratholes like procedures, and use that --
which will provide some working solutions now, especially since a couple of
folks are already doing implementations -- and provide a basis of discussion
for standardization and additional work. There's nothing in "SIEVE1" as-is
that can't be undone in an enhanced "SIEVE2". This method of proceeding
doesn't require a meeting at this point, since I don't think we've seen
enough progress since LA at this point to justify a productive meeting. And
I'd prefer holding off Ratholefestapalooza II until we have working
experience with simplified SIEVE1-style implementations. Just my druthers,
but I will defend the position that simple and implemented is better than
complicated and vapor.

- remember that official IETF procedures allow only _two_
officially-scheduled BOFs. I'd like to reserve that last BOF for December
(or some later use), at which point we can (a) go straight to standard or
(b) decide to go ahead with a working group (or c, abandon all work 8-). I
basically don't want to "waste" our second and last official BOF without
more evidence that we'll have sufficient implementation progress by August,
and similarly, with sufficient implementation progress it will become a lot
more apparent whether this puppy has enough momentum to go formal WG route
and/or enough simplicity to skip it and go straight to proposed.

- I personally have next to no time to put into organizing a SIEVE BOF for
August, especially if a couple of other expected IETF obligations percolate
up for that meeting.

- all that said, the December meeting isn't too far off, so I don't think
delaying a BOF or a putative WG session until then is terribly harmful.

Comments/reactions...?

We have until August 3 to request a slot, but I'd like to develop a
yes/no/punt consensus now if at all possible. 

- Matt

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Jun 1998 17:13:10 -0700

I agree: no BOF for Chicago.

(I have an implementation of the current draft, by the way.)