[Top] [All Lists]

Re: Storing filters in LDAP

1999-06-21 12:56:32
-- On Thu, Jun 17, 1999 4:11 PM -0700 the entity known as Bruce Steinback
<bruces(_at_)Netscape(_dot_)COM> 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

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'?

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

- Matt

<Prev in Thread] Current Thread [Next in Thread>