http://ds.internic.net/internet-drafts/draft-showalter-sieve-03.txt

>   OPEN:   Are there any other comparators that SHOULD or MUST be
>           supported?

Yes -- POSIX and/or Perl regular expressions

--

-- 
Jeff Garzik			    Typhoon, Cyclone, Diablo, and INN
http://www.spinne.com/usenet/	           News tuning and consulting

http://ds.internic.net/internet-drafts/draft-showalter-sieve-03.txt

At 06:00 PM 5/18/98 -0400, Jeff Garzik wrote:
>>   OPEN:   Are there any other comparators that SHOULD or MUST be
>>           supported?
>
>Yes -- POSIX and/or Perl regular expressions

I thought that we were purposefully staying away from regexs as
they added too much complexity to a simple implementation?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

http://ds.internic.net/internet-drafts/draft-showalter-sieve-03.txt

> X-Sender: "Jack De Winter" <jack <at> wildbear.on.ca>

> Date: Tue, 19 May 1998 12:29:16 -0400
> From: "Jack De Winter" <jack <at> wildbear.on.ca>
> Precedence: bulk
> 
> At 06:00 PM 5/18/98 -0400, Jeff Garzik wrote:
> >>   OPEN:   Are there any other comparators that SHOULD or MUST be
> >>           supported?
> >
> >Yes -- POSIX and/or Perl regular expressions
> 
> I thought that we were purposefully staying away from regexs as
> they added too much complexity to a simple implementation?

We are.

--

-- 
Tim Showalter <tjs+ <at> andrew.cmu.edu>

reply cut from the draft?

As per John Myers suggestion at the IETF, I suggest that Reply be
removed from the draft.  Without a mechanism to prevent looping, or
sending out mail too often (like "vacation" will have), it is too
dangerous; such a mechanism requires on-server storage, and as Ned Freed 
has pointed out, this is not always availible.

--

-- 
Tim Showalter <tjs+ <at> andrew.cmu.edu>

Sieve Attributes in Accounts Dataset

draft-gellens-acap-acnt-00 proposed a "Sieve.Script" attribute in the
Accounts dataset, to contain the Sieve script to be executed against
incoming mail for an account.

I'd like to add optional magic attributes for determining syntax
warnings and errors.  If the server advertises the "Sieve" capability,
it supports the magic attributes.

I'm thinking of four such attributes, one each for the count and text
of syntax warnings and errors.

So, the Sieve-related attributes in \Account would be:

Account.Sieve.Script
Account.Sieve.Syntax.Warnings
Account.Sieve.Syntax.Errors
Account.Sieve.Syntax.WarnText
Account.Sieve.Syntax.ErrText

Does anyone think it would be better to instead make a Sieve subdataset
in the Account dataset?

The Warnings and Errors attributes would be numbers.  The WarnText and
ErrText attributes would be text strings, with a special format.  I'm
thinking of:

"line: <line number>; offset: <offset>; text: <text>"

For example:

Re: Sieve Attributes in Accounts Dataset

At 4:19 PM -0700 5/19/98, I wrote:

>"line: <line number>; offset: <offset>; text: <text>"
>
>For example:
>
>"line: 3; offset: 8; text: semicolon expected"

Oops.  I forgot length.  What I meant was:

"line: <line number>; offset: <offset>; length: <length>; text: <text>"

For example:

"line: 3; offset: 8; length: 4; text: semicolon expected"

The idea is that the UI could highlight characters 8 through 11 of line
3 of the script while displaying the text.

Re: reply cut from the draft?

On 19 May 1998 18:31:53 -0400 Tim Showalter <tjs+ <at> andrew.cmu.edu> wrote:

> As per John Myers suggestion at the IETF, I suggest that Reply be
> removed from the draft.  Without a mechanism to prevent looping, or
> sending out mail too often (like "vacation" will have), it is too
> dangerous; such a mechanism requires on-server storage, and as Ned Freed 
> has pointed out, this is not always availible.

OK, but only if vacation is moved along as part of the primary work of the 
working group then.    This is by far the most useful standardized function 
for all classes of distributed client (POP and IMAP).    There are other ways
to do the other things that SIEVE does, but there is no replacement for 
generating automatic replies and forwards.

---  
Steve Hole                           
The Esys Corporation
Mailto:Steve.Hole <at> esys.ca  
Phone:403-424-4922

Re: Sieve Attributes in Accounts Dataset

On Tue, 19 May 1998 16:19:21 -0700 Randall Gellens <randy <at> qualcomm.com> wrote:

> draft-gellens-acap-acnt-00 proposed a "Sieve.Script" attribute in the
> Accounts dataset, to contain the Sieve script to be executed against
> incoming mail for an account.
> 
> I'd like to add optional magic attributes for determining syntax
> warnings and errors.  If the server advertises the "Sieve" capability,
> it supports the magic attributes.

So the idea is provide a standard place for the sieve interpretter to record 
errors encountered in the script?   If so, why restrict it to syntactic 
errors.   Why not generalize to include executive errors -- a log that the 
client can display to see how things are going.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:Steve.Hole <at> esys.ca  
Phone:403-424-4922

Re: Sieve Attributes in Accounts Dataset

At 7:46 AM -0700 5/20/98, Steve Hole wrote:

>So the idea is provide a standard place for the sieve interpretter to record
>errors encountered in the script?   If so, why restrict it to syntactic
>errors.   Why not generalize to include executive errors -- a log that the
>client can display to see how things are going.

I didn't intend to restrict this to syntax errors; I just wanted to
start there.  That's why I use "Account.Sieve.Syntax.*" -- so that
later on an "Account.Sieve.Execution.*" set of attributes could be
defined.

Also, I wanted to permit an implementation to not ever store the syntax
errors, but instead parse the Sieve script on a store, and return the
syntax errors, although I'm not sure how important that is.

ACAP Profile for Sieve Issues

At DC, it was discussed that a profile of ACAP would be useful for
IMAP.  That is, an IMAP implementation could support only enough ACAP
to handle the mailboxes dataset.

A profile of ACAP would also be useful for Sieve, so a Sieve
implementation could support only enough ACAP to handle the Sieve
related attributes in the Capabilities and Accounts datasets.

One issue that comes up in this is the situation where multiple
accounts do not make sense.  Multiple accounts (multiple entries in the
/Account dataset) are very useful in general, but when a Sieve
implementation uses a profile of ACAP for access, it is likely there is
only one account per user.

We could require the Sieve implementation to be aware of the
"mua.default.account" attribute as well, but I think that adds more
complexity than necessary.

Off the top of my head, I was thinking we could use a tilde to indicate
the default (and maybe only) entry.  So, "/Account/~/~" would be a path
to the default (or only) entry in the Account dataset for the current
user.

Of course, the client would then have to be aware of this, and know to
go to each mail server for its Sieve implementation.

The alternative is to have an active client (or a smart server) map the
entries in the account dataset to the individual mail servers, and copy
the Sieve script there when it is updated.