Subject: a few restrictions on Sieve requirements

From: Tim Showalter <[email-masked]>
Date: Mon, 21 Jun 1999 14:10:28 -0700

I'm proposing the following as nesting limits for a Sieve
implementation.  These are lower limits, and there is no upper bound.

I am adding a new section, 2.10.7, Limits on Execution:

Implementations may limit certain constructs.
However, this specification places a lower bound on some of these
limits.

Implementations MUST support fifteen levels of nested blocks.

Implementations MUST support fifteen levels of nested testlists.

If I recall correctly, ANSI C lets ifs nest fifteen deep.

If anyone has any issues with either of these, please let me know.  If
this is a good idea, and there are other places that need limits, please
let me know as well.

-- Tim

Date: Mon, 21 Jun 1999 14:10:28 -0700
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: a few restrictions on Sieve requirements
Sender: [email-masked]

I'm proposing the following as nesting limits for a Sieve
implementation.  These are lower limits, and there is no upper bound.

I am adding a new section, 2.10.7, Limits on Execution:

Implementations may limit certain constructs.
However, this specification places a lower bound on some of these
limits.

Implementations MUST support fifteen levels of nested blocks.

Implementations MUST support fifteen levels of nested testlists.

If I recall correctly, ANSI C lets ifs nest fifteen deep.

If anyone has any issues with either of these, please let me know.  If
this is a good idea, and there are other places that need limits, please
let me know as well.

-- Tim

Date: Mon, 21 Jun 1999 15:59:22 -0400
From: Matthew Wall <[email-masked]>
To: [email-masked]
cc: Bruce Steinback <[email-masked]>
Subject: Re: Storing filters in LDAP
Originator-Info: login-id=wall; server=imap.cyrusoft.com
Sender: [email-masked]

-- On Thu, Jun 17, 1999 4:11 PM -0700 the entity known as Bruce Steinback
<[email-masked]> wrote:

<begin quote>

> 
> I'd like to proclaim that every script stored in LDAP should have a
> unique name.  Furthermore, this name should be in the script source, and
> can be used to tie it to other parameters.  What I was thinking of was
> having a 'special' comment line at the beginning of the script, e.g.:

<end quote>

To which Matthew Wall offers this response on Mon, 21 Jun 1999 15:48:56
-0400:

This is probably a reasonable approach, but I'd suggest codifying this in
an internet draft as a proposed attribute structure (and description of the
semantics) would be the most useful way of actually getting this out. But
it shouldn't be prescriptive with respect to Sieve syntax, of course (as I
understand it, your proposal is more in the lines of giving advice to the
LDAP.) I'm not sure making a Sieve script requirement to have a special
name in a comment -- which turns it from a comment into an active element
of syntax. Why not simply establish a convention from the LDAP side that
has no requirements o the Sieve script?

Would you like to volunteer for the ID for 'LDAP storage of Sieve scripts'?
8-)

> Any thoughts?  Indeed, any
> thoughts on script storage in general?

we're storing sieve scripts in ACAP/IMSP, and also working with another
implementation that uses an http get/put. We'll also add modules for other
transports as necessary (including LDAP). In general, the intent was to be
non-specific about any particular storage/transport format in the interests
of wider interoperability, and more to the point, wider applicability. I
think it's best to maintain that general rule of thumb at present. But
certainly within any given transport-storage model, it would be fabulous to
have consistent implementations in the interests of interop.

I think somebody on this list or the ACAP list was proposing some standard
naming conventions, but I don't think this has percolated up. WRT to http
as transport, I'd expect an XML description will ultimately be the most
useful, although we're working with something a bit more mundane at present
so we can work with a particular vendor.

> I was thinking that it might be nice to standardize this, so that any
> client can handle organizing multiple filters, in the spirit of trying
> to make Sieve truly interoperational.

Yah, but with the understanding that many organizations won't want to use
LDAP (or ACAP, or a direct file read/write, or whatever). See comment
above. 

- Matt

Date: 18 Jun 1999 01:43:17 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: CMU Sieve 1.2
Sender: [email-masked]

Now with vacation support.

Ok, as far as I know this implements the very latest in Sieve
specifications.  (Ok, so it doesn't check that some strings should be
addresses, and there's a minor bug in checking whether "require" was
called.)

I'd appreciate any & all thinking.

Larry

Date: Thu, 17 Jun 1999 16:11:22 -0700
From: "Bruce Steinback" <[email-masked]>
To: [email-masked]
Subject: Storing filters in LDAP
Sender: [email-masked]

Well, it's been far too quiet here, so I thought I'd poke on a
peripheral put important matter - script storage.  I haven't seen any
messages on how/where scripts would get stored.  We at Netscape (nee
"The Alliance" but I'll pass on that for now) want to store Sieve
filters in user LDAP entries, but there's a consideration of note.
(Note: people uninterested in LDAP can probably tune out here, but might
want to look briefly at the 'Solution?' section below)

We figure that generally the U/I for Server Side Rules will be that
users select a filter type (e.g. spam rejection, vacation, folder
storage,...) create a rule of that type, and then organize the rules in
order desired to run.  The problem is that this creates a fair amount of
'meta-information' about a filter script that needs to get stored, e.g.
filter type and order to run.  I don't particularly want to store this
info with the script, but there's an annoying problem with LDAP -
there's no inherent way to order attribute values.  That is, if there
are attributes scriptSource and scriptRunOrder, each with three values,
there's no guaranteed order of return, so no way to make sure that the
three values picked from one attribute matches with the other.  e.g.:
given...

scriptSource: (script1)
scriptSource: (script2)
scriptSource: (script3)
scriptRunOrder: 1
scriptRunOrder: 2
scriptRunOrder: 3

There's no way to guarantee that script1 will match up with
scriptRunOrder of 1.

Solution?

I'd like to proclaim that every script stored in LDAP should have a
unique name.  Furthermore, this name should be in the script source, and
can be used to tie it to other parameters.  What I was thinking of was
having a 'special' comment line at the beginning of the script, e.g.:

# !Name=This is my script #1
(script)

Where the "!Name=" identifies the 'special' line.  That can then be used
in other attributes to tie them to the appropriate script: e.g.

scriptRunOrder: 1 = This is my script #1

making sure that the scriptRunOrder of 1 gets associated with "This is
my script #1".

I realize that this isn't perfect, e.g. people who modify LDAP directly
could easily screw up the association by changing a name in just one of
the 'tied' attributes, or putting in a script with no name.  But I think
it's a reasonable solution that makes minimal demands on script format.
I was thinking that it might be nice to standardize this, so that any
client can handle organizing multiple filters, in the spirit of trying
to make Sieve truly interoperational.  Any thoughts?  Indeed, any
thoughts on script storage in general?

    Cheers,

    Bruce