Re: General thoughts on variables

["Mark E. Mallett" <[e-mail]>]

On Wed, Oct 27, 2004 at 09:24:13AM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2004-10-26 at 18:37 -0400, Mark E. Mallett wrote:
> > 
> > You can consult an array of such structures and apply processing
> > generally.  You can even load the array from a file that's separate from
> > your script.  Or you can do all that stuff inline, one at a time.
> 
> exactly.  what's the difference between successive tests on List-Id and
> storing the values in a lookup array?  the representation is different,
> but the information is the same.  this is static, you (or your e-mail
> client) could even generate the Sieve script from a different style
> configuration.

There are some differences; one approach provides expression through
data structures, another through one-at-a-time code steps.  In this
particular case, you can pretty easily enhance the way the data is
applied, or add elements to the data that affect the way the data is
applied, without having to diddle with code.  As you say, it's also
possible to have a utility that generates sieve code from data
structures-- that's a workaround for not being able to express something
directly in sieve, and illustrates the desire for that ability (not
necessarily a desire for it to be in Sieve, though).

There are other potential differences: suppose the language provides
content-addressable arrays or accessed to indexed structures.  One
lookup, one result, rather than chunking through lots of steps one
test at a time.

One drawback of using examples is that you get into tangents about
the specific examples used, instead of the underlying philosophy.
As I mentioned at one point, I don't think it's even possible to
imagine the potential uses that come about when you provide script
writers with powerful building blocks.

Note that I am not saying that all these powerful blocks should go into
Sieve.  I do think there is plenty of room for some of them.  But that's
another tangent..

 
> this thread is the closest we've been a discussion of 3028bis.  why
> don't you post what changes you think we need to the basic grammar to
> allow such a future of Sieve?

Actually I thought that's what the new working group would get into.
I'd be happy to participate in those kinds of talks, even in a more
down-to-earth, sane, and sensible way :-)

-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THfsx0005780; Fri, 29 Oct 2004 10:41:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9THfsmv005779; Fri, 29 Oct 2004 10:41:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9THfnqh005655 for <[e-mail]>; Fri, 29 Oct 2004 10:41:53 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 57788 invoked by uid 101); 29 Oct 2004 13:41:41 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 29 Oct 2004 13:41:41 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: General thoughts on variables
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Oct 27, 2004 at 09:24:13AM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2004-10-26 at 18:37 -0400, Mark E. Mallett wrote:
> > 
> > You can consult an array of such structures and apply processing
> > generally.  You can even load the array from a file that's separate from
> > your script.  Or you can do all that stuff inline, one at a time.
> 
> exactly.  what's the difference between successive tests on List-Id and
> storing the values in a lookup array?  the representation is different,
> but the information is the same.  this is static, you (or your e-mail
> client) could even generate the Sieve script from a different style
> configuration.

There are some differences; one approach provides expression through
data structures, another through one-at-a-time code steps.  In this
particular case, you can pretty easily enhance the way the data is
applied, or add elements to the data that affect the way the data is
applied, without having to diddle with code.  As you say, it's also
possible to have a utility that generates sieve code from data
structures-- that's a workaround for not being able to express something
directly in sieve, and illustrates the desire for that ability (not
necessarily a desire for it to be in Sieve, though).

There are other potential differences: suppose the language provides
content-addressable arrays or accessed to indexed structures.  One
lookup, one result, rather than chunking through lots of steps one
test at a time.

One drawback of using examples is that you get into tangents about
the specific examples used, instead of the underlying philosophy.
As I mentioned at one point, I don't think it's even possible to
imagine the potential uses that come about when you provide script
writers with powerful building blocks.

Note that I am not saying that all these powerful blocks should go into
Sieve.  I do think there is plenty of room for some of them.  But that's
another tangent..

 
> this thread is the closest we've been a discussion of 3028bis.  why
> don't you post what changes you think we need to the basic grammar to
> allow such a future of Sieve?

Actually I thought that's what the new working group would get into.
I'd be happy to participate in those kinds of talks, even in a more
down-to-earth, sane, and sensible way :-)

-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9W9tM078252; Wed, 27 Oct 2004 02:32:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9W9f8078251; Wed, 27 Oct 2004 02:32:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9W865078199 for <[e-mail]>; Wed, 27 Oct 2004 02:32:09 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CMkA1-0002XU-Qu; Wed, 27 Oct 2004 11:32:05 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CMk95-0007ks-Ti; Wed, 27 Oct 2004 11:31:08 +0200
Subject: Re: General thoughts on variables
From: Kjetil Torgrim Homme <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 27 Oct 2004 11:30:59 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On ons, 2004-10-27 at 11:12 +0200, Simon Josefsson wrote:
> Kjetil Torgrim Homme <[e-mail]> writes:
> 
> > none of the competing e-mail filtering languages I know (procmail, MH,
> > Exim-filter) are significantly more expressive than Sieve.  I think that
> > indicates there is no great demand for it.
> 
> No, it indicate that you have no great demand for it.  I have several
> times been forced to chose otherwise less reliable technologies
> (procmail, Perl filters, etc) because Sieve is too limited for my
> needs.

explicit examples would be nice.

> There is a need for a standardized Turing complete mail filtering
> language.  Sieve is pretty close.  I believe it would be better to
> extend Sieve to be Turing complete (in an optional way), than to
> develop a competing solution.  The latter will eventually happen if
> Sieve is not extended.

explicit proposals would be nice.

thanks,
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9TtQC077195; Wed, 27 Oct 2004 02:29:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9Ttpf077194; Wed, 27 Oct 2004 02:29:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9R9TrrP077181 for <[e-mail]>; Wed, 27 Oct 2004 02:29:54 -0700 (PDT) (envelope-from [e-mail])
Received: by kalyani.oryx.com (Postfix, from userid 1005) id 3D9741BDE88; Wed, 27 Oct 2004 11:29:54 +0200 (CEST)
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id DF05A1BDE7F for <[e-mail]>; Wed, 27 Oct 2004 11:29:50 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Wed, 27 Oct 2004 11:31:51 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: General thoughts on variables
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> I have several times been forced to chose otherwise less reliable 
> technologies (procmail, Perl filters, etc) because Sieve is too 
> limited for my needs.

Could you describe your needs on the last two or three occasions? Three 
use cases from somone sane and sensible would be good to have.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9DBFQ069234; Wed, 27 Oct 2004 02:13:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9DB7R069232; Wed, 27 Oct 2004 02:13:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9D322069167 for <[e-mail]>; Wed, 27 Oct 2004 02:13:03 -0700 (PDT) (envelope-from [e-mail])
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMjrb-0004Gp-00 for <[e-mail]>; Wed, 27 Oct 2004 11:13:03 +0200
Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 27 Oct 2004 11:13:03 +0200
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 27 Oct 2004 11:13:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Simon Josefsson <[e-mail]>
Subject: Re: General thoughts on variables
Date: Wed, 27 Oct 2004 11:12:59 +0200
Lines: 18
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
Cancel-Lock: sha1:PZedMLoGLgKckGRK26Hv7Q3E9h4=
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme <[e-mail]> writes:

> none of the competing e-mail filtering languages I know (procmail, MH,
> Exim-filter) are significantly more expressive than Sieve.  I think that
> indicates there is no great demand for it.

No, it indicate that you have no great demand for it.  I have several
times been forced to chose otherwise less reliable technologies
(procmail, Perl filters, etc) because Sieve is too limited for my
needs.

There is a need for a standardized Turing complete mail filtering
language.  Sieve is pretty close.  I believe it would be better to
extend Sieve to be Turing complete (in an optional way), than to
develop a competing solution.  The latter will eventually happen if
Sieve is not extended.

Thanks.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7OZRS019517; Wed, 27 Oct 2004 00:24:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R7OZNX019516; Wed, 27 Oct 2004 00:24:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7OXDt019490 for <[e-mail]>; Wed, 27 Oct 2004 00:24:34 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CMiAY-0006Yg-Sx; Wed, 27 Oct 2004 09:24:30 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CMiAQ-00049d-7i; Wed, 27 Oct 2004 09:24:22 +0200
Subject: Re: General thoughts on variables
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 27 Oct 2004 09:24:13 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2004-10-26 at 18:37 -0400, Mark E. Mallett wrote:
> On Tue, Oct 26, 2004 at 11:04:55PM +0200, Kjetil Torgrim Homme wrote:
> > if the feature is integrated in the language, it can't be disabled.
> 
> Oh, I see what you were getting at- native variables implies more
> complex scripts (or at least scripts that have a higher resource load)
> which may be bad from a system administrator's perspective, vs a
> variables extension which an administrator could choose not to enable.
> But resource issues are resource issues, and language issues are language
> issues; they ought to be addressed on their own.

from a practical viewpoint, it's not only a resource issue, it's also a
security issue -- a complex language will have a complex implementation,
with greater potential for security flaws.  a minimal Sieve
implementation can be written in few lines of code, meaning it can
easily be scrutinised by a security conscious administrator.

> I think if you disagree with typed variables, we are just going to
> disagree, especially as I concede that you can apply operations to
> string variables that interpret them in different ways- although
> that's not my preference.

do you want strong typing?  in most script languages the type is
implicitly cast to string or integer as needed.  since any type can be
expressed as a string, or as a number, it doesn't really matter what
happens behind the curtains, unless you wish to enforce type "safety".

> Structures are useful for anything where you have tuples that you
> want to apply general processing to.  Off the top of my head, you
> might have a set for each mailing list you are on:
> 
>  - list name (inside List-Id, say);
>  - folder to file mail into;
>  - an optional prefix to add to the header;
>  - whether to add a "Mail-Followup-To" header for your local use;
>  - what IMAP flags to set
> 
> etc.
> 
> You can consult an array of such structures and apply processing
> generally.  You can even load the array from a file that's separate from
> your script.  Or you can do all that stuff inline, one at a time.

exactly.  what's the difference between successive tests on List-Id and
storing the values in a lookup array?  the representation is different,
but the information is the same.  this is static, you (or your e-mail
client) could even generate the Sieve script from a different style
configuration.

> I have the attitude that if you provide things like typed variables,
> structures, and fundamental language features, people will use them, and
> you can't always predict the things that people will do with them.  In
> my original note I opined that in an eventual implementation of native
> variables, only one data type might be provided (and of course I had
> strings in mind), but that design should not prevent the eventual
> addition of more types.  (I didn't say it quite that way, but it was
> roughly the same.)

this thread is the closest we've been a discussion of 3028bis.  why
don't you post what changes you think we need to the basic grammar to
allow such a future of Sieve?

> > none of the competing e-mail filtering languages I know (procmail, MH,
> > Exim-filter) are significantly more expressive than Sieve.  I think that
> > indicates there is no great demand for it.
> 
> Really... seems to me that procmail is the poster child for demand for
> extra features.  Most useful procmail scripts do all kinds of piping to
> external programs to do things that can't be done inside procmail.

your view of "useful" is different from mine :-).  I had totally missed
the "var=|program" syntax to set variables based on the message.  I
haven't felt a need for the feature, though.

> Maildrop is a popular delivery language that seems to illustrate
> peoples' desire for more expressive scripting languages.

maildropex(7) includes code for implementing vacation, absolutely
horrific if you ask me.  a friend also wrote YAMPLE which is really Perl
used as a filter language.  fine for a home system, but neither is
suitable for a big e-mail system, IMHO.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R17dAG089709; Tue, 26 Oct 2004 18:07:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R17ddh089708; Tue, 26 Oct 2004 18:07:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9R17YSY089665 for <[e-mail]>; Tue, 26 Oct 2004 18:07:34 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 67850 invoked by uid 101); 26 Oct 2004 21:07:39 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 26 Oct 2004 21:07:39 -0400
To: Philip Guenther <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: General thoughts on variables
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Oct 26, 2004 at 04:47:24PM -0700, Philip Guenther wrote:
> "Mark E. Mallett" <[e-mail]> writes:
> ...
> >Really... seems to me that procmail is the poster child for demand for
> >extra features.  Most useful procmail scripts do all kinds of piping to
> >external programs to do things that can't be done inside procmail.
> 
> Sure, but that's because procmail was designed to be 'extended' via
> the shell, just as sieve was designed to be extended via 'require'.
> That procmail picked a extension method that allows arbitrary
> computation may speak more towards the power of the UNIX tool model
> than the needs of a mail filter.

OK, but I was responding to a remark that gave procmail as evidence that
script writers aren't looking for more features.  My followup was that
they are indeed: they get other features out of pipes and shell escapes.

 
> Indeed, just a most procmail rcfiles invoke formail or $SENDMAIL,
> I would guess that most sieve filters require 'fileinto' or 'vacation'.

Yep.  There are different ways of giving more power to the script
writer, including Sieve-style extensions and shell escapes and pipes.
There are others.


> Is your concern that sieve extensions require more developer or
> admin action than procmail 'extensions'?  Some would consider that
> a feature, not a bug.

I don't have those concerns, that's not really the conversation I was
in.. I think there's a place for both.  I was mainly talking about
variables.


mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QNlKOt071166; Tue, 26 Oct 2004 16:47:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QNlKJI071165; Tue, 26 Oct 2004 16:47:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QNlJGd071159 for <[e-mail]>; Tue, 26 Oct 2004 16:47:19 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id i9QNlPBm008516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 26 Oct 2004 16:47:25 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i9QNlPBm008516
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=EFCw9vyERYgItrt0jzZp3cV92RVyBnIo3Y1Qc0bT5I0vHdaCnt9kOxx4NOtrEhlHQ DKw59YxYn93Zf5WAyIYFXAjfNZjbqi2Ye8drqvUcYZYu5yxrGJe9nF3A3vaXUfTjpms KmF55qC29LsxF5FfCgAxLPC5tIH0ZsCisNMe3lo=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i9QNlOkY097083; Tue, 26 Oct 2004 16:47:24 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: General thoughts on variables 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Tue, 26 Oct 2004 16:47:24 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Mark E. Mallett" <[e-mail]> writes:
...
>Really... seems to me that procmail is the poster child for demand for
>extra features.  Most useful procmail scripts do all kinds of piping to
>external programs to do things that can't be done inside procmail.

Sure, but that's because procmail was designed to be 'extended' via
the shell, just as sieve was designed to be extended via 'require'.
That procmail picked a extension method that allows arbitrary
computation may speak more towards the power of the UNIX tool model
than the needs of a mail filter.

Indeed, just a most procmail rcfiles invoke formail or $SENDMAIL,
I would guess that most sieve filters require 'fileinto' or 'vacation'.

Is your concern that sieve extensions require more developer or
admin action than procmail 'extensions'?  Some would consider that
a feature, not a bug.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMvlX2058604; Tue, 26 Oct 2004 15:57:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QMvlCY058603; Tue, 26 Oct 2004 15:57:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMvlJ7058584 for <[e-mail]>; Tue, 26 Oct 2004 15:57:47 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id i9QMvd1f027397 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 26 Oct 2004 15:57:39 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i9QMvd1f027397
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=GAjMidC0f0HfcF/+kwkeBofjDk4rBsXfbhshCXmLPmHn4hQZCxPitzfPxODMlLW11 b4NOOuxcI+W+OT0D3b074qJS4VrCu4oiz95qhVg5oxsQtuItmL0UFAc4u05791+viBg Twx/u8rOzYtehrVo4b/64K5KVmvQKkjWH2bnbuM=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i9QMvdbY093270; Tue, 26 Oct 2004 15:57:39 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: General thoughts on variables 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Tue, 26 Oct 2004 15:57:38 -0700
From: Philip Guenther <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme <[e-mail]> writes:
...
>none of the competing e-mail filtering languages I know (procmail, MH,
>Exim-filter) are significantly more expressive than Sieve.  I think that
>indicates there is no great demand for it.

Actually, procmail is Turing complete, as it has variables, tests, some
arithmetic, and can loop using rcfiles that recursively 'call'
themselves using SWITCHRC or INCLUDERC.

More interesting is the question of how those capabilities are used.
The only 'wide' use of recursive rcfiles that I know of is a cute little
ditty for counting matches of a regexp in a string (e.g., "how many
commas are in this To: field?"), though it did have more extensive uses
at some places.  Capturing of values via regexp to then refine the logic
of the match or use a supplied value in generating a response or
selecting a folder is common.  The 'arithmetic' is used mostly to
simplify certain complex conditions, though there are setups that use it
for its original purpose of weighted matching.


The MH filtering language (aka slocal or maildelivery) is much less
functional than sieve, having no nested tests, IIRC.  Well, I suppose
you could recursively invoke slocal, but I doubt that was done with any
regularity.  I believe the old 'filter' program that used to be
distributed with ELM was around this same level of complexity.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QMbaG6054703; Tue, 26 Oct 2004 15:37:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QMbaDM054702; Tue, 26 Oct 2004 15:37:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9QMbZwe054696 for <[e-mail]>; Tue, 26 Oct 2004 15:37:35 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 9038 invoked by uid 101); 26 Oct 2004 18:37:40 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 26 Oct 2004 18:37:40 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: General thoughts on variables
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Oct 26, 2004 at 11:04:55PM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2004-10-26 at 16:09 -0400, Mark E. Mallett wrote:
> > On Sat, Oct 23, 2004 at 04:38:04PM +0200, Kjetil Torgrim Homme wrote:
> > > On fre, 2004-10-22 at 16:04 -0400, Mark E. Mallett wrote:
> > > > RFC3028 made this statement:
> > > > 
> > > >    The language is not Turing-complete: it provides no way to write a
> > > >    loop or a function and variables are not provided.
> > > > 
> > > > Yet all of those things have been put on the table in one form or
> > > > another [...]
> > > 
> > > since the proposals are extensions, a system administrator is free to
> > > support them or not.
> > 
> > Nothing to quibble with there; I'm not sure how it relates to what I
> > said, though.
> 
> if the feature is integrated in the language, it can't be disabled.

Oh, I see what you were getting at- native variables implies more
complex scripts (or at least scripts that have a higher resource load)
which may be bad from a system administrator's perspective, vs a
variables extension which an administrator could choose not to enable.
But resource issues are resource issues, and language issues are language
issues; they ought to be addressed on their own.


> > That's fine, but not really related to my remarks.  I prefer operations
> > that are explicit rather than implicit.  So given my druthers I would
> > allow the script writer to apply a function to a string, as opposed to
> > enabling an extension that made all strings automatically subjected to
> > that function.
> 
> that would be a _less_ integrated feature.

What I said, perhaps in a fuzzy way, was that among the things you'd
have in a native implementation of variables is "integration into the
language syntax" rather than being things that were inside of strings.
I didn't say one thing was "more integrated" than another: the
"integration" in that sentence was about the inclusion of variables in
the language grammar.


> > > > PS/Disclaimer: not that a disclaimer is needed, but I have an
> > > > implementation that includes typed variables, compound structures,
> > > > expressions, functions, etc.
> > > 
> > > sounds nice, but what do you actually use these for in your Sieve
> > > scripts?
> > 
> > I have indeed used all of the above-mentioned constructs in delivery
> > scripts.  I'm not sure great examples are important [...]
> 
> I think they are.  I honestly can't think of a use for compound
> structures and typed variables.  (particularily not abstract types,
> which may or may not be implied by those two features.)  that doesn't
> mean I doubt its existence, but without a use case, we shouldn't be
> considering adding to the complexity.

I think if you disagree with typed variables, we are just going to
disagree, especially as I concede that you can apply operations to
string variables that interpret them in different ways- although
that's not my preference.

Structures are useful for anything where you have tuples that you
want to apply general processing to.  Off the top of my head, you
might have a set for each mailing list you are on:

 - list name (inside List-Id, say);
 - folder to file mail into;
 - an optional prefix to add to the header;
 - whether to add a "Mail-Followup-To" header for your local use;
 - what IMAP flags to set

etc.

You can consult an array of such structures and apply processing
generally.  You can even load the array from a file that's separate from
your script.  Or you can do all that stuff inline, one at a time.

I have the attitude that if you provide things like typed variables,
structures, and fundamental language features, people will use them, and
you can't always predict the things that people will do with them.  In
my original note I opined that in an eventual implementation of native
variables, only one data type might be provided (and of course I had
strings in mind), but that design should not prevent the eventual
addition of more types.  (I didn't say it quite that way, but it was
roughly the same.)


> 
> none of the competing e-mail filtering languages I know (procmail, MH,
> Exim-filter) are significantly more expressive than Sieve.  I think that
> indicates there is no great demand for it.

Really... seems to me that procmail is the poster child for demand for
extra features.  Most useful procmail scripts do all kinds of piping to
external programs to do things that can't be done inside procmail.
(There is the fact that the external program is often "formail," which
is part of the procmail package, but I don't think that negates this.)

Maildrop is a popular delivery language that seems to illustrate
peoples' desire for more expressive scripting languages.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QLNIgJ038983; Tue, 26 Oct 2004 14:23:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QLNIpe038982; Tue, 26 Oct 2004 14:23:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QLNHud038974 for <[e-mail]>; Tue, 26 Oct 2004 14:23:17 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CMYml-0006YX-1a; Tue, 26 Oct 2004 23:23:19 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CMYmj-0001Be-7x; Tue, 26 Oct 2004 23:23:17 +0200
Subject: Re: Notes on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 26 Oct 2004 23:23:07 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2004-10-26 at 17:09 -0400, Mark E. Mallett wrote:
> On Sat, Oct 23, 2004 at 05:32:43PM +0200, Kjetil Torgrim Homme wrote:
> > incidentally, if we had a "reverse" operator, users could implement
> > non-greedy themselves:
> > 
> >         set :reverse "pattern" "[*] *"; [...]
> 
> I'm all in favor of giving script writers options, such as a :non-greedy
> option.  I don't really get what your ":reverse" does for "set" though.

it'd reverse the argument before storing it in the variable.  e.g.,
'set :reverse "var" "kram"' would set ${var} to "mark".

(the example was included for fun, to illustrate how arbitrary our
choice is for an implementation, it's a _lousy_ use case for :reverse,
in truth I don't see any utility of such a modifier :-)
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL9jHt036559; Tue, 26 Oct 2004 14:09:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL9jQ4036558; Tue, 26 Oct 2004 14:09:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9QL9hBw036552 for <[e-mail]>; Tue, 26 Oct 2004 14:09:44 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 77616 invoked by uid 101); 26 Oct 2004 17:09:48 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 26 Oct 2004 17:09:48 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: Notes on draft-homme-sieve-variables-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

On Sat, Oct 23, 2004 at 05:32:43PM +0200, Kjetil Torgrim Homme wrote:
> On fre, 2004-10-22 at 16:11 -0400, Mark E. Mallett wrote:
> > These are a few comments on draft-homme-sieve-variables-04 .  In another
> > message, I made some comments about variables in general:  specifically
> > that I'd like to see a time where variables are integrated into the
> > SIEVE language in a more fundamental way.  However I imagine that even
> > assuming anyone else agreed with me, that goal would take some time to
> > reach, and that something like this draft would be more immediately
> > useful.  In making allowance for that farther goal, I'd want to see:
> > 
> >  - This draft and its capability called something other than "variables"
> >    (maybe "stringvars")
> 
> if the capability is integrated, why does the name of an obsolete
> extension matter?

Because terminology and labels are sticky.  If at some point we have two
different things called "variables" there's ambiguity.  Native variables
would have a higher claim to the term; my thought was to reserve that
term for their eventual introduction.  As you can see, though, I don't
really have a better alternative; it's natural to think of these things
as "variables" and I don't have an idea for an equally natural term for
non-native variables.  But the fact that I don't have an answer doesn't
mean I don't think it's an issue :-)  Anyway it was something to point
out; apparently there's not much (any?) agreement with me.


> > >    When a string is evaluated, substrings matching variable-ref SHALL be
> > >    replaced by the value of variable-name.  Only one pass through the
> > >    string SHALL be done.  Variable names are case insensitive, so "foo"
> > >    and "FOO" refer to the same variable.  Unknown variables are replaced
> > >    by the empty string.
> > 
> > I'd strongly prefer case sensitivity here.
> 
> almost all Internet standards are case insensitive, and I don't think it
> is important enough to go against that flow.

I guess I am on the short side of that opinion too :-)

Actually my preference for case sensitivity applies mainly to any future
implemention of native variables, since the trend in languages is for
case sensitivity in variables, and that is what many programmers will be
most comfortable with.  I'm mainly concerned with any precedent set
here.  I realize that RFC3028 specifies that statements (that is, all
tokens) are case-insensitive; I still think that script writers would
want case sensitive native variables.



> > The implication
> > seems to be that namespace-associated variables are read-only; if that's
> > true, might want to make that explicit.
> 
> I don't think we want to restrict them to be read-only, but there needs
> to be a new action if they are to change, since SET disallows setting
> variables in namespaces.

Right, I was just trying to figure out what the namespaces were getting
at.  As you point out, the description of "SET" disallows specifying
a namespace, so my conclusion was that namespace-associated variables
are read-only.


> > I've lost track of the history: what's the reason for "*" expanding
> > greedily?  Is it to be compatible with what regex does?
> 
> yes, I think it would be strange if :matches was non-greedy,
> while :regex was greedy.  you may be right that the improved usability
> is worth it, though.

Yes- it's a problem either way.


> incidentally, if we had a "reverse" operator, users could implement
> non-greedy themselves:
> 
>         set :reverse "pattern" "[*] *";
>         if header :matches "Subject" "*" {
>            set :reverse "subject" "${1}";
>         }
>         if string :matches "${subject}" "${pattern}" {
>            set :reverse "prefix" "${2}";
>            set :reverse "actual_subject" "${1}";
>         }

I'm all in favor of giving script writers options, such as a :non-greedy
option.  I don't really get what your ":reverse" does for "set" though.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL5Be7035852; Tue, 26 Oct 2004 14:05:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL5B0k035851; Tue, 26 Oct 2004 14:05:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL5Af1035837 for <[e-mail]>; Tue, 26 Oct 2004 14:05:10 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CMYVD-0003Bl-5O; Tue, 26 Oct 2004 23:05:11 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CMYV9-00071e-BP; Tue, 26 Oct 2004 23:05:07 +0200
Subject: Re: General thoughts on variables
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 26 Oct 2004 23:04:55 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2004-10-26 at 16:09 -0400, Mark E. Mallett wrote:
> On Sat, Oct 23, 2004 at 04:38:04PM +0200, Kjetil Torgrim Homme wrote:
> > On fre, 2004-10-22 at 16:04 -0400, Mark E. Mallett wrote:
> > > RFC3028 made this statement:
> > > 
> > >    The language is not Turing-complete: it provides no way to write a
> > >    loop or a function and variables are not provided.
> > > 
> > > Yet all of those things have been put on the table in one form or
> > > another [...]
> > 
> > since the proposals are extensions, a system administrator is free to
> > support them or not.
> 
> Nothing to quibble with there; I'm not sure how it relates to what I
> said, though.

if the feature is integrated in the language, it can't be disabled.

> That's fine, but not really related to my remarks.  I prefer operations
> that are explicit rather than implicit.  So given my druthers I would
> allow the script writer to apply a function to a string, as opposed to
> enabling an extension that made all strings automatically subjected to
> that function.

that would be a _less_ integrated feature.

> Anyway, I wouldn't interpret the existence of workarounds as a
> justification of that which has to be gotten around.

if the workaround isn't too painful, the need to do something drastic
isn't so great.

> > > PS/Disclaimer: not that a disclaimer is needed, but I have an
> > > implementation that includes typed variables, compound structures,
> > > expressions, functions, etc.
> > 
> > sounds nice, but what do you actually use these for in your Sieve
> > scripts?
> 
> I have indeed used all of the above-mentioned constructs in delivery
> scripts.  I'm not sure great examples are important [...]

I think they are.  I honestly can't think of a use for compound
structures and typed variables.  (particularily not abstract types,
which may or may not be implied by those two features.)  that doesn't
mean I doubt its existence, but without a use case, we shouldn't be
considering adding to the complexity.

none of the competing e-mail filtering languages I know (procmail, MH,
Exim-filter) are significantly more expressive than Sieve.  I think that
indicates there is no great demand for it.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QK9M1g027995; Tue, 26 Oct 2004 13:09:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QK9MaG027994; Tue, 26 Oct 2004 13:09:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9QK9Lnt027977 for <[e-mail]>; Tue, 26 Oct 2004 13:09:21 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 55803 invoked by uid 101); 26 Oct 2004 16:09:15 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 26 Oct 2004 16:09:15 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: General thoughts on variables
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

On Sat, Oct 23, 2004 at 04:38:04PM +0200, Kjetil Torgrim Homme wrote:
> On fre, 2004-10-22 at 16:04 -0400, Mark E. Mallett wrote:
> > The bottom line is that if we're going to put variables into the
> > language, I'd like to see it done in a fundamental, fully integrated
> > way, while allowing for easy improvement and enhancement.  RFC3028 made
> > this statement:
> > 
> >    The language is not Turing-complete: it provides no way to write a
> >    loop or a function and variables are not provided.
> > 
> > Yet all of those things have been put on the table in one form or
> > another (and I doubt that anyone is really surprised that they'd come
> > up).  Once you've crossed the line to where you want something like
> > variables, you're going to want more and more out of them.
> 
> since the proposals are extensions, a system administrator is free to
> support them or not.  there is no doubt that Sieve scripts with
> "variables" enabled can use more resources than scripts without them.
> on the other hand, a very complex set of simple rules can be a burden on
> the system, too.  managesieve allows the administrator to set limits on
> the size of the filter file, so the administrator can control that
> complexity.  (we have had complaints from users that the default limit
> of 32 KiB in Cyrus is too low.)
> 
> "variables" can reduce load, too, if the user is able to simplify
> hundred rules into a handful.  this probably will only happen if your
> users are predominantly tech savvy, so again, leave the choice to the
> administrator.

Nothing to quibble with there; I'm not sure how it relates to what I
said, though.  Re the large script files: people will indeed create
elaborate and large scripts.  Variables (and other fundamental
constructs) that can give better expression of intent can possibly help.
Then again, giving people more language elements can also result in
larger things built out of those elements.  I don't consider that a
downside if it means they are enabled to do elaborate things with them.


> > Things I would want to see out of the addition of variables to the
> > language include:
> > 
> >  - Integration into the language syntax (e.g. not names enclosed in quotes,
> >    not side-effects of referencing strings);
> 
> I agree with the first, but I don't know what other extensions would
> have use for bare identifiers as arguments.  regarding the second,
> "$foo" is optimised into $foo by Perl's byte code compiler, and probably
> by just about all other script languages.

That's fine, but not really related to my remarks.  I prefer operations
that are explicit rather than implicit.  So given my druthers I would
allow the script writer to apply a function to a string, as opposed to
enabling an extension that made all strings automatically subjected to
that function.  Remember this is not targetted to the variables draft
but is a more global comment.



> >  - Provision for multiple data types (even if only one is initially
> >    specified);
> 
> better support for numeric types would be nice, but Tcl has managed just
> fine with their "everything is a string" approach.  extra actions for
> doing arithmetic on strings can be added later.
> 
> example: result = count * 2 + 1
> CALC "result" ["1", "$count", "2", "*", "+"]
> 
> (no discussions on the merits of RPN, please :-)

OK :-)
(I've had happy experiences with RPN)

Anyway, I wouldn't interpret the existence of workarounds as a
justification of that which has to be gotten around.


> > PS/Disclaimer: not that a disclaimer is needed, but I have an
> > implementation that includes typed variables, compound structures,
> > expressions, functions, etc.
> 
> sounds nice, but what do you actually use these for in your Sieve
> scripts?

I have indeed used all of the above-mentioned constructs in delivery
scripts.  I'm not sure great examples are important (or even possible
without a crystal ball- one can be surprised what people will do with
constructs they are given).  What is important (IMHO) is to provide the
building blocks that makes complex tasks easier.  One can argue about
whether such things belong in sieve; I'm certainly arguing that typed
variables do, at least at some point in the future.  This does not
take anything away from the variables draft, other than wanting to
recognize that native variables should come along at some point.

-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PELMo3042479; Mon, 25 Oct 2004 07:21:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PELM7j042478; Mon, 25 Oct 2004 07:21:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PELLd7042470 for <[e-mail]>; Mon, 25 Oct 2004 07:21:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CM5iq-0001lr-GE; Mon, 25 Oct 2004 16:21:20 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CM5ik-0002w9-5Q; Mon, 25 Oct 2004 16:21:14 +0200
Subject: Re: Notes on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 25 Oct 2004 16:21:01 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 2004-10-23 at 17:32 +0200, Kjetil Torgrim Homme wrote:
> On fre, 2004-10-22 at 16:11 -0400, Mark E. Mallett wrote:
> > >    Numbered variables ${1} through ${9} MUST be supported.  References
> > >    to higher indices than the implementation supports should be treated
> > >    as a syntax error which MUST be discovered at compile-time.
> > 
> > I don't like the mandate that strings have to be inspected at
> > compile time-- a "MAY" would be preferable.
> 
> I don't like the possibility of an error spuriously occuring during
> delivery.

re-reading 2.10.6 of RFC 3028, MUST may seem inappropriate, but on the
other hand, that section allows implementation to not have a
"compile-time" at all.

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OHU118041974; Sun, 24 Oct 2004 10:30:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OHU1wn041973; Sun, 24 Oct 2004 10:30:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OHU0qn041955 for <[e-mail]>; Sun, 24 Oct 2004 10:30:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CLmBz-0005ed-HK; Sun, 24 Oct 2004 19:30:07 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CLmBu-0007Ry-PB; Sun, 24 Oct 2004 19:30:02 +0200
Subject: Re: More comments on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Date: Sun, 24 Oct 2004 19:29:55 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9OHU0qn041968
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On søn, 2004-10-24 at 19:04 +0200, Kjetil Torgrim Homme wrote:
> On Sun, 2004-10-24 at 10:59 -0400, Cyrus Daboo wrote:
> > Actually I was going to suggest to all authors that we use 'SIEVE Email 
> > Filtering' in all titles and abstracts (we can argue about capitalization 
> > of SIEVE if you want...). I think that addresses Ned's point about 
> > clarifying 'sieve' a little better. When we get around to revising the 
> > existing rfc extensions we should change those as well.
> 
> well, it would have to be "e-mail filtering", since this has very little
> to do with enamel :-)

putting a leash on my hobby horse, the obvious solution is of course to
use the form which 3028 and most other e-mail related standards are
using: "mail".  (131 "mail", 3 "email" and 7 "e-mail".)

still a pedant,
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OH4K4D036602; Sun, 24 Oct 2004 10:04:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OH4KFN036601; Sun, 24 Oct 2004 10:04:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OH4IxS036554 for <[e-mail]>; Sun, 24 Oct 2004 10:04:19 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CLln1-0001A5-Sd; Sun, 24 Oct 2004 19:04:19 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CLlmz-0005zg-El; Sun, 24 Oct 2004 19:04:17 +0200
Subject: Re: More comments on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sun, 24 Oct 2004 19:04:07 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2004-10-24 at 10:59 -0400, Cyrus Daboo wrote:
> Actually I was going to suggest to all authors that we use 'SIEVE Email 
> Filtering' in all titles and abstracts (we can argue about capitalization 
> of SIEVE if you want...). I think that addresses Ned's point about 
> clarifying 'sieve' a little better. When we get around to revising the 
> existing rfc extensions we should change those as well.

well, it would have to be "e-mail filtering", since this has very little
to do with enamel :-)

pedantically yours,
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OF00Am008765; Sun, 24 Oct 2004 08:00:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OF00tg008762; Sun, 24 Oct 2004 08:00:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OExwFn008732 for <[e-mail]>; Sun, 24 Oct 2004 07:59:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.3] (pool-68-162-186-92.pitt.east.verizon.net [68.162.186.92]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i9OEXgo3013460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Oct 2004 10:33:44 -0400
Date: Sun, 24 Oct 2004 10:59:56 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: More comments on draft-homme-sieve-variables-04
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Sunday, October 24, 2004 5:09:13 AM EDT +0200 Kjetil Torgrim Homme 
<[e-mail]> wrote:

> 3028 Sieve: A Mail Filtering Language.
> 3431 Sieve Extension: Relational Tests.
> 3598 Sieve Email Filtering -- Subaddress Extension.
> 3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions.
> 3894 Sieve Extension: Copying Without Side Effects.
>
> and then:
>
> XXXX Sieve -- Variables Extension
>
> I've changed it to "Sieve Extension: Variables" to keep it aligned with
> 2 out of 4.

Actually I was going to suggest to all authors that we use 'SIEVE Email 
Filtering' in all titles and abstracts (we can argue about capitalization 
of SIEVE if you want...). I think that addresses Ned's point about 
clarifying 'sieve' a little better. When we get around to revising the 
existing rfc extensions we should change those as well.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O3bD19052209; Sat, 23 Oct 2004 20:37:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O3bDVD052208; Sat, 23 Oct 2004 20:37:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O3bCnl052199 for <[e-mail]>; Sat, 23 Oct 2004 20:37:12 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1CLZBz-0003k0-Vb; Sun, 24 Oct 2004 05:37:16 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CLZBx-0007nq-TS; Sun, 24 Oct 2004 05:37:14 +0200
Subject: Re: More comments on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Sun, 24 Oct 2004 05:09:13 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On fre, 2004-10-22 at 16:28 -0700, [e-mail] wrote:
> Since we seem to be in the mood for comments on variables I have
> a few of my own to make:
> 
> (0) The term "sieve" is used in RFCs to mean several different things;
>     the title of the document should therefore make it clear what "sieve"
>     we're dealing with. I suggest a title change to "Sieve Mail Filtering
>     Language - Variables Extension". I would also suggest a change in the
>     abstract: "filtering rule sets" -> "sieve mail filtering  rule sets".

currently, we have:

3028 Sieve: A Mail Filtering Language.
3431 Sieve Extension: Relational Tests. 
3598 Sieve Email Filtering -- Subaddress Extension.
3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. 
3894 Sieve Extension: Copying Without Side Effects.

and then:

XXXX Sieve -- Variables Extension

I've changed it to "Sieve Extension: Variables" to keep it aligned with
2 out of 4.

> (1) This draft still uses the old copyright/IPR boilerplate; it needs to be
>     updated to use the RFC 3667 stuff. (xml2rfc is your friend here; its
>     a one line change to make it do all the right stuff.)

XML is not my friend during editing :-).  I'm writing it in good old
roff.  probably should have used m4 or something to include the
boilerplate, but I didn't think it'd change so much.

> (2) There are lots of hypenated words in this draft. I don't think the RFC
>     Editor likes them much. You might consider turning off hyphenation in
>     whatever tool you are using.

ok.

> (3) Abstract. "interpolation" -> "intepretation".
> (4) Section 3.2 talks about :regex, which probably means we need a reference
>     to the regex specification. However, I think this can be an informative
>     reference, since you certainly don't need to understand regex in to
>     implement variables. (A normative reference would be bad since it would
>     hold up publication of variables until regex can also be published.)

done.

> (6) Section 3.2: "The wild- cards expand greedily." -> "All :matches wildcards
>     MUST expand greedily."

I don't agree a clarification is needed here, the entire paragraph is
about :matches and nothing else.

> (7) Isn't the precedence ordering in section 4.1 backwards? That is, don't
>     you want to do :lower before you do :upperfirst? That's certainly the
>     effect I'd want, and it appears to be the order the examples call for.
>     Additionally, while it makes no difference in ASCII, it strikes me that
>     if case conversion changed the length of a string you'd want the length
>     of the case-converted result when you specify :length, not the length of
>     what you started with.

"highest value first".  it might be more readable to change this to
"lowest value" and put the table on its head.

> (8) Do we want to make it an error to specify both :lower and :upper, or
>     both :lowerfirst and :upperfirst? Or at least make it legal to return
>     an error in this case?

I don't have a problem with making the behaviour undefined.

> (9) Is 9 numbered variables enough? (It probably is, I just wanted to check
>     and make sure we'll all OK with it.)
> 
> (10) Pointing out that sieves always terminate in the security considerations
>      is good. However, we probably should state that this doesn't preclude
>      the construction of scripts that take a long time to evaluate.

perhaps, but I don't really see what that is.  what do you have in mind?
pathological match patterns?
  
> (11) Might want to have an informative reference to spamtest/virustest in the
>      security considerations section when you talk about how sieve isn't
>      a spam/virus filter facility in and of itself. (Although heaven knows I
>      have lots of customers who use it this way.)

ok.

> (12) When it comes to :count, we probably need to specify what it does to
>      list arguments to string. (This one sure is silly, isn't it?)

it already says: "The count of a string list is the sum of the counts of
the member strings."

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O3K8Hm048613; Sat, 23 Oct 2004 20:20:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O3K8ht048612; Sat, 23 Oct 2004 20:20:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O3K6Dn048595 for <[e-mail]>; Sat, 23 Oct 2004 20:20:07 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CLYvS-0000uk-E2; Sun, 24 Oct 2004 05:20:10 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CLYvQ-00019C-G3; Sun, 24 Oct 2004 05:20:08 +0200
Subject: Re: More comments on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Sun, 24 Oct 2004 05:09:13 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On fre, 2004-10-22 at 16:28 -0700, [e-mail] wrote:
> Since we seem to be in the mood for comments on variables I have
> a few of my own to make:
> 
> (0) The term "sieve" is used in RFCs to mean several different things;
>     the title of the document should therefore make it clear what "sieve"
>     we're dealing with. I suggest a title change to "Sieve Mail Filtering
>     Language - Variables Extension". I would also suggest a change in the
>     abstract: "filtering rule sets" -> "sieve mail filtering  rule sets".

currently, we have:

3028 Sieve: A Mail Filtering Language.
3431 Sieve Extension: Relational Tests. 
3598 Sieve Email Filtering -- Subaddress Extension.
3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. 
3894 Sieve Extension: Copying Without Side Effects.

and then:

XXXX Sieve -- Variables Extension

I've changed it to "Sieve Extension: Variables" to keep it aligned with
2 out of 4.

> (1) This draft still uses the old copyright/IPR boilerplate; it needs to be
>     updated to use the RFC 3667 stuff. (xml2rfc is your friend here; its
>     a one line change to make it do all the right stuff.)

XML is not my friend during editing :-).  I'm writing it in good old
roff.  probably should have used m4 or something to include the
boilerplate, but I didn't think it'd change so much.

> (2) There are lots of hypenated words in this draft. I don't think the RFC
>     Editor likes them much. You might consider turning off hyphenation in
>     whatever tool you are using.

ok.

> (3) Abstract. "interpolation" -> "intepretation".
> (4) Section 3.2 talks about :regex, which probably means we need a reference
>     to the regex specification. However, I think this can be an informative
>     reference, since you certainly don't need to understand regex in to
>     implement variables. (A normative reference would be bad since it would
>     hold up publication of variables until regex can also be published.)

done.

> (6) Section 3.2: "The wild- cards expand greedily." -> "All :matches wildcards
>     MUST expand greedily."

I don't agree a clarification is needed here, the entire paragraph is
about :matches and nothing else.

> (7) Isn't the precedence ordering in section 4.1 backwards? That is, don't
>     you want to do :lower before you do :upperfirst? That's certainly the
>     effect I'd want, and it appears to be the order the examples call for.
>     Additionally, while it makes no difference in ASCII, it strikes me that
>     if case conversion changed the length of a string you'd want the length
>     of the case-converted result when you specify :length, not the length of
>     what you started with.

"highest value first".  it might be more readable to change this to
"lowest value" and put the table on its head.

> (8) Do we want to make it an error to specify both :lower and :upper, or
>     both :lowerfirst and :upperfirst? Or at least make it legal to return
>     an error in this case?

I don't have a problem with making the behaviour undefined.

> (9) Is 9 numbered variables enough? (It probably is, I just wanted to check
>     and make sure we'll all OK with it.)
> 
> (10) Pointing out that sieves always terminate in the security considerations
>      is good. However, we probably should state that this doesn't preclude
>      the construction of scripts that take a long time to evaluate.

perhaps, but I don't really see what that is.  what do you have in mind?
pathological match patterns?
  
> (11) Might want to have an informative reference to spamtest/virustest in the
>      security considerations section when you talk about how sieve isn't
>      a spam/virus filter facility in and of itself. (Although heaven knows I
>      have lots of customers who use it this way.)

ok.

> (12) When it comes to :count, we probably need to specify what it does to
>      list arguments to string. (This one sure is silly, isn't it?)

it already says: "The count of a string list is the sum of the counts of
the member strings."

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O39Xl3046555; Sat, 23 Oct 2004 20:09:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O39XT9046554; Sat, 23 Oct 2004 20:09:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O39Wif046544 for <[e-mail]>; Sat, 23 Oct 2004 20:09:32 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CLYlD-00074V-Po; Sun, 24 Oct 2004 05:09:35 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CLYl9-0000WR-5m; Sun, 24 Oct 2004 05:09:31 +0200
Subject: Re: More comments on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Sun, 24 Oct 2004 05:09:13 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On fre, 2004-10-22 at 16:28 -0700, [e-mail] wrote:
> Since we seem to be in the mood for comments on variables I have
> a few of my own to make:
> 
> (0) The term "sieve" is used in RFCs to mean several different things;
>     the title of the document should therefore make it clear what "sieve"
>     we're dealing with. I suggest a title change to "Sieve Mail Filtering
>     Language - Variables Extension". I would also suggest a change in the
>     abstract: "filtering rule sets" -> "sieve mail filtering  rule sets".

currently, we have:

3028 Sieve: A Mail Filtering Language.
3431 Sieve Extension: Relational Tests. 
3598 Sieve Email Filtering -- Subaddress Extension.
3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. 
3894 Sieve Extension: Copying Without Side Effects.

and then:

XXXX Sieve -- Variables Extension

I've changed it to "Sieve Extension: Variables" to keep it aligned with
2 out of 4.

> (1) This draft still uses the old copyright/IPR boilerplate; it needs to be
>     updated to use the RFC 3667 stuff. (xml2rfc is your friend here; its
>     a one line change to make it do all the right stuff.)

XML is not my friend during editing :-).  I'm writing it in good old
roff.  probably should have used m4 or something to include the
boilerplate, but I didn't think it'd change so much.

> (2) There are lots of hypenated words in this draft. I don't think the RFC
>     Editor likes them much. You might consider turning off hyphenation in
>     whatever tool you are using.

ok.

> (3) Abstract. "interpolation" -> "intepretation".
> (4) Section 3.2 talks about :regex, which probably means we need a reference
>     to the regex specification. However, I think this can be an informative
>     reference, since you certainly don't need to understand regex in to
>     implement variables. (A normative reference would be bad since it would
>     hold up publication of variables until regex can also be published.)

done.

> (6) Section 3.2: "The wild- cards expand greedily." -> "All :matches wildcards
>     MUST expand greedily."

I don't agree a clarification is needed here, the entire paragraph is
about :matches and nothing else.

> (7) Isn't the precedence ordering in section 4.1 backwards? That is, don't
>     you want to do :lower before you do :upperfirst? That's certainly the
>     effect I'd want, and it appears to be the order the examples call for.
>     Additionally, while it makes no difference in ASCII, it strikes me that
>     if case conversion changed the length of a string you'd want the length
>     of the case-converted result when you specify :length, not the length of
>     what you started with.

"highest value first".  it might be more readable to change this to
"lowest value" and put the table on its head.

> (8) Do we want to make it an error to specify both :lower and :upper, or
>     both :lowerfirst and :upperfirst? Or at least make it legal to return
>     an error in this case?

I don't have a problem with making the behaviour undefined.

> (9) Is 9 numbered variables enough? (It probably is, I just wanted to check
>     and make sure we'll all OK with it.)
> 
> (10) Pointing out that sieves always terminate in the security considerations
>      is good. However, we probably should state that this doesn't preclude
>      the construction of scripts that take a long time to evaluate.

perhaps, but I don't really see what that is.  what do you have in mind?
pathological match patterns?
  
> (11) Might want to have an informative reference to spamtest/virustest in the
>      security considerations section when you talk about how sieve isn't
>      a spam/virus filter facility in and of itself. (Although heaven knows I
>      have lots of customers who use it this way.)

ok.

> (12) When it comes to :count, we probably need to specify what it does to
>      list arguments to string. (This one sure is silly, isn't it?)

it already says: "The count of a string list is the sum of the counts of
the member strings."

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NFWtP6091679; Sat, 23 Oct 2004 08:32:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NFWtan091678; Sat, 23 Oct 2004 08:32:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NFWsOR091670 for <[e-mail]>; Sat, 23 Oct 2004 08:32:54 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1CLNsz-0007EM-U5; Sat, 23 Oct 2004 17:32:54 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CLNsx-0006To-FH; Sat, 23 Oct 2004 17:32:51 +0200
Subject: Re: Notes on draft-homme-sieve-variables-04
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Sat, 23 Oct 2004 17:32:43 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On fre, 2004-10-22 at 16:11 -0400, Mark E. Mallett wrote:
> These are a few comments on draft-homme-sieve-variables-04 .  In another
> message, I made some comments about variables in general:  specifically
> that I'd like to see a time where variables are integrated into the
> SIEVE language in a more fundamental way.  However I imagine that even
> assuming anyone else agreed with me, that goal would take some time to
> reach, and that something like this draft would be more immediately
> useful.  In making allowance for that farther goal, I'd want to see:
> 
>  - This draft and its capability called something other than "variables"
>    (maybe "stringvars")

if the capability is integrated, why does the name of an obsolete
extension matter?

>  - The things that this draft calls "variables" be called something
>    else (like, "stringvars").

I can try to add a definition of "variable" to make it clear.  The
introduction now reads in my personal copy:

        Conventions for notations are as in [SIEVE] section 1.1,
        including use of [KEYWORDS] and [ABNF].  The grammar builds on
        the grammar of [SIEVE].  In this document, "character" means a
        [UNICODE] character, which may consist of multiple octets coded
        in [UTF-8], and "variable" is a named reference to data stored
        or read back using the mechanisms of this extension.

> >    When a string is evaluated, substrings matching variable-ref SHALL be
> >    replaced by the value of variable-name.  Only one pass through the
> >    string SHALL be done.  Variable names are case insensitive, so "foo"
> >    and "FOO" refer to the same variable.  Unknown variables are replaced
> >    by the empty string.
> 
> I'd strongly prefer case sensitivity here.

almost all Internet standards are case insensitive, and I don't think it
is important enough to go against that flow.

> You might want to mention that "identifier" is as defined in rfc3028
> (even though this is an extension- it doesn't hurt to be explicit).

the excerpt above addresses this.

> There's not really a lot about namespaces in this draft, other than to
> allow for future state variables associated with extensions (or so it
> appears).  Maybe point out that this document specifies namespace syntax
> only, without addressing anything else about namespaces.

- Future extensions may make internal state available through variables.
+ Namespaces are for future extensions which make internal state
available through variables.

> The implication
> seems to be that namespace-associated variables are read-only; if that's
> true, might want to make that explicit.

I don't think we want to restrict them to be read-only, but there needs
to be a new action if they are to change, since SET disallows setting
variables in namespaces.  one use could be a "scope" extension, so the
user says something like:

        LET "scope.local.myvar" "true"
 
> >    The expanded string MUST use the variable values which are current
> >    when control reaches the statement the string is part of.
> 
> At least one problem with this has already been brought up on the list:
> the interaction between match results and sequential evaluation of
> multiple tests.  It's much more expressive to be able to take advantage
> of the side effects (the match results) within one test statement;
> furthermore it's burdensome on an implementation (especially in terms of
> efficiency) to have to freeze the current match results upon entry to a
> test statement so that those frozen results will be available by each
> step inside that test statement.  I suspect that the goal of this
> prescription is to address deferred actions such as "fileinto" -- and
> that's a good thing.  However, it does introduce these other real
> problems.

the main issue is whether the results are defined or not.  there are no
other natural sequence points than the complete statement.  if this is a
to change, significant amounts of thought has to be put into defining
execution order.  (I'd be glad to be proved wrong, of course.)


> I suppose this is as good a place as any for this comment:  I'm not all
> that comfortable with all strings being automagically eligible for
> interpolation (once this extension's capability is enabled).  It seems
> to me that it would be better to have a syntax that specifically
> commands that the string be processed.

we have that, if the string contains "${", it should be processed.  a
bytecode compiler can do this trivially, and store the two types of
strings differently.

> e.g., with some character before the opening quote:
> 
>     fileinto ?"${1}";
> 
> or via other different quoting style.  A bonus would be a syntax that
> allows one or more rescannings of the resulting string.

I'm not sure that is a bonus :-)

> >    For ":matches", the list will contain one string for each wildcard
> >    ("?" and "*") in the match pattern.  Each string holds what the cor-
> >    responding wildcard expands to, possibly the empty string.  The wild-
> >    cards expand greedily.
> 
> I've lost track of the history: what's the reason for "*" expanding
> greedily?  Is it to be compatible with what regex does?

yes, I think it would be strange if :matches was non-greedy,
while :regex was greedy.  you may be right that the improved usability
is worth it, though.

incidentally, if we had a "reverse" operator, users could implement
non-greedy themselves:

        set :reverse "pattern" "[*] *";
        if header :matches "Subject" "*" {
           set :reverse "subject" "${1}";
        }
        if string :matches "${subject}" "${pattern}" {
           set :reverse "prefix" "${2}";
           set :reverse "actual_subject" "${1}";
        }

> >    Numbered variables ${1} through ${9} MUST be supported.  References
> >    to higher indices than the implementation supports should be treated
> >    as a syntax error which MUST be discovered at compile-time.
> 
> I don't like the mandate that strings have to be inspected at
> compile time-- a "MAY" would be preferable.

I don't like the possibility of an error spuriously occuring during
delivery.

> >    The introduction of variables makes advanced decision making easier
> >    to write, but since no looping construct is provided, all Sieve
> >    scripts will terminate orderly.
> 
> "orderly" is not an adverb :-)

strangely so.

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NEcMOi088509; Sat, 23 Oct 2004 07:38:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NEcMbc088508; Sat, 23 Oct 2004 07:38:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NEcLJm088500 for <[e-mail]>; Sat, 23 Oct 2004 07:38:22 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CLN29-0006Wq-Ed; Sat, 23 Oct 2004 16:38:17 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1CLN25-0005eF-Qa; Sat, 23 Oct 2004 16:38:13 +0200
Subject: Re: General thoughts on variables
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Sat, 23 Oct 2004 16:38:04 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 (2.0.1-0.mozer.2) 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On fre, 2004-10-22 at 16:04 -0400, Mark E. Mallett wrote:
> The bottom line is that if we're going to put variables into the
> language, I'd like to see it done in a fundamental, fully integrated
> way, while allowing for easy improvement and enhancement.  RFC3028 made
> this statement:
> 
>    The language is not Turing-complete: it provides no way to write a
>    loop or a function and variables are not provided.
> 
> Yet all of those things have been put on the table in one form or
> another (and I doubt that anyone is really surprised that they'd come
> up).  Once you've crossed the line to where you want something like
> variables, you're going to want more and more out of them.

since the proposals are extensions, a system administrator is free to
support them or not.  there is no doubt that Sieve scripts with
"variables" enabled can use more resources than scripts without them.
on the other hand, a very complex set of simple rules can be a burden on
the system, too.  managesieve allows the administrator to set limits on
the size of the filter file, so the administrator can control that
complexity.  (we have had complaints from users that the default limit
of 32 KiB in Cyrus is too low.)

"variables" can reduce load, too, if the user is able to simplify
hundred rules into a handful.  this probably will only happen if your
users are predominantly tech savvy, so again, leave the choice to the
administrator.

> Things I would want to see out of the addition of variables to the
> language include:
> 
>  - Integration into the language syntax (e.g. not names enclosed in quotes,
>    not side-effects of referencing strings);

I agree with the first, but I don't know what other extensions would
have use for bare identifiers as arguments.  regarding the second,
"$foo" is optimised into $foo by Perl's byte code compiler, and probably
by just about all other script languages.

>  - Provision for multiple data types (even if only one is initially
>    specified);

better support for numeric types would be nice, but Tcl has managed just
fine with their "everything is a string" approach.  extra actions for
doing arithmetic on strings can be added later.

example: result = count * 2 + 1
CALC "result" ["1", "$count", "2", "*", "+"]

(no discussions on the merits of RPN, please :-)

>  - Operations on variables including expressions and comparisons.

we have comparisons, although the comparator name is long and awkward.

> if not:
> 
>  - Compound/complex types;

hmm.

>  - scoping.

can be added later if needed.

> i.e., things that one would expect of variables in a language.

> PS/Disclaimer: not that a disclaimer is needed, but I have an
> implementation that includes typed variables, compound structures,
> expressions, functions, etc.

sounds nice, but what do you actually use these for in your Sieve
scripts?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNTQKD038935; Fri, 22 Oct 2004 16:29:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MNTQEQ038934; Fri, 22 Oct 2004 16:29:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNTPA2038928 for <[e-mail]>; Fri, 22 Oct 2004 16:29:26 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 22 Oct 2004 16:29:30 -0700 (PDT)
Date: Fri, 22 Oct 2004 16:28:14 -0700 (PDT)
From: [e-mail]
Subject: More comments on draft-homme-sieve-variables-04
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since we seem to be in the mood for comments on variables I have
a few of my own to make:

(0) The term "sieve" is used in RFCs to mean several different things;
    the title of the document should therefore make it clear what "sieve"
    we're dealing with. I suggest a title change to "Sieve Mail Filtering
    Language - Variables Extension". I would also suggest a change in the
    abstract: "filtering rule sets" -> "sieve mail filtering  rule sets".
    
(1) This draft still uses the old copyright/IPR boilerplate; it needs to be
    updated to use the RFC 3667 stuff. (xml2rfc is your friend here; its
    a one line change to make it do all the right stuff.)

(2) There are lots of hypenated words in this draft. I don't think the RFC
    Editor likes them much. You might consider turning off hyphenation in
    whatever tool you are using.

(3) Abstract. "interpolation" -> "intepretation".

(4) Section 3.2 talks about :regex, which probably means we need a reference
    to the regex specification. However, I think this can be an informative
    reference, since you certainly don't need to understand regex in to
    implement variables. (A normative reference would be bad since it would
    hold up publication of variables until regex can also be published.)

(6) Section 3.2: "The wild- cards expand greedily." -> "All :matches wildcards
    MUST expand greedily."

(7) Isn't the precedence ordering in section 4.1 backwards? That is, don't
    you want to do :lower before you do :upperfirst? That's certainly the
    effect I'd want, and it appears to be the order the examples call for.
    Additionally, while it makes no difference in ASCII, it strikes me that
    if case conversion changed the length of a string you'd want the length
    of the case-converted result when you specify :length, not the length of
    what you started with.

(8) Do we want to make it an error to specify both :lower and :upper, or
    both :lowerfirst and :upperfirst? Or at least make it legal to return
    an error in this case?

(9) Is 9 numbered variables enough? (It probably is, I just wanted to check
    and make sure we'll all OK with it.)

(10) Pointing out that sieves always terminate in the security considerations
     is good. However, we probably should state that this doesn't preclude
     the construction of scripts that take a long time to evaluate.
  
(11) Might want to have an informative reference to spamtest/virustest in the
     security considerations section when you talk about how sieve isn't
     a spam/virus filter facility in and of itself. (Although heaven knows I
     have lots of customers who use it this way.)

(12) When it comes to :count, we probably need to specify what it does to
     list arguments to string. (This one sure is silly, isn't it?)

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNPvni038525; Fri, 22 Oct 2004 16:25:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MNPvVd038524; Fri, 22 Oct 2004 16:25:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNPuYS038518 for <[e-mail]>; Fri, 22 Oct 2004 16:25:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 22 Oct 2004 16:26:00 -0700 (PDT)
Date: Fri, 22 Oct 2004 16:22:00 -0700 (PDT)
From: [e-mail]
Subject: Re: Notes on draft-homme-sieve-variables-04
In-reply-to: "Your message dated Fri, 22 Oct 2004 18:26:39 -0400" <[e-mail]>
To: "\"\" Mark E. Mallett \"\"" <[e-mail]>
Cc: [e-mail], "\"\"  Mark E. Mallett  \"\"" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Fri, Oct 22, 2004 at 01:46:02PM -0700, [e-mail] wrote:
> > > I suppose this is as good a place as any for this comment:  I'm not all
> > > that comfortable with all strings being automagically eligible for
> > > interpolation (once this extension's capability is enabled).  It seems
> > > to me that it would be better to have a syntax that specifically
> > > commands that the string be processed. e.g., with some character before
> > > the opening quote:
> >
> > >     fileinto ?"${1}";
> >
> > > or via other different quoting style.  A bonus would be a syntax that
> > > allows one or more rescannings of the resulting string.
> >
> > I think having this as a global setting is sufficient. You either
> > require variables and get the effect or you don't and the effect is absent.

> That was the thing that I was attempting to find a cure for.. the
> necessity of interpolating every single string once the capability has
> been enabled.  "require variables" isn't really a global setting,
> in that you can't unset it.

> I would imagine that in most scripts, very few strings will have
> variable references.  It simply strikes me as wasteful to process all of
> them for interpolation just for the few that need it; plus it's just my
> inclination to want such processing to be explicit rather than implicit.
> (with the emphasis on the latter, really- as the extra processing
> probably isn't major.)  None of the alternatives that I could think of
> were all that attractive to me though, including the one of
> interpolating all strings all the time.  But I figured I'd throw it
> out there.

Having implemented this, I can assure you that the waste involved is
insignificant compared to other costs in implementing sieve.

> > > >    For ":matches", the list will contain one string for each wildcard
> > > >    ("?" and "*") in the match pattern.  Each string holds what the cor-
> > > >    responding wildcard expands to, possibly the empty string.  The wild-
> > > >    cards expand greedily.
> >
> > > I've lost track of the history: what's the reason for "*" expanding
> > > greedily?  Is it to be compatible with what regex does?  My preference
> > > (both in terms of what I'd expect and in terms of what is efficient to
> > > implement) is the opposite.  For example, let's say you have:
> >
> > I'm afraid I don't buy your efficiency claims here. I can write efficient
> > greedy globbing code and I can write inefficient non-greedy globbing code.

> What I was thinking of here was that some implementations (including the
> one I am most familiar with) have a local hack or extension to allow
> tests on the message body.  And in time, when there are extensions to
> support body and MIME part tests, existing match semantics will likely
> be used.  Doing a search in a message body, some of which may be cached
> on disk, would be better done non-greedily.  The efficiency of matches
> on header strings is probably not all that big of a factor.

Interesting point. I hadn't considered body tests.

> As for the utility of greedy ":matches" in scripts, I tend to think
> non-greedy is more useful, but would welcome being educated by
> examples of why that's not the case.

Well, greedy matches get some of the nested parens cases "more right"
than non-greedy. But again, I'm a bit ambivalent about whether or not
greedy is the right way to go.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MMQZ7Q028550; Fri, 22 Oct 2004 15:26:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MMQZWc028549; Fri, 22 Oct 2004 15:26:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MMQYxm028527 for <[e-mail]>; Fri, 22 Oct 2004 15:26:35 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 12367 invoked by uid 101); 22 Oct 2004 18:26:39 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 22 Oct 2004 18:26:39 -0400
To: [e-mail]
Cc: " Mark E. Mallett " <[e-mail]>, [e-mail]
Subject: Re: Notes on draft-homme-sieve-variables-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 22, 2004 at 01:46:02PM -0700, [e-mail] wrote:
> > I suppose this is as good a place as any for this comment:  I'm not all
> > that comfortable with all strings being automagically eligible for
> > interpolation (once this extension's capability is enabled).  It seems
> > to me that it would be better to have a syntax that specifically
> > commands that the string be processed. e.g., with some character before
> > the opening quote:
> 
> >     fileinto ?"${1}";
> 
> > or via other different quoting style.  A bonus would be a syntax that
> > allows one or more rescannings of the resulting string.
> 
> I think having this as a global setting is sufficient. You either 
> require variables and get the effect or you don't and the effect is absent.

That was the thing that I was attempting to find a cure for.. the
necessity of interpolating every single string once the capability has
been enabled.  "require variables" isn't really a global setting,
in that you can't unset it.

I would imagine that in most scripts, very few strings will have
variable references.  It simply strikes me as wasteful to process all of
them for interpolation just for the few that need it; plus it's just my
inclination to want such processing to be explicit rather than implicit.
(with the emphasis on the latter, really- as the extra processing
probably isn't major.)  None of the alternatives that I could think of
were all that attractive to me though, including the one of
interpolating all strings all the time.  But I figured I'd throw it
out there.


> > >    For ":matches", the list will contain one string for each wildcard
> > >    ("?" and "*") in the match pattern.  Each string holds what the cor-
> > >    responding wildcard expands to, possibly the empty string.  The wild-
> > >    cards expand greedily.
> 
> > I've lost track of the history: what's the reason for "*" expanding
> > greedily?  Is it to be compatible with what regex does?  My preference
> > (both in terms of what I'd expect and in terms of what is efficient to
> > implement) is the opposite.  For example, let's say you have:
> 
> I'm afraid I don't buy your efficiency claims here. I can write efficient
> greedy globbing code and I can write inefficient non-greedy globbing code.

What I was thinking of here was that some implementations (including the
one I am most familiar with) have a local hack or extension to allow
tests on the message body.  And in time, when there are extensions to
support body and MIME part tests, existing match semantics will likely
be used.  Doing a search in a message body, some of which may be cached
on disk, would be better done non-greedily.  The efficiency of matches
on header strings is probably not all that big of a factor.

As for the utility of greedy ":matches" in scripts, I tend to think
non-greedy is more useful, but would welcome being educated by
examples of why that's not the case.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MLSWCR015554; Fri, 22 Oct 2004 14:28:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MLSWFR015553; Fri, 22 Oct 2004 14:28:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MLSV0K015546 for <[e-mail]>; Fri, 22 Oct 2004 14:28:32 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 22 Oct 2004 14:28:33 -0700 (PDT)
Date: Fri, 22 Oct 2004 13:46:02 -0700 (PDT)
From: [e-mail]
Subject: Re: Notes on draft-homme-sieve-variables-04
In-reply-to: "Your message dated Fri, 22 Oct 2004 16:11:12 -0400" <[e-mail]>
To: "\"\" Mark E. Mallett \"\"" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> These are a few comments on draft-homme-sieve-variables-04 .  In another
> message, I made some comments about variables in general:  specifically
> that I'd like to see a time where variables are integrated into the
> SIEVE language in a more fundamental way.  However I imagine that even
> assuming anyone else agreed with me, that goal would take some time to
> reach, and that something like this draft would be more immediately
> useful.  In making allowance for that farther goal, I'd want to see:

>  - This draft and its capability called something other than "variables"
>    (maybe "stringvars")

I could not care less what the capability naame is.

>  - The things that this draft calls "variables" be called something
>    else (like, "stringvars").

This strikes me as more confusing than useful. It something else comes along it
cann call whatever it defines builtin variables or something similar.

> Other than that, here's some specific stuff about the draft.

> >    When a string is evaluated, substrings matching variable-ref SHALL be
> >    replaced by the value of variable-name.  Only one pass through the
> >    string SHALL be done.  Variable names are case insensitive, so "foo"
> >    and "FOO" refer to the same variable.  Unknown variables are replaced
> >    by the empty string.

> I'd strongly prefer case sensitivity here.

I, OTOH, strongly prefer case insensitivity.

> >
> >
> >       variable-name       =  num-variable / *namespace identifier
> >       namespace           =  identifier "."

> You might want to mention that "identifier" is as defined in rfc3028
> (even though this is an extension- it doesn't hurt to be explicit).

Any time a document inherits ABNF from another document it needs to say so.
So yes, this issue definitely needs to be addressed.

> There's not really a lot about namespaces in this draft, other than to
> allow for future state variables associated with extensions (or so it
> appears).  Maybe point out that this document specifies namespace syntax
> only, without addressing anything else about namespaces.  (Also I'd
> prefer something other than "." as a namespace suffix.)  The implication
> seems to be that namespace-associated variables are read-only; if that's
> true, might want to make that explicit.

Pointing out that namespaces are basically a placeholder is fine and a good
idea. I like dot as a separator; there are other characters I could
live with but also a lot I would object to. I don't think stating that
namespace variables are read-only is a good idea at this point.

> >       num-variable        =  1*DIGIT

> Why limit numbered variables to a single digit?

This doesn't impose such a limit. "1*" means "one or more", not "one".
You'd write "1DIGIT" for "one".

> Some languages have had
> this restriction to help them with parsing, but that's not the case
> here; it's not that much of a trick to distinquish an all-digits
> variable name from one that's not all-digits.

Right, although perhaps banning leading zeroes in the ABNF would be a good idea.
Something like:

    num-variable = 1DIGIT / (%x31-39 1*DIGIT)

> Not that I really see a lot of call for more than 9 match references,
> but I hate that sort of limit- an implementation ought to be able to
> provide more than 9 if it wants to, and limits should be about
> resources rather than syntax.

Again, there's no such limit, although implementations are
allowed to impose a limit if they wish. I wonder if 9 is an
appropriate minimum maximum, however.
 
> >    The expanded string MUST use the variable values which are current
> >    when control reaches the statement the string is part of.

> At least one problem with this has already been brought up on the list:
> the interaction between match results and sequential evaluation of
> multiple tests.  It's much more expressive to be able to take advantage
> of the side effects (the match results) within one test statement;
> furthermore it's burdensome on an implementation (especially in terms of
> efficiency) to have to freeze the current match results upon entry to a
> test statement so that those frozen results will be available by each
> step inside that test statement.  I suspect that the goal of this
> prescription is to address deferred actions such as "fileinto" -- and
> that's a good thing.  However, it does introduce these other real
> problems.

I agree, I can argue this one either way, but I actually prefer the
"numbered variable changes take effect immediately" model.

> >    Tests or actions in future extensions may need to access the unex-
> >    panded version of the string argument and, e.g., do the expansion
> >    after setting variables in its namespace.  The design of the imple-
> >    mentation should allow this.

> I suppose this is as good a place as any for this comment:  I'm not all
> that comfortable with all strings being automagically eligible for
> interpolation (once this extension's capability is enabled).  It seems
> to me that it would be better to have a syntax that specifically
> commands that the string be processed. e.g., with some character before
> the opening quote:

>     fileinto ?"${1}";

> or via other different quoting style.  A bonus would be a syntax that
> allows one or more rescannings of the resulting string.

I think having this as a global setting is sufficient. You either 
require variables and get the effect or you don't and the effect is absent.

I also strongly object to making a syntax change to the language in order
to get this functionality. If we're gonna do that we might as well
make variables first class objects and add a concatenation operator.

> >    For ":matches", the list will contain one string for each wildcard
> >    ("?" and "*") in the match pattern.  Each string holds what the cor-
> >    responding wildcard expands to, possibly the empty string.  The wild-
> >    cards expand greedily.

> I've lost track of the history: what's the reason for "*" expanding
> greedily?  Is it to be compatible with what regex does?  My preference
> (both in terms of what I'd expect and in terms of what is efficient to
> implement) is the opposite.  For example, let's say you have:

I'm afraid I don't buy your efficiency claims here. I can write efficient
greedy globbing code and I can write inefficient non-greedy globbing code.

I think the main reason for greedy globbing is exactly what you say: It
is what people have come to expect. I could live with non-greedy
globbing, although I'd have to change things a bit to support it.

> >    Numbered variables ${1} through ${9} MUST be supported.  References
> >    to higher indices than the implementation supports should be treated
> >    as a syntax error which MUST be discovered at compile-time.

> I don't like the mandate that strings have to be inspected at
> compile time-- a "MAY" would be preferable.

I missed this. I agree 100% with your assessment.

> >    The introduction of variables makes advanced decision making easier
> >    to write, but since no looping construct is provided, all Sieve
> >    scripts will terminate orderly.

> "orderly" is not an adverb :-)

Indeed.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ML0CkM008987; Fri, 22 Oct 2004 14:00:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ML0CVc008986; Fri, 22 Oct 2004 14:00:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9ML0A0i008967 for <[e-mail]>; Fri, 22 Oct 2004 14:00:11 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 79656 invoked by uid 101); 22 Oct 2004 17:00:15 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 22 Oct 2004 17:00:15 -0400
To: Lyndon Nerenberg <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: Notes on draft-homme-sieve-variables-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 22, 2004 at 01:51:36PM -0700, Lyndon Nerenberg wrote:
> --On 2004-10-22 4:11 PM -0400 "Mark E. Mallett" <[e-mail]> wrote:
> 
> >>      num-variable        =  1*DIGIT
> >
> >Why limit numbered variables to a single digit?
> 
> They aren't. That construct means a <num-variable> consists of at least 
> one digit, with no upper bound on the number of DIGITs it can contain. 
> If it was limited to a single digit the ABNF construct would be 1DIGIT.
> See RFC 2234 sections 3.6 and 3.7.

Right, of course- my mistake.  

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MKpj4l007055; Fri, 22 Oct 2004 13:51:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MKpjMG007054; Fri, 22 Oct 2004 13:51:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MKpikx007045 for <[e-mail]>; Fri, 22 Oct 2004 13:51:44 -0700 (PDT) (envelope-from [e-mail])
Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9MKpgYI067435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2004 14:51:44 -0600 (MDT)
Date: Fri, 22 Oct 2004 13:51:36 -0700
From: Lyndon Nerenberg <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: Notes on draft-homme-sieve-variables-04
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On 2004-10-22 4:11 PM -0400 "Mark E. Mallett" <[e-mail]> wrote:

>>       num-variable        =  1*DIGIT
>
> Why limit numbered variables to a single digit?

They aren't. That construct means a <num-variable> consists of at least 
one digit, with no upper bound on the number of DIGITs it can contain. 
If it was limited to a single digit the ABNF construct would be 1DIGIT.
See RFC 2234 sections 3.6 and 3.7.

--lyndon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MKB9Xd097089; Fri, 22 Oct 2004 13:11:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MKB9tY097088; Fri, 22 Oct 2004 13:11:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MKB8Qh097081 for <[e-mail]>; Fri, 22 Oct 2004 13:11:08 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 59826 invoked by uid 101); 22 Oct 2004 16:11:12 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 22 Oct 2004 16:11:12 -0400
To: [e-mail]
Subject: Notes on draft-homme-sieve-variables-04
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

These are a few comments on draft-homme-sieve-variables-04 .  In another
message, I made some comments about variables in general:  specifically
that I'd like to see a time where variables are integrated into the
SIEVE language in a more fundamental way.  However I imagine that even
assuming anyone else agreed with me, that goal would take some time to
reach, and that something like this draft would be more immediately
useful.  In making allowance for that farther goal, I'd want to see:

 - This draft and its capability called something other than "variables"
   (maybe "stringvars")

 - The things that this draft calls "variables" be called something
   else (like, "stringvars").


Other than that, here's some specific stuff about the draft.


>    When a string is evaluated, substrings matching variable-ref SHALL be
>    replaced by the value of variable-name.  Only one pass through the
>    string SHALL be done.  Variable names are case insensitive, so "foo"
>    and "FOO" refer to the same variable.  Unknown variables are replaced
>    by the empty string.

I'd strongly prefer case sensitivity here.


> 
> 
>       variable-ref        =  "${" variable-name "}"
>       variable-name       =  num-variable / *namespace identifier
>       namespace           =  identifier "."

You might want to mention that "identifier" is as defined in rfc3028
(even though this is an extension- it doesn't hurt to be explicit).

There's not really a lot about namespaces in this draft, other than to
allow for future state variables associated with extensions (or so it
appears).  Maybe point out that this document specifies namespace syntax
only, without addressing anything else about namespaces.  (Also I'd
prefer something other than "." as a namespace suffix.)  The implication
seems to be that namespace-associated variables are read-only; if that's
true, might want to make that explicit.



>       num-variable        =  1*DIGIT

Why limit numbered variables to a single digit?  Some languages have had
this restriction to help them with parsing, but that's not the case
here; it's not that much of a trick to distinquish an all-digits
variable name from one that's not all-digits.

Not that I really see a lot of call for more than 9 match references,
but I hate that sort of limit- an implementation ought to be able to
provide more than 9 if it wants to, and limits should be about
resources rather than syntax.


 
>    The expanded string MUST use the variable values which are current
>    when control reaches the statement the string is part of.

At least one problem with this has already been brought up on the list:
the interaction between match results and sequential evaluation of
multiple tests.  It's much more expressive to be able to take advantage
of the side effects (the match results) within one test statement;
furthermore it's burdensome on an implementation (especially in terms of
efficiency) to have to freeze the current match results upon entry to a
test statement so that those frozen results will be available by each
step inside that test statement.  I suspect that the goal of this
prescription is to address deferred actions such as "fileinto" -- and
that's a good thing.  However, it does introduce these other real
problems.



>    Tests or actions in future extensions may need to access the unex-
>    panded version of the string argument and, e.g., do the expansion
>    after setting variables in its namespace.  The design of the imple-
>    mentation should allow this.

I suppose this is as good a place as any for this comment:  I'm not all
that comfortable with all strings being automagically eligible for
interpolation (once this extension's capability is enabled).  It seems
to me that it would be better to have a syntax that specifically
commands that the string be processed. e.g., with some character before
the opening quote:

    fileinto ?"${1}";

or via other different quoting style.  A bonus would be a syntax that
allows one or more rescannings of the resulting string.


 

>    For ":matches", the list will contain one string for each wildcard
>    ("?" and "*") in the match pattern.  Each string holds what the cor-
>    responding wildcard expands to, possibly the empty string.  The wild-
>    cards expand greedily.

I've lost track of the history: what's the reason for "*" expanding
greedily?  Is it to be compatible with what regex does?  My preference
(both in terms of what I'd expect and in terms of what is efficient to
implement) is the opposite.  For example, let's say you have:

    Subject: [filters] how to search for ']' 

I would want this to work:

    if header :matches "subject" "[*]*" {
        set "prefix" "${1}";
	set "actual_subject" "${2}";
    }



>    Numbered variables ${1} through ${9} MUST be supported.  References
>    to higher indices than the implementation supports should be treated
>    as a syntax error which MUST be discovered at compile-time.

I don't like the mandate that strings have to be inspected at
compile time-- a "MAY" would be preferable.



>    The introduction of variables makes advanced decision making easier
>    to write, but since no looping construct is provided, all Sieve
>    scripts will terminate orderly.

"orderly" is not an adverb :-)

Yours,
mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MK4sgW095865; Fri, 22 Oct 2004 13:04:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MK4sBl095864; Fri, 22 Oct 2004 13:04:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MK4qNw095827 for <[e-mail]>; Fri, 22 Oct 2004 13:04:53 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 56812 invoked by uid 101); 22 Oct 2004 16:04:53 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 22 Oct 2004 16:04:53 -0400
To: [e-mail]
Subject: General thoughts on variables
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi-

I've been musing about the draft-homme-sieve-variables draft for
quite some time.  I've got two sorts of comments:

 1. About the approach taken to variables vs what I'd like to see;
 2. Specific comments about the draft.

#1 is kind of hard to get into, and seems contentious, so I've held off.

but #2 is hard to do without first having done #1, so here goes a
somewhat disorganized stab at the first.  Specific comments on the draft
will be in another message.

The bottom line is that if we're going to put variables into the
language, I'd like to see it done in a fundamental, fully integrated
way, while allowing for easy improvement and enhancement.  RFC3028 made
this statement:

   The language is not Turing-complete: it provides no way to write a
   loop or a function and variables are not provided.

Yet all of those things have been put on the table in one form or
another (and I doubt that anyone is really surprised that they'd come
up).  Once you've crossed the line to where you want something like
variables, you're going to want more and more out of them.

I do appreciate the goals behind the draft-homme-sieve-variables
approach, and I would support it for what it is, but it really only adds
variables to the language in a roundabout way, and only for very limited
string substitution purposes (a la very simple shell variables).
Language evolution will eventually call for more, as will script
writers.  So I say let's allow for the language to grow to the point
where it has real variables, and not do something now that makes that
harder later.  This doesn't mean that I want to shelve the draft;
just adjust some of the terms.  (See #2 message.)

Things I would want to see out of the addition of variables to the
language include:

 - Integration into the language syntax (e.g. not names enclosed in quotes,
   not side-effects of referencing strings);
 - Provision for multiple data types (even if only one is initially
   specified);
 - Operations on variables including expressions and comparisons.

if not:

 - Compound/complex types;
 - scoping.

i.e., things that one would expect of variables in a language.

One interesting thing about this draft is that it really doesn't get in
the way of the sort of native variables I'd like to see.  The furthest
it goes is to preempt the use of the word "variable" -- it's called
"variables," and it calls things "variables."  So one of my suggestions
is to use different words for this draft.

Anyway, that's more or less the executive summary..

-mm-

PS/Disclaimer: not that a disclaimer is needed, but I have an
implementation that includes typed variables, compound structures,
expressions, functions, etc.  However, I don't think this prejudices me
against this draft, since (a) I can easily implement the draft without
disrupting my implementation, and (b) I think a fuller specification of
native SIEVE variables *would* be disruptive to mine.  (i.e. by arguing
for a different SIEVE variables spec, I'm would be arguing for a lot
more work for my implementation to adapt to it.)  And I suppose (c) my
attempt was to implement other language features outside of SIEVE
constructs as much as possible.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EKdDih051620; Thu, 14 Oct 2004 13:39:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EKdDln051619; Thu, 14 Oct 2004 13:39:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EKdAXK051602 for <[e-mail]>; Thu, 14 Oct 2004 13:39:13 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i9EKEOo3023251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 14 Oct 2004 16:14:25 -0400
Date: Thu, 14 Oct 2004 16:39:08 -0400
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Status and BOF Agenda
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========195433831FDB9F8CC04D=========="
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--==========195433831FDB9F8CC04D==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
The proposed WG charter is in the hands of the ADs right now and going 
through the WG setup review process. That will likely not be complete 
before the meeting next month in Washington, DC, so the ADs have agreed 
that we can hold a proper BOF meeting there (as opposed to our traditional 
ad-hoc lunch BOFs).

I have attached a proposed BOF agenda to this message - please review and 
send comments asap as we want to make sure we get a time slot. Given the 
amount we have to do I am proposing a 2 hour slot, if we can get one.

I will in the next day or so start posting messages to kick off work we 
need to start doing - particularly the base spec revision.

-- 
Cyrus Daboo
--==========195433831FDB9F8CC04D==========
Content-Type: text/plain; charset=us-ascii; name="BOF agenda"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

SIEVE Mail Filtering BOF
IETF-61 Washington, DC

Chairs: Cyrus Daboo <[e-mail]>
        Alexey Melnikov <[e-mail]>
Mailing list: [e-mail]>
Subscriptions: mailto:[e-mail]?body=subscribe
List archive: http://www.imc.org/ietf-mta-filters/mail-archive/

Agenda

- Introduction (blue sheets, scribe etc)    (1 min)
- Agenda Bashing                            (3 mins)
- WG Status                                 (1 mins)
- Base spec discussion                      (25 mins)
- Existing extension discussion             (20 mins)
- Variables draft (start WG last call?)     (15 mins)
- Vacation draft (start WG last call?)      (10 mins)
- IMAP Flags                                (10 mins)
- Body test draft                           (5 mins)
- Regex draft                               (5 mins)
- MIME part tests                           (5 mins)
- Notify draft                              (5 mins)
- Edit header draft                         (5 mins)
- Reject draft                              (5 mins)
- Other business                            (5 mins)

Total                                       120 mins

Please attempt to avoid conflicts with the following:

SASL, IMAPEXT, LDAPbis, Kerberos.


--==========195433831FDB9F8CC04D==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EtJSF020756; Tue, 5 Oct 2004 07:55:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95EtJQU020755; Tue, 5 Oct 2004 07:55:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95EtITJ020748 for <[e-mail]>; Tue, 5 Oct 2004 07:55:18 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 5765 invoked by uid 101); 5 Oct 2004 10:55:20 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 5 Oct 2004 10:55:20 -0400
To: Cyrus Daboo <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 01, 2004 at 01:47:28PM -0400, Cyrus Daboo wrote:
> Hi Mark,
> 
> --On Friday, October 1, 2004 1:00 PM -0400 "Mark E. Mallett" 
> <[e-mail]> wrote:
> 
> >>(2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598),
> >>    spamtest/virustest (RFC 3685), and copy extension specifications,
> >
> >The "copy extensions specifications" being "draft-degener-sieve-copy" ?
> >Why is it listed in (2) and not in (3)?  (not that it really matters I
> >guess, just wanted to make sure it's included...)
> 
> That draft is currently in the RFC Editor queue waiting to be published, 
> and hopefully will be very soon - so it is correct to put it under (2) 
> thought there is no RFC number assigned to it right now.

Ah... thanks.  Saw the notice yesterday, in fact: RFC3894

   ftp://ftp.rfc-editor.org/in-notes/rfc3894.txt

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94JfnN4002352; Mon, 4 Oct 2004 12:41:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94JfnYD002351; Mon, 4 Oct 2004 12:41:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94JfjOw002318 for <[e-mail]>; Mon, 4 Oct 2004 12:41:48 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: 2PUFYDBKyx8lVUsaVQgaNg 1096918906
Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend1.messagingengine.com (Postfix) with ESMTP id 790B2C2F4B7; Mon,  4 Oct 2004 15:41:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 04 Oct 2004 12:43:43 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: Mark Shewmaker <[e-mail]>
Subject: "refuse" - wording from a MARID post.
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello.  What follows is from a post to the IETF's MARID mailing list.  
It seems relevant to the "refuse" I-D.
The "Disallow some message recipients" method is well described and 
justified, IMO.

Previous Subject: "Re: TECH-OMISSION: Legal liability for creating 
bounces from forged messages."

On 8/31/2004 2:39 AM, Mark Shewmaker <mark primefactor com> sent forth 
electrons to convey:

>...
>Then let me reword:
>
>=====================================================================
>
>6.5 Vulnerability to unintended participation in Forged DSN attacks.
>
>This vulnerability exists if local policy settings allow for a situation
>in which all of the following are true:
>
>  -  A message is sent to multiple recipients,
>
>  -  The recipients have differing local policy settings
>     with respect to message body requirements,
>
>  -  An ultimate determination of per-recipient nondeliverability
>     cannot be communicated within the SMTP session after the receipt
>     of message data, and
>
>  -  The Return Path is forged,
>
>An attacker can take advantage of this vulnerability by using any
>machine with detectably differing local policy settings as an apparent
>source of the attacker's forged DSNs.
>
>Not only does this mean the ultimate victims will receive forged DSNs,
>but the machine the attacker used to accomplish the forgery may become
>known as a source of forged DSNs.
>
>An MTA can completely avoid becoming a participant in this type of DSN
>attack by preventing any of the above listed requirements from
>occuring.  That is, it could do any of the following:
>
>  -  Disallow some message recipients.
>  -  Disallow local policy settings which depend on message contents.
>  -  Disable sending of DSNs.
>
>Each option has downsides.  The first option would require addition
>message transmission attempts, the second option would limit desirable
>functionality, and the third would hide email to become less reliable by
>hiding legitimate email problems.
>
>However, the first option is the only one which does not actually limit
>mail system functionality, making it the only real option to consider.
>
>To expand upon the first option, an MTA can completely avoid becoming a
>participant in this type of DSN attack in all cases by:
>
>  Whenever all of the following is true:
>
>  -  An incoming message is addressed to multiple participants.
>
>  -  Those participants have local policy settings that,
>     given the context of the specifics of the MTA transaction
>     mean that per-recipient final determinations of nondeliverability
>     cannot be communicated until after the message has been accepted
>     for delivery.
>
>  -  The MTA has not positively validated the MAIL FROM address to
>     its satisfaction,
>
>  Then:
>
>  -  The MTA should give temporary rejections at "RCPT TO:" time
>     to all recipients with differing message-body-related local policy 
>     settings and where the recipients have not already been temporarily
>or permanently rejected for other reasons, thus accepting only a
>     compatible subset of  recipients and avoiding the need to create 
>     DSNs at all.
>
>     It is suggested that the MTA reject these recipients with a
>     return code of 4.7.6.
>
>     (Note that the MTA is not rejecting on the basis of too many
>     recipients, rather it is rejecting on the basis of a
>     security-related incompatibility in the requested recipient list.)
>
>  
>
Ok that's what I wanted to post.
(The post continues below, with 2 points that I think may depend on 
unwarranted trust assumptions, followed by some good points.

>Given special-case conditions, there are simpler, alternative ways an
>MTA can completely avoid becoming a participant in a DSN attack:
>
>-  If the client MTA sends a "SUBMITTER" parameter to the MAIL command,
>   then no per-recipient policy that addresses functionality related to
>   this standard can trigger this vulnerability.  If per-recipient
>   policy settings only extend to functionality related to this 
>   standard, then the above recipient-rejection workaround need not be 
>   used for that SMTP transaction.
>
>-  If the server MTA obtains positive validation of the MAIL FROM
>   address for a particular SMTP transaction, then for that SMTP
>   transaction the server MTA need not use the recipient-rejection
>   workaround given above.
>
>-  If a future SMTP extension allows for per-recipient after-DATA
>   rejects, and an SMTP session makes use of such an extension, then
>   the above workaround is not needed for that session.
>
>Avoiding the receipt of forged DSNs is generally outside the scope of
>this document, however a domain that signs outgoing messages in a
>recognizable way can avoid at least some types of forged DSN attacks.
>
>Note that this workaround will not prevent DSN attacks if your domain
>authorizes messages to be received by any other MTA, such as a border or
>secondary MTA, and that other MTA does not do the exact set of checks as
>the final MTA or checks more stringent than the final MTA.  The reason
>is that when the border MTA relays the message to final MTA, even if it
>rejects the message, the border MTA will then create a DSN which would
>be sent to an inappropriate party if the Return Path is forged.
>
>This second type of forged DSN attack can be avoided by ensuring that
>all other MTAs your domain authorizes to receive mail do the same set of
>checks.  Border and secondary MTAs can do a more stringent set of checks
>than final MTAs, as long as there is never a relay from an MTA with
>less-stringent tests to an MTA with more-stringent tests.
>
>=====================================================================
>
)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i923XRkh078305; Fri, 1 Oct 2004 20:33:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i923XRvi078304; Fri, 1 Oct 2004 20:33:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i923XQGJ078297 for <[e-mail]>; Fri, 1 Oct 2004 20:33:26 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 01 Oct 2004 20:25:04 -0700 (PDT)
Date: Fri, 01 Oct 2004 20:23:43 -0700 (PDT)
From: [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
In-reply-to: "Your message dated Fri, 01 Oct 2004 13:00:28 -0400" <[e-mail]>
To: "\"\" Mark E. Mallett \"\"" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Fri, Sep 24, 2004 at 04:13:41PM -0700, [e-mail] wrote:

> ...

> Also the "draft-daboo-sieve-include" draft is not mentioned (which is OK
> with me -- I didn't care for the include draft the way it was but think
> that some kind of include facility is important).  I'm assuming it's
> left out because of the lack of "willingness to implement" that you
> said later, but again, just pointing out that it's not there.

The general consensus at the last IETF meeting seemed to be that this
one doesn't belong on the list of WG deliverables now. Maybe later...

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i923Nw0v077794; Fri, 1 Oct 2004 20:23:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i923NwGt077793; Fri, 1 Oct 2004 20:23:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i923NucF077782 for <[e-mail]>; Fri, 1 Oct 2004 20:23:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 01 Oct 2004 15:40:15 -0700 (PDT)
Date: Fri, 01 Oct 2004 15:39:13 -0700 (PDT)
From: [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
In-reply-to: "Your message dated Fri, 01 Oct 2004 13:58:10 -0400" <[e-mail]>
To: "\"\" Mark E. Mallett \"\"" <[e-mail]>
Cc: "Cyrus Daboo" <[e-mail]>, "\"\" Mark E. Mallett \"\"" <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Fri, Oct 01, 2004 at 01:47:28PM -0400, Cyrus Daboo wrote:
> > --On Friday, October 1, 2004 1:00 PM -0400 "Mark E. Mallett"
> > <[e-mail]> wrote:
> >
> > >My only other comment is about the rapid schedule on the variables
> > >draft- I had some thoughts that would probably not be appropriate if the
> > >draft is to be sent through at this rate.
> > >
> >
> > Please post any comments you have. Note that a new -04 version of the draft
> > was posted a couple of weeks ago.

> Saw that..  One thing I wondered is whether it was appropriate to open
> up more conversation about variables on this list in light of the fact a
> new working group is being created (making the bold assumption that I'd
> be admitted to it, of course :-) ).  I'm guilty of waiting way too long
> to comment, unfortunately.

It is entirely appropriate to start talking about any draft at this point,
regardless of what our WG status is. Although I for one hope we don't make
extensive changes to variables at this point ;-)

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91IAt1V047351; Fri, 1 Oct 2004 11:10:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91IAtN1047350; Fri, 1 Oct 2004 11:10:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91IAtBO047340 for <[e-mail]>; Fri, 1 Oct 2004 11:10:55 -0700 (PDT) (envelope-from [e-mail])
Received: from jutta.sendmail.com ([10.210.202.35]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i91IAqxK014051; Fri, 1 Oct 2004 11:10:52 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i91IAqxK014051
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=L5tSf4zfwHe6T6sKKi+joMVl6YLVt0yi1O0ucfq3IkoFkB9mqrt/Z7IRyGqNL890W phSROrtg7GsJzaYov8NDyAACXkcHihzmr+XmR+JuKWiWm3W6gF/7HDPOxwIS4NDiWc1 mE+yz6F0mQ80YEHX20z99rzWns8Zu/wD5tMein4=
Received: by jutta.sendmail.com (Postfix, from userid 500) id 0CF62179A2; Fri,  1 Oct 2004 11:10:48 -0700 (PDT)
Date: Fri, 1 Oct 2004 11:10:47 -0700
From: Jutta Degener <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 00, 2004 at 01:00:28PM -0400, Mark E. Mallett wrote:
> 
> On Fri, Sep 24, 2004 at 04:13:41PM -0700, [e-mail] wrote:
> 
> > (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598),
> >     spamtest/virustest (RFC 3685), and copy extension specifications,
> 
> The "copy extensions specifications" being "draft-degener-sieve-copy" ?
> Why is it listed in (2) and not in (3)?  (not that it really matters I
> guess, just wanted to make sure it's included...)

By the time Ned's document is published,
the copy extension is very likely to have become an RFC.

Jutta



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I4lKB046917; Fri, 1 Oct 2004 11:04:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91I4l6V046916; Fri, 1 Oct 2004 11:04:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91I4lt7046908 for <[e-mail]>; Fri, 1 Oct 2004 11:04:47 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i91Hg3o3002944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 13:42:04 -0400
Date: Fri, 01 Oct 2004 14:04:47 -0400
From: Cyrus Daboo <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mark,

--On Friday, October 1, 2004 1:58 PM -0400 "Mark E. Mallett" 
<[e-mail]> wrote:

>> Please post any comments you have. Note that a new -04 version of the
>> draft  was posted a couple of weeks ago.
>
> Saw that..  One thing I wondered is whether it was appropriate to open
> up more conversation about variables on this list in light of the fact a
> new working group is being created (making the bold assumption that I'd
> be admitted to it, of course :-) ).  I'm guilty of waiting way too long
> to comment, unfortunately.

It is entirely appropriate to do that, the WG is merely a continuation of 
the work done on the mailing list. There is no reason to delay work on the 
drafts waiting for the WG to actually be setup (assuming we do get approval 
from ADs and IESG).

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Hw74w046540; Fri, 1 Oct 2004 10:58:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Hw7MU046539; Fri, 1 Oct 2004 10:58:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i91Hw61P046533 for <[e-mail]>; Fri, 1 Oct 2004 10:58:06 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 49433 invoked by uid 101); 1 Oct 2004 13:58:10 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 1 Oct 2004 13:58:10 -0400
To: Cyrus Daboo <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 01, 2004 at 01:47:28PM -0400, Cyrus Daboo wrote:
> --On Friday, October 1, 2004 1:00 PM -0400 "Mark E. Mallett" 
> <[e-mail]> wrote:
> 
> >My only other comment is about the rapid schedule on the variables
> >draft- I had some thoughts that would probably not be appropriate if the
> >draft is to be sent through at this rate.
> >
> 
> Please post any comments you have. Note that a new -04 version of the draft 
> was posted a couple of weeks ago.

Saw that..  One thing I wondered is whether it was appropriate to open
up more conversation about variables on this list in light of the fact a
new working group is being created (making the bold assumption that I'd
be admitted to it, of course :-) ).  I'm guilty of waiting way too long
to comment, unfortunately.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91HlTr5045370; Fri, 1 Oct 2004 10:47:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91HlT3u045369; Fri, 1 Oct 2004 10:47:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91HlTmK045363 for <[e-mail]>; Fri, 1 Oct 2004 10:47:29 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i91HOho3002518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 13:24:44 -0400
Date: Fri, 01 Oct 2004 13:47:28 -0400
From: Cyrus Daboo <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mark,

--On Friday, October 1, 2004 1:00 PM -0400 "Mark E. Mallett" 
<[e-mail]> wrote:

>> (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598),
>>     spamtest/virustest (RFC 3685), and copy extension specifications,
>
> The "copy extensions specifications" being "draft-degener-sieve-copy" ?
> Why is it listed in (2) and not in (3)?  (not that it really matters I
> guess, just wanted to make sure it's included...)

That draft is currently in the RFC Editor queue waiting to be published, 
and hopefully will be very soon - so it is correct to put it under (2) 
thought there is no RFC number assigned to it right now.

> Also the "draft-daboo-sieve-include" draft is not mentioned (which is OK
> with me -- I didn't care for the include draft the way it was but think
> that some kind of include facility is important).  I'm assuming it's
> left out because of the lack of "willingness to implement" that you
> said later, but again, just pointing out that it's not there.

There was a lack of interest to implement this expressed at the lunch 
session in San Diego, and hence it was left out of the WG items. I know 
that the CMU folks did implement it and they had no comments back to me 
after doing that. At this point we could just do a last call with it aimed 
either for Proposed or Experimental depending on whether anyone else might 
implement it in the future...

> My only other comment is about the rapid schedule on the variables
> draft- I had some thoughts that would probably not be appropriate if the
> draft is to be sent through at this rate.
>

Please post any comments you have. Note that a new -04 version of the draft 
was posted a couple of weeks ago.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91H0TtY042190; Fri, 1 Oct 2004 10:00:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91H0TfY042189; Fri, 1 Oct 2004 10:00:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i91H0PIC042180 for <[e-mail]>; Fri, 1 Oct 2004 10:00:28 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 22960 invoked by uid 101); 1 Oct 2004 13:00:28 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 1 Oct 2004 13:00:28 -0400
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: -01 revision of proposed sieve WG charter
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Sep 24, 2004 at 04:13:41PM -0700, [e-mail] wrote:

> (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598),
>     spamtest/virustest (RFC 3685), and copy extension specifications,

The "copy extensions specifications" being "draft-degener-sieve-copy" ?
Why is it listed in (2) and not in (3)?  (not that it really matters I
guess, just wanted to make sure it's included...)

Also the "draft-daboo-sieve-include" draft is not mentioned (which is OK
with me -- I didn't care for the include draft the way it was but think
that some kind of include facility is important).  I'm assuming it's
left out because of the lack of "willingness to implement" that you
said later, but again, just pointing out that it's not there.

My only other comment is about the rapid schedule on the variables
draft- I had some thoughts that would probably not be appropriate if the
draft is to be sent through at this rate.

-mm-