Re: escapes in sieve strings

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

On Sun, 2005-02-27 at 22:50 -0800, Philip Guenther wrote:
> If the WG decides that breaking backwards compability on this point is
> worthwhile, then I would suggest we go ahead and explicitly warn script
> authors that future extensions or revisions MAY redefine other
> backslash-character combinations and that scripts should therefore avoid
> extraneous backslash escapes.

agreed.

> Also, please note that currently, backslashes are only special in quoted
> strings and not in multi-line strings.  That leaves a choice of either
> a) making quoted strings strictly more 'powerful' that multi-line
>    strings, or
> b) changing the interpretation of backslashes in multi-line strings.
> 
> Personally, I find (b) a non-starter.

agreed.

> Regarding the discussion around how to express NUL, I would rather
> _only_ have \u and \U, so that NUL would be \u0000 (or \U00000000).

then it is impossible to express arbitrary octets, e.g., 0xFF, since
it's not a valid UTF-8 sequence.

> I dislike escape sequences that are neither fixed length (like \u and \U)
> nor bracketed (like perl5's \P{name}).

agreed.
-- 
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 j1SDQiFN070029; Mon, 28 Feb 2005 05:26:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SDQiKV070028; Mon, 28 Feb 2005 05:26:44 -0800 (PST)
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 j1SDQdBR070013 for <[e-mail]>; Mon, 28 Feb 2005 05:26:40 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45] ident=7411) by pat.uio.no with esmtp (Exim 4.43) id 1D5kuw-000489-2V; Mon, 28 Feb 2005 14:26:34 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtps (TLSv1:RC4-MD5:128) (Exim 4.43) id 1D5kus-0000X2-7K; Mon, 28 Feb 2005 14:26:30 +0100
Subject: Re: escapes in sieve strings
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Mon, 28 Feb 2005 14:26:29 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.5 
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=-4.839, required 12, autolearn=disabled, AWL 0.16, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-02-27 at 22:50 -0800, Philip Guenther wrote:
> If the WG decides that breaking backwards compability on this point is
> worthwhile, then I would suggest we go ahead and explicitly warn script
> authors that future extensions or revisions MAY redefine other
> backslash-character combinations and that scripts should therefore avoid
> extraneous backslash escapes.

agreed.

> Also, please note that currently, backslashes are only special in quoted
> strings and not in multi-line strings.  That leaves a choice of either
> a) making quoted strings strictly more 'powerful' that multi-line
>    strings, or
> b) changing the interpretation of backslashes in multi-line strings.
> 
> Personally, I find (b) a non-starter.

agreed.

> Regarding the discussion around how to express NUL, I would rather
> _only_ have \u and \U, so that NUL would be \u0000 (or \U00000000).

then it is impossible to express arbitrary octets, e.g., 0xFF, since
it's not a valid UTF-8 sequence.

> I dislike escape sequences that are neither fixed length (like \u and \U)
> nor bracketed (like perl5's \P{name}).

agreed.
-- 
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 j1S6oNN5021510; Sun, 27 Feb 2005 22:50:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1S6oNGw021509; Sun, 27 Feb 2005 22:50:23 -0800 (PST)
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 j1S6oM5k021452 for <[e-mail]>; Sun, 27 Feb 2005 22:50:22 -0800 (PST) (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 j1S6oDZZ019033 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Sun, 27 Feb 2005 22:50:14 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com j1S6oDZZ019033
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=FTcliu2kg9i1GuoDd11FUvEqVvDS5r0pXufcnpZNc5ooUiNvPGSNbHdtTQb73aeqd bG24lkk3jePDwLTgbtolbA/yoq1J1iBC4Cf00eelxLGCox5/O2wb6KWGmGf+nQLEeN7 lKd8hpgQQBP42cfGjGrdDU6dpepoM9UHTFrsfos=
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 j1S6oDBp099320 for <[e-mail]>; Sun, 27 Feb 2005 22:50:13 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: escapes in sieve strings
Date: Sun, 27 Feb 2005 22:50:13 -0800
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>

Personally, I'm a bit mixed on the wisdom of changing the interpretation
of escapes in sieve scripts, mainly because the original spec defined
the meaning of _all_ escapes instead of only defining those that were
required ( \\ and \" ) while leaving other escapes as having undefined
behavior.  An implementation that complies with RFC 3028 cannot
simultaneously comply with a specification that requires \0 to be
treated as a NUL or \u0025 to be treated as a percent sign.

If the WG decides that breaking backwards compability on this point is
worthwhile, then I would suggest we go ahead and explicitly warn script
authors that future extensions or revisions MAY redefine other
backslash-character combinations and that scripts should therefore avoid
extraneous backslash escapes.


Also, please note that currently, backslashes are only special in quoted
strings and not in multi-line strings.  That leaves a choice of either
a) making quoted strings strictly more 'powerful' that multi-line
   strings, or
b) changing the interpretation of backslashes in multi-line strings.

Personally, I find (b) a non-starter.


Regarding the discussion around how to express NUL, I would rather
_only_ have \u and \U, so that NUL would be \u0000 (or \U00000000).  I
dislike escape sequences that are neither fixed length (like \u and \U)
nor bracketed (like perl5's \P{name}).


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 j1OBjJO4090624; Thu, 24 Feb 2005 03:45:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OBjJEr090623; Thu, 24 Feb 2005 03:45:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OBjChD090496 for <[e-mail]>; Thu, 24 Feb 2005 03:45:16 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 24 Feb 2005 11:43:57 +0000
Message-ID: <[e-mail]>
Date: Wed, 23 Feb 2005 22:06:05 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: Sieve base-spec revision I-D
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Kjetil Torgrim Homme wrote:

>>I could also see a \0<alpha> sequence having extra
>>meaning, e.g. '\0xnn' for hex.  
>>
>>What would be the need for \uXXXX that a series of multiple escaped
>>bytes couldn't provide?
>>    
>>
>
>it's more convenient than having to do the UTF-8 coding yourself.  not
>that it's hard, I could even do it in my head, but it's error prone.
>
I second this.

>it also puts an additional burden on Sieve script builders, they need to
>convert back and forth before presenting the rule for the user.
>  
>




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 j1MKNAuK087698; Tue, 22 Feb 2005 12:23:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1MKNAKT087697; Tue, 22 Feb 2005 12:23:10 -0800 (PST)
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 j1MKN90V087685 for <[e-mail]>; Tue, 22 Feb 2005 12:23:09 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45] ident=7411) by pat.uio.no with esmtp (Exim 4.43) id 1D3gYf-0002tn-Up; Tue, 22 Feb 2005 21:23:02 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtps (TLSv1:RC4-MD5:128) (Exim 4.43) id 1D3gYb-00039U-W9; Tue, 22 Feb 2005 21:22:58 +0100
Subject: Re: Sieve base-spec revision I-D
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: Tue, 22 Feb 2005 21:22:55 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.5 
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=-4.751, required 12, autolearn=disabled, AWL 0.25, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-02-22 at 13:26 -0500, Mark E. Mallett wrote:
> On Wed, Feb 16, 2005 at 05:36:26AM +0100, Kjetil Torgrim Homme wrote:
> > I wish
> > there were an escape for including octets by value in strings, e.g.
> > "\x00".  that would be an incompatible change, can we do that?
> > 
> > (if so, I'd want "\uXXXX" and "\UXXXXXXXX" for Unicode, too (same syntax
> > as Java and C99))
> 
> I agree with wanting to be able to specify octets by value.  I'd hate to
> do it with a leading alpha character though, as '\x' is supposed to mean
> 'x'.  I've done it a la C escapes, with '\0nnn' meaning an octal value,
> where you only have to make '0' special, and I don't think \0 sequences
> being special would come as as much of a shock as \<alpha> sequences
> being special.

perhaps, but I don't think it makes much difference.  FWIW, I did a
quick survey of our user's Sieve scripts (a little more than 2000
scripts), and none of them had extraneous backslashes.  only one user
had (wrongly) written "\." in a regex context.

I don't like \0nnn since it is AFAIK a syntax not used in any other
language, also octal is a bit old-school :-)

(C-style \nnn for octal is problematic since it is variable width.)

> I could also see a \0<alpha> sequence having extra
> meaning, e.g. '\0xnn' for hex.  
> 
> What would be the need for \uXXXX that a series of multiple escaped
> bytes couldn't provide?

it's more convenient than having to do the UTF-8 coding yourself.  not
that it's hard, I could even do it in my head, but it's error prone.  it
also puts an additional burden on Sieve script builders, they need to
convert back and forth before presenting the rule for the user.

-- 
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 j1MIQQrm079754; Tue, 22 Feb 2005 10:26:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1MIQQPu079753; Tue, 22 Feb 2005 10:26:26 -0800 (PST)
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 j1MIQOWP079743 for <[e-mail]>; Tue, 22 Feb 2005 10:26:24 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 32497 invoked by uid 101); 22 Feb 2005 13:26:24 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 22 Feb 2005 13:26:24 -0500
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Philip Guenther <[e-mail]>, [e-mail]
Subject: Re: Sieve base-spec revision I-D
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 Wed, Feb 16, 2005 at 05:36:26AM +0100, Kjetil Torgrim Homme wrote:
> there is a slight problem since a header can use encoding to include NUL
> and other problematic characters, and the Sieve interpreter undoes this
> in order to present it all as UTF-8 or plain octets to the user.  I wish
> there were an escape for including octets by value in strings, e.g.
> "\x00".  that would be an incompatible change, can we do that?
> 
> (if so, I'd want "\uXXXX" and "\UXXXXXXXX" for Unicode, too (same syntax
> as Java and C99))

I agree with wanting to be able to specify octets by value.  I'd hate to
do it with a leading alpha character though, as '\x' is supposed to mean
'x'.  I've done it a la C escapes, with '\0nnn' meaning an octal value,
where you only have to make '0' special, and I don't think \0 sequences
being special would come as as much of a shock as \<alpha> sequences
being special.  I could also see a \0<alpha> sequence having extra
meaning, e.g. '\0xnn' for hex.  

What would be the need for \uXXXX that a series of multiple escaped
bytes couldn't provide?

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 j1MIKddR079369; Tue, 22 Feb 2005 10:20:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1MIKdnK079368; Tue, 22 Feb 2005 10:20:39 -0800 (PST)
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 j1MIKYHa079356 for <[e-mail]>; Tue, 22 Feb 2005 10:20:34 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 30817 invoked by uid 101); 22 Feb 2005 13:20:31 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 22 Feb 2005 13:20:31 -0500
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
Subject: Re: Sieve base-spec revision I-D
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 Tue, Feb 15, 2005 at 04:22:52PM -0800, Philip Guenther wrote:
> 
> The other open issues on my list are:
> 
> 1) removal of the "Tests MUST NOT have side effects" restriction.
>    We must permit the behavior of the 'variables' extension; do we
>    still want to discourage side-effects in general or should the
>    last two paragraphs of section 2.5 simply be dropped?

I would either drop them, or isolate the side-effect prohibition to
the message only (i.e., may change the state of the filter, but
must not change the message).

BTW, since the intent is to make accomodation for the variables
extension, perhaps the introductory text about how variables are
not provided (two places) should be amended.



One other minor thing noted:

2.10.2.  Implicit Keep

   > An implicit keep is performed if a message is not written to a
   > mailbox, redirected to a new address, rejected, or explicitly thrown
   > out.  That is, if a fileinto, a keep, a redirect, or a discard is
   > performed, an implicit keep is not.

You've added "rejected" to the first sentence (as well as modifying
4.1), so you should probably also add "reject" to the second sentence.

(of course, this is muddled somewhat by :copy ...)

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 j1IBwARY082480; Fri, 18 Feb 2005 03:58:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IBwAir082479; Fri, 18 Feb 2005 03:58:10 -0800 (PST)
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 j1IBw2i4082392 for <[e-mail]>; Fri, 18 Feb 2005 03:58:03 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29] ident=[U2FsdGVkX1+47qibUWud5OS3CcUWIw7H0Ntw7gwSUC4=]) by pat.uio.no with esmtp (Exim 4.43) id 1D26lh-0006XF-05; Fri, 18 Feb 2005 12:57:57 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx1.uio.no with esmtps (TLSv1:RC4-MD5:128) (Exim 4.43) id 1D26lZ-0008C9-Ox; Fri, 18 Feb 2005 12:57:49 +0100
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
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]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 18 Feb 2005 12:57:48 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.5 
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=-4.887, required 12, autolearn=disabled, AWL 0.11, UIO_MAIL_IS_INTERNAL -5.00)
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 Thu, 2005-02-17 at 22:39 -0500, Mark E. Mallett wrote:
> On Fri, Feb 18, 2005 at 01:10:16AM +0100, Kjetil Torgrim Homme wrote:
> > On Thu, 2005-02-17 at 18:44 -0500, Mark E. Mallett wrote:
> > 
> > > > > 4.  Action set
> > > > > 
> > > > >    > An illegal name MUST cause a syntax error.
> > > > > 
> > > > > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
>
> I guess I'm just being anal.  I think of an invalid name as being a
> syntax error rather than causing a syntax error.  That was behind "must
> be detected as a syntax error."

ah, it didn't register as suggested replacement text, I'm just blind.
fixed, 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 j1IBumu6081984; Fri, 18 Feb 2005 03:56:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IBumrm081983; Fri, 18 Feb 2005 03:56:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IBulvc081923 for <[e-mail]>; Fri, 18 Feb 2005 03:56:47 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.203]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Fri, 18 Feb 2005 03:56:38 -0800
Message-ID: <004c01c515b0$f3308d80$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>, "Mark E. Mallett" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Date: Fri, 18 Feb 2005 11:56:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1IBulvc081975
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>

> I agree, I can't really think of a use case for the count, so I probably
> shouldn't have included it in the first place.
> 
> > I'd rather have both, though, and providing them is really a minor thing,
> > no matter how late it is.
> 
> anyone else have an opinion?

My expectation would be that ${0} is the match.  I've never had a need for the number of parts that matched.  It was something I read in the draft though "oh that's different to what I expect" but then I didn't have a big problem with it so didn't mention it.  Indeed as already mentioned, adding another set of () is all you need if ${0} has a different meaning.

Nigel



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 j1I3daYH031472; Thu, 17 Feb 2005 19:39:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I3date031471; Thu, 17 Feb 2005 19:39:36 -0800 (PST)
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 j1I3dYPv031459 for <[e-mail]>; Thu, 17 Feb 2005 19:39:35 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 66601 invoked by uid 101); 17 Feb 2005 22:39:30 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 17 Feb 2005 22:39:30 -0500
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Fri, Feb 18, 2005 at 01:10:16AM +0100, Kjetil Torgrim Homme wrote:
> On Thu, 2005-02-17 at 18:44 -0500, Mark E. Mallett wrote:
> 
> > > > 4.  Action set
> > > > 
> > > >    > An illegal name MUST cause a syntax error.
> > > > 
> > > > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
> >
> > Just to be clear, my main comment was about the wording "must cause a
> > syntax error" being wrong.  The parenthesised "compile time or runtime"
> > was a side comment and yeah, it's probably obvious that it's compile
> > time.
> 
> what's wrong?  you mean s/cause/handled as/ ?

I guess I'm just being anal.  I think of an invalid name as being a
syntax error rather than causing a syntax error.  That was behind "must
be detected as a syntax error."

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 j1I0AVhS010468; Thu, 17 Feb 2005 16:10:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I0AV26010467; Thu, 17 Feb 2005 16:10:31 -0800 (PST)
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 j1I0AU1Q010446 for <[e-mail]>; Thu, 17 Feb 2005 16:10:30 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29] ident=[U2FsdGVkX18+XTMsALgPPyccRWN9D5WgkwSH+WSQp18=]) by pat.uio.no with esmtp (Exim 4.43) id 1D1vix-0005Ik-5U; Fri, 18 Feb 2005 01:10:23 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx1.uio.no with esmtps (TLSv1:RC4-MD5:128) (Exim 4.43) id 1D1vis-0002n2-5j; Fri, 18 Feb 2005 01:10:18 +0100
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
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]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 18 Feb 2005 01:10:16 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.5 
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=-4.876, required 12, autolearn=disabled, AWL 0.12, UIO_MAIL_IS_INTERNAL -5.00)
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 Thu, 2005-02-17 at 18:44 -0500, Mark E. Mallett wrote:
> My prediction is that something returning the entire match string will
> be much more useful than something returning the count of matches.

I agree, I can't really think of a use case for the count, so I probably
shouldn't have included it in the first place.

> I'd rather have both, though, and providing them is really a minor thing,
> no matter how late it is.

anyone else have an opinion?

>> > [${0} is the match, ${#} is the count]
> > > Or keep ${0} as the count, and add something else (e.g. ${*}) as the
> > > complete match string.

${*} (shell) or ${&} (sed, Perl), I guess.  ${0} as match corresponds to
e.g. awk.  ${:} as in Python's [:] could work, too, but is strange
without the range.  so many options ...

> > explicit is better than implicit -- users can just add an extra pair of
> > parentheses.  (this only applies to :regex.  for :matches, the match
> > string is always equal to the source string.)
> 
> Indeed it is- it's still useful to be able to access it.

you're right, that's actually awkward to do with :matches without this
feature:

   if header :matches ["To", "Cc"] ["kj*", "za*"]

the above needs to be replaced by four individual statements.  whether
that is _compelling_, I'll leave for someone else to say :-)

> > > 4.  Action set
> > > 
> > >    > An illegal name MUST cause a syntax error.
> > > 
> > > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
>
> Just to be clear, my main comment was about the wording "must cause a
> syntax error" being wrong.  The parenthesised "compile time or runtime"
> was a side comment and yeah, it's probably obvious that it's compile
> time.

what's wrong?  you mean s/cause/handled as/ ?

-- 
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 j1HNiQLW007120; Thu, 17 Feb 2005 15:44:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HNiQZs007119; Thu, 17 Feb 2005 15:44:26 -0800 (PST)
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 j1HNiPe6007113 for <[e-mail]>; Thu, 17 Feb 2005 15:44:25 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 2544 invoked by uid 101); 17 Feb 2005 18:44:21 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 17 Feb 2005 18:44:21 -0500
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Message-ID: <[e-mail]>
References: <[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>

[sorry, I'm slow]

On Mon, Feb 07, 2005 at 12:41:26AM +0100, Kjetil Torgrim Homme wrote:
> On Sat, 2005-02-05 at 17:01 -0500, Mark E. Mallett wrote:
> > 
> > Hmm, I glossed over this before.  There are other environments
> > (including typical regex implementations) where it's common to have
> > submatch 0 represent the entire matched string.  Access to the number of
> > strings is useful, but so is access to the entire match (probably more
> > so than the number of matches, since that's predictable from the pattern
> > used).  Since it's nice to be consistent with what people might already
> > be used to, I'd recommend having index 0 be the entire match, and something
> > else be the count of the matches.  Maybe a special ${#} for the number
> > of matches.
> 
> I think too little is gained by this change to incorporate it at this
> stage.

My prediction is that something returning the entire match string will
be much more useful than something returning the count of matches.
I'd rather have both, though, and providing them is really a minor thing,
no matter how late it is.



> > Or keep ${0} as the count, and add something else (e.g. ${*}) as the
> > complete match string.
> 
> explicit is better than implicit -- users can just add an extra pair of
> parentheses.  (this only applies to :regex.  for :matches, the match
> string is always equal to the source string.)

Indeed it is- it's still useful to be able to access it.



> > 4.  Action set
> > 
> >    > An illegal name MUST cause a syntax error.
> > 
> > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
> 
> from RFC 3028, 2.10.6:
> 
>    In any programming language, there are compile-time and run-time
>    errors.
> 
>    Compile-time errors are ones in syntax that are detectable if a
>    syntax check is done.
> 
> so compile-time.

Just to be clear, my main comment was about the wording "must cause a
syntax error" being wrong.  The parenthesised "compile time or runtime"
was a side comment and yeah, it's probably obvious that it's compile
time.

-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 j1HI6wRe076463; Thu, 17 Feb 2005 10:06:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HI6w4V076462; Thu, 17 Feb 2005 10:06:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HI6sL7076439 for <[e-mail]>; Thu, 17 Feb 2005 10:06:54 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.210]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Thu, 17 Feb 2005 10:06:43 -0800
Message-ID: <01da01c5151b$7cb4a140$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Daniel" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <008f01c514ff$0f615460$6401a8c0@nigelhome> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Thu, 17 Feb 2005 18:06:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1HI6sL7076445
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>

> RFC 2806 defines the "tel" URL scheme - is this what you are looking for?
> 
> Daniel

Yeah perfect!  Thanks Daniel!  I found RFC 3966 is the newer version of 2806, and it goes OTT for the purposes for Sieve, but if we pick selected bits of the BNF we get:
 
   telephone-subscriber = global-number / local-number
   global-number        = global-number-digits *par
   local-number         = [I'd suggest we'd not allow this]
   par                  = [I'd suggest we'd not allow this]
   global-number-digits = "+" *phonedigit DIGIT *phonedigit
   phonedigit           = DIGIT / [ visual-separator ]
   visual-separator     = "-" / "." / "(" / ")"

Then it's a fairly trivial case of binning the visual-separators and you should be left with a string of numbers prefixed with a +. :o)

Nigel



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 j1HHu4jO075302; Thu, 17 Feb 2005 09:56:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HHu1qx075299; Thu, 17 Feb 2005 09:56:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HHu0AG075135 for <[e-mail]>; Thu, 17 Feb 2005 09:56:00 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.210]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Thu, 17 Feb 2005 09:55:47 -0800
Message-ID: <01b801c51519$f56c2c40$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Michael Haardt" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <008f01c514ff$0f615460$6401a8c0@nigelhome> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Thu, 17 Feb 2005 17:56:06 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1HHu0AG075293
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>

> Again, over here people pay per part.  One SMS part has a fixed cost,
> billed (mostly) to the sender.  Very long SMS contain multiple parts.
> If other telephone networks follow this model, then it makes more
> sense to let people specify the maximum number of parts allowed,
> which dirctly translates to money, cutting the message after that.
> What good is a limit of 170 characters, if 1-160 characters cost one
> unit and 161-320 cost two units? Then again, I may give a message with
> many UTF-8 characters that will be dropped when converting to IA5, so
> people won't understand why sometimes 200 characters "fit" in 170 octets.
> With parts, they indirectly say "you can spend this much money" and do
> not need to care about encoding or number of octets.

I'm in the UK so it's the same for me too.  You are detailing the exact reason why I proposed :limit being a message limit rather than a character limit (which was in the original I-Draft).  My "message" is your "part", we're gunning for the same thing.  :o)

> > If we are to offer a standard, then maybe we should just drop the "To"
> > as well, as in the vast majority of cases I'd imagine users will know
> > who the message was sent to.
> 
> Not if they have multiple mailboxes, like office and private.

So will that be more common?  With only 140 8 byte characters to play with, using up approximately 40 for what might always be the same might be quite a lot....  Ideally we'd pick a default which had no internationalisation issues, so maybe not even use the word "From"....  But perhaps the subject has no place in the draft anyway...

Nigel



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 j1HFXEtt060724; Thu, 17 Feb 2005 07:33:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HFXEtT060723; Thu, 17 Feb 2005 07:33:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HFXCHj060713 for <[e-mail]>; Thu, 17 Feb 2005 07:33:13 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.47) id 1D1ne8-0005p4-RE for [e-mail]; Thu, 17 Feb 2005 16:32:52 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1D1ne8-0000kO-Pn for [e-mail]; Thu, 17 Feb 2005 16:32:52 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.47 #9) id 1D1ne8-0003Zn-F2 for [e-mail]; Thu, 17 Feb 2005 16:32:52 +0100
Date: Thu, 17 Feb 2005 16:32:52 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Sieve-Notify and potential associative arrays.
Message-ID: <[e-mail]>
References: <[e-mail]> <008f01c514ff$0f615460$6401a8c0@nigelhome>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <008f01c514ff$0f615460$6401a8c0@nigelhome>
User-Agent: Mutt/1.5.6i
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 Thu, Feb 17, 2005 at 02:43:31PM -0000, Nigel Swinson wrote:
> > So what if no number is specified, either explicit or implicit? Should
> > the action be ignored or cause the script to fail? The same question
> > arises on invalid number strings.  I vote for ignoring invalid numbers
> > and actions without any number at all.
> 
> I think if phone numbers are supplied, then the implementation SHOULD
> raise a compile error if the supplied string is not valid.

You assume that Sieve scripts are always compiled, but in fact RFC 3028
allows for them to be interpreted, too.  Invalid phone numbers are
like invalid header names in comparisons to me.  It's not specified
what happens in this case.  My implementation generates an error to
ease debugging, but does so when interpreting the script.

> Ok :o)  And if more than the limit are specified, then this would be a compile error?

Or a runtime error. :)

> The :limit parameter I was proposing was meant to apply after any
> character set encoding of the message.  I'm not familiar with IA5, I had
> hoped we could just pipe UTF8 and then truncate at some appropriate point.
> So I'm not sure in what way your proposed :parts differs to my :limit?

Again, over here people pay per part.  One SMS part has a fixed cost,
billed (mostly) to the sender.  Very long SMS contain multiple parts.
If other telephone networks follow this model, then it makes more
sense to let people specify the maximum number of parts allowed,
which dirctly translates to money, cutting the message after that.
What good is a limit of 170 characters, if 1-160 characters cost one
unit and 161-320 cost two units? Then again, I may give a message with
many UTF-8 characters that will be dropped when converting to IA5, so
people won't understand why sometimes 200 characters "fit" in 170 octets.
With parts, they indirectly say "you can spend this much money" and do
not need to care about encoding or number of octets.

> I wasn't actually proposing we standardize the default message format,
> just describing what I was going to use, but that is an interesting idea
> :o)  That could make your sieve action just:
> 
>    sms;

Yes, if you have a mailbox property that contains a phone number, but
I wouldn't make that even a SHOULD, but optional.

> If we are to offer a standard, then maybe we should just drop the "To"
> as well, as in the vast majority of cases I'd imagine users will know
> who the message was sent to.

Not if they have multiple mailboxes, like office and private.

Michael



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 j1HEhXP2056660; Thu, 17 Feb 2005 06:43:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HEhXXY056659; Thu, 17 Feb 2005 06:43:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HEhTpK056623 for <[e-mail]>; Thu, 17 Feb 2005 06:43:29 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.210]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Thu, 17 Feb 2005 06:43:15 -0800
Message-ID: <008f01c514ff$0f615460$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Michael Haardt" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Thu, 17 Feb 2005 14:43:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1HEhTpK056644
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>

> Sorry for the late reply, but I sent this previously with a sender
> that's not subscribed to the list.

:o)

> It may be easier to specify different actions than different extensions
> to notify, at least current extension specifications make me think so.
> So I don't mind to split things up.

Ok :o)
 
> >  The :recipient tag specifies the target phone numbers to send this SMS
> >  to.  If not present, the implementation should try to send the SMS to the
> >  owner of the script where the number is held by the sieve implementation,
> >  ie a mailbox property.
> 
> As long as that's not a "SHOULD try", it is fine with me.  Enforcing a new
> mailbox property in order to use this extension would not be nice at all.

Good point, I'm fine with this.

> So what if no number is specified, either explicit or implicit? Should
> the action be ignored or cause the script to fail? The same question
> arises on invalid number strings.  I vote for ignoring invalid numbers
> and actions without any number at all.

I think if phone numbers are supplied, then the implementation SHOULD raise a compile error if the supplied string is not valid.  If no phone number is supplied then the implementation SHOULD try use a default, and if this is not available then the implementation SHOULD notify the user of the error but MUST NOT fail the execution of the script.  I had a look to see what was specified in the vacation draft, but didn't find any comments relating to what I think are similair issues.

> >  If present, specifies the target number, and it
> >  can also be a list of numbers if more than one recipient is desired.
> 
> Please let the implementation limit the maximum amount of specified
> recipients or sms actions.

Ok :o)  And if more than the limit are specified, then this would be a compile error?

> I think that must be a MUST. :) I am sure the TON/NPI for the
> international numbers you described is defined by a standard that could
> be referenced here, I just don't know which one.

Ok, I guess when the time comes we'll need to find it and reference it.

> >  The message is a string, whereby variable expansion is also
> >  permitted. The limit is the maximum number of SMS messages that the
> >  server can send.  Given that each message typically has a cost associated
> >  with it, the limit by default will be whatever produces the least cost
> >  which in today?s terms is 1 message (140 bytes) but may change in the
> >  future.
> 
> Over here, up to 160 octets do fit in a single message.  I think that
> the EUR currency sign is encoded in two octets, though.  The character
> set is IA5, so we have to specify what happens to unicode characters that
> can not be translated to IA5.  I am used to gateways just dropping them.
> 
> Of course you could apply the length after IA5 translation, but how
> about specifying the cost in number of messages (:parts)?

The :limit parameter I was proposing was meant to apply after any character set encoding of the message.  I'm not familiar with IA5, I had hoped we could just pipe UTF8 and then truncate at some appropriate point.  So I'm not sure in what way your proposed :parts differs to my :limit?

> I prefer this:
> 
>                From <sender-address> To <recipient-address>: 
> <Subject>\r\n<body>
> 
> I would like to allow the implementation to use a different default
> format.  In case it has access to a language mailbox property, it should
> be allowed to send a message in the users native language by default.

I wasn't actually proposing we standardize the default message format, just describing what I was going to use, but that is an interesting idea :o)  That could make your sieve action just:

   sms;

If we are to offer a standard, then maybe we should just drop the "To" as well, as in the vast majority of cases I'd imagine users will know who the message was sent to.

> >  One way to get his is using the proposed $name$ variables which seem
> >  pretty ugly next to what we've worked so hard on with the variables
> >  extension, and also is pretty inflexible.
> 
> Agreed.

:o)
 
> There are two remaining issues: Rate limiting and security.  I suggest
> a new extension which specifies a condition for rate limiting, e.g.
> named token buckets, to keep that out of sms.  It may be useful to forward
> mail to expensive gateway addresses as well.  The sms/notify extension
> should not offer builtin rate limiting.  

Reminds me of an old post that I can't find just now todo with gathering statistics about how long various extensions were taking so as to limit the capabilities of scripts...

> With concern to security: The
> implementation SHOULD enforce that SMS are only sent to verified numbers.
> Otherwise, one typo suffices to annoy someone else like hell, apart
> from letting him read part of your mail.

I'm still dreaming of the day when phone numbers don't exist in the user domain at all, and rather we move completely over to using the localpart@domainname format for email, post, phone, sms, fax.  I'm told the model in the US is that the recipient pays for receiving an SMS, and I'm amazed to hear that it works!  Apparently you can disable SMS from certain senders as a way of protecting against error/mallicious use.

Thanks for the comments!

Nigel



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 j1GDGkFW001383; Wed, 16 Feb 2005 05:16:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GDGkap001382; Wed, 16 Feb 2005 05:16:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GDGfuQ001264 for <[e-mail]>; Wed, 16 Feb 2005 05:16:45 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.47) id 1D1P2T-0005el-67 for [e-mail]; Wed, 16 Feb 2005 14:16:21 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1D1P2T-0000bv-3M for [e-mail]; Wed, 16 Feb 2005 14:16:21 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.47 #4) id 1D1P2S-0002Hi-QF for [e-mail]; Wed, 16 Feb 2005 14:16:20 +0100
Date: Wed, 16 Feb 2005 14:16:20 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Sieve-Notify and potential associative arrays.
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <015501c508cd$f508ce00$6501a8c0@nigelhome>
User-Agent: Mutt/1.5.6i
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>

Sorry for the late reply, but I sent this previously with a sender
that's not subscribed to the list.

On Wed, Feb 02, 2005 at 02:21:49AM -0000, Nigel Swinson wrote:
>  It seems to me that the notify extension is trying to do too much
>  in supporting notification by email, SMS or indeed any arbitrary
>  notification mechanism.  It was pointed out quickly how many complex
>  internationalization issues you have to deal with when composing
>  emails, but you have completely different concerns when dealing with
>  SMS messages, so I'm not sure it makes sense to bundle them.

It may be easier to specify different actions than different extensions
to notify, at least current extension specifications make me think so.
So I don't mind to split things up.

>we should therefore have something more along these lines:
>
>  Syntax:   sms [":recipient" <recipient-numbers: string-list>] 
>[:limit <number>] <message: string>
>
>  The :recipient tag specifies the target phone numbers to send this SMS
>  to.  If not present, the implementation should try to send the SMS to the
>  owner of the script where the number is held by the sieve implementation,
>  ie a mailbox property.

As long as that's not a "SHOULD try", it is fine with me.  Enforcing a new
mailbox property in order to use this extension would not be nice at all.

So what if no number is specified, either explicit or implicit? Should
the action be ignored or cause the script to fail? The same question
arises on invalid number strings.  I vote for ignoring invalid numbers
and actions without any number at all.

>  If present, specifies the target number, and it
>  can also be a list of numbers if more than one recipient is desired.

Please let the implementation limit the maximum amount of specified
recipients or sms actions.

>  Each phone number must begin with a + and include the country code to
>  ensure that the script will work regardless of location of server/script.

I think that must be a MUST. :) I am sure the TON/NPI for the
international numbers you described is defined by a standard that could
be referenced here, I just don't know which one.

>  The message is a string, whereby variable expansion is also
>  permitted. The limit is the maximum number of SMS messages that the
>  server can send.  Given that each message typically has a cost associated
>  with it, the limit by default will be whatever produces the least cost
>  which in today?s terms is 1 message (140 bytes) but may change in the
>  future.

Over here, up to 160 octets do fit in a single message.  I think that
the EUR currency sign is encoded in two octets, though.  The character
set is IA5, so we have to specify what happens to unicode characters that
can not be translated to IA5.  I am used to gateways just dropping them.

Of course you could apply the length after IA5 translation, but how
about specifying the cost in number of messages (:parts)?

>  Which brings me on to variables.  Each of these different notification
>  types, and also the vacation extension to a certain degree, has the need
>  to author messages, and likely include sections of the triggering message.
>  So suppose I want to author what I think is a fairly reasonable SMS
>  which looks like this:
>             [To:<recipient-addresss>From:<sender-address>] 
><Subject>\r\n<body>

I prefer this:

               From <sender-address> To <recipient-address>: 
<Subject>\r\n<body>

I would like to allow the implementation to use a different default
format.  In case it has access to a language mailbox property, it should
be allowed to send a message in the users native language by default.

>  One way to get his is using the proposed $name$ variables which seem
>  pretty ugly next to what we've worked so hard on with the variables
>  extension, and also is pretty inflexible.

Agreed.

There are two remaining issues: Rate limiting and security.  I suggest
a new extension which specifies a condition for rate limiting, e.g.
named token buckets, to keep that out of sms.  It may be useful to forward
mail to expensive gateway addresses as well.  The sms/notify extension
should not offer builtin rate limiting.  With concern to security: The
implementation SHOULD enforce that SMS are only sent to verified numbers.
Otherwise, one typo suffices to annoy someone else like hell, apart
from letting him read part of your mail.

Michael



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 j1G8h5sm003174; Wed, 16 Feb 2005 00:43:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G8h5PG003173; Wed, 16 Feb 2005 00:43:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G8gxw1003007 for <[e-mail]>; Wed, 16 Feb 2005 00:43:04 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.47) id 1D1KlZ-0005rZ-Dj for [e-mail]; Wed, 16 Feb 2005 09:42:37 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1D1KlZ-0002Ri-Bc for [e-mail]; Wed, 16 Feb 2005 09:42:37 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.47 #4) id 1D1KlZ-0000NJ-4C for [e-mail]; Wed, 16 Feb 2005 09:42:37 +0100
Date: Wed, 16 Feb 2005 09:42:37 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Sieve base-spec revision I-D
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.5.6i
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, Feb 15, 2005 at 06:42:33PM -0800, Philip Guenther wrote:
> <editor hat off>
> 
> If I want to search for control characters in a message's subject
> (or body, using the body extension) or include them in a vacation
> reply or notification message, why shouldn't I be able to?
> 
> <editor hat on>

>From the Exim Sieve implementation:

----------
Sieve scripts can not contain NUL characters in strings, but mail
headers could contain MIME encoded NUL characters, which could never
be matched by Sieve scripts using exact comparisons.  For that reason,
this implementation extends the Sieve quoted string syntax with \0
to describe a NUL character, violating \0 being the same as 0 in
RFC 3028.  Even without using \0, the following tests are all true in
this implementation.  Implementations that use C-style strings will only
evaulate the first test as true.

Subject: =?iso-8859-1?q?abc=00def

header :contains "Subject" ["abc"]
header :contains "Subject" ["def"]
header :matches "Subject" ["abc?def"]

Note that by considering Sieve to be a MUA, RFC 2047 can be interpreted
in a way that NUL characters truncating strings is allowed for Sieve
implementations, although not recommended.  It is further allowed to use
encoded NUL characters in headers, but that's not recommended either.
The above example shows why.  Good code should still be able to deal
with it.
----------

I doubt repeating it makes a difference to anybody here, but I would
really like if RFC 3028 specified behaviour of the above comparisons.

Michael



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 j1G4fc1k033136; Tue, 15 Feb 2005 20:41:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G4fclq033134; Tue, 15 Feb 2005 20:41:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G4fa8l033117 for <[e-mail]>; Tue, 15 Feb 2005 20:41:37 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id B141135F3; Wed, 16 Feb 2005 05:41:22 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j1G4aXEl011515; Wed, 16 Feb 2005 05:36:34 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j1G4aXIN011513; Wed, 16 Feb 2005 05:36:33 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: Sieve base-spec revision I-D
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Feb 2005 05:36:26 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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, 2005-02-15 at 18:42 -0800, Philip Guenther wrote:
> Kjetil Torgrim Homme <[e-mail]> writes:
> <shrug>  Looking again, I see the various IETF webpages aren't
> consist on this, some using "email" or "Email", others using "e-mail"
> or "E-mail".  I find Donald Knuth's argument for "email", as
> reproduced by W. Richard Stevens at:
> 	http://www.kohala.com/start/papers.others/knuth.email.html
> 
> persuasive, but if there's consensus to go the other way I'll change it.

I don't find that persuasive.  the natural progression is "electronic
mail" -> "e-mail" -> "mail".  the latter is another keystroke saved. :-)

> While the prose of RFC 3028 at least partially addresses the presence
> of NUL, HTAB, CR, and LF in scripts, it doesn't ban any other valid
> UTF-8 character.  Can you speak more on why you think control codes
> should be banned from strings and comments?

"they're ugly and will mostly serve as a projectile ejector which users
can aim at their lower extremities".

but I've already changed my mind :-).  we need to mimic what [IMAIL]
accepts at least for strings and multi-line strings.  to make it easier
to comment out parts of the code, we should not make the syntax for
comments more restrictive.

NUL should be disallowed completely.

> >if we keep control characters, solitary CR or LF should be accepted just
> >as any other odd control character.

that is, with no special meaning.  this is more lax than [IMAIL], which
says

   - CR and LF MUST only occur together as CRLF; they MUST NOT appear
     independently in the body.

the grammar makes it clear that the same is true for the headers.  if
you prefer to be as strict as [IMAIL], that's fine by me, too.

> If I want to search for control characters in a message's subject
> (or body, using the body extension) or include them in a vacation
> reply or notification message, why shouldn't I be able to?

for vacation, you can use ":mime" and do the quoted-printable thing
yourself.

there is a slight problem since a header can use encoding to include NUL
and other problematic characters, and the Sieve interpreter undoes this
in order to present it all as UTF-8 or plain octets to the user.  I wish
there were an escape for including octets by value in strings, e.g.
"\x00".  that would be an incompatible change, can we do that?

(if so, I'd want "\uXXXX" and "\UXXXXXXXX" for Unicode, too (same syntax
as Java and C99))

> >wrt bracket-comment, I don't think you need to complicate it much more:
> >
> >bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
> >"*/"
> 
> That, like the version in 3028, permits "*/" in the middle of a
> comment.

I don't think so, note the placement of the parentheses.  but no matter.

> >a clarification about ":matches" would be useful: the pattern must match
> >the entire string.
> 
> How about the following for 2.7.1, paragraph 5, first sentence:
> 	The ":matches" match type specifies a wildcard match using
> 	the characters "*" and "?"; the entire value must be matched.

ok, but I think I prefer s/value/value argument/
-- 
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 j1G2uQGm024197; Tue, 15 Feb 2005 18:56:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G2uQr4024196; Tue, 15 Feb 2005 18:56:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G2uOh8024178 for <[e-mail]>; Tue, 15 Feb 2005 18:56:25 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j1G2uHa446026 for <[e-mail]>; Tue, 15 Feb 2005 21:56:17 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j1G2uGf66354 for <[e-mail]>; Tue, 15 Feb 2005 21:56:16 -0500
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j1G2uGs64824 for <[e-mail]>; Tue, 15 Feb 2005 21:56:16 -0500
Received: from SATURN ([9.12.33.9]) by mars.watson.ibm.com ID IMFd1108522575.1; Tue, 15 Feb 2005 21:56:15 -0400
Date: Tue, 15 Feb 2005 21:56:13 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: Re: Sieve base-spec revision I-D
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========1DBF34C61EEBD0FF3C8D=========="
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>

--==========1DBF34C61EEBD0FF3C8D==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> It missed at least one of the deadlines

Yes... ARGH!  9 *AM* Monday, not 9 *PM* Monday.  Grr.  So I missed it
also, having submitted the "relational" draft Monday afternoon.  :-(
Here's what I submitted, and I'll resubmit it after the IETF meeting.
The only substantive change is in the formal grammar, where I've added
definitions of the comparison terms ("gt", "ge", "lt", "le", "eq",
"ne").

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

--==========1DBF34C61EEBD0FF3C8D==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-sieve-3431bis-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-sieve-3431bis-00.txt";
 size=15219


Sieve Working Group                                         W. =
Segmuller
Internet Draft                                                  B. =
Leiba
Obsoletes: 3431 (if approved)            IBM T.J. Watson Research =
Center
Document: draft-ietf-sieve-3431bis-00.txt                  February =
2005
                                                     Expires August =
2005
                   Sieve Extension: Relational Tests
Status of this Document
   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.
   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
   This Internet-Draft will expire on August 14, 2005.
Copyright Notice
   Copyright (C) The Internet Society (2005).
Abstract
   This document describes the RELATIONAL extension to the Sieve mail
   filtering language defined in RFC 3028.  This extension extends
   existing conditional tests in Sieve to allow relational operators.=20
W. Segmuller, B. Leiba    Expires August 2005                  [Page 1]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   In addition to testing their content, it also allows for testing of
   the number of entities in header and envelope fields. =20
Meta-information on this document
   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.
   This document is intended to be an update to the existing
   "relational" extension to the Sieve mail filtering language,
   available from the RFC repository as
   <ftp://ftp.isi.edu/in-notes/rfc3431.txt>.
   This document and the Sieve language itself are being discussed on
   the MTA Filters mailing list at <mailto:[e-mail]>.=20
   Subscription requests can be sent to
   <mailto:[e-mail]?body=3Dsubscribe> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.
Conventions used in this document
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119. =20
   Conventions for notations are as in [SIEVE] section 1.1, including
   the use of [KEYWORDS] and "Syntax:" label for the definition of
   action and tagged arguments syntax, and the use of [ABNF]. =20
   The capability string associated with extension defined in this
   document is "relational".
1. Introduction
   Sieve [SIEVE] is a language for filtering e-mail messages at the =
time
   of final delivery.  It is designed to be implementable on either a
   mail client or mail server.  It is meant to be extensible, simple,
   and independent of access protocol, mail architecture, and operating
   system.  It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   Internet Messages Access Protocol (IMAP) servers, as it has no
   variables, loops, nor the ability to shell out to external programs. =

   The RELATIONAL extension provides relational operators on the
W. Segmuller, B. Leiba    Expires August 2005                  [Page 2]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   address, envelope, and header tests.  This extension also provides a
   way of counting the entities in a message header or address field. =20
   With this extension, the sieve script may now determine if a field =
is
   greater than or less than a value instead of just equivalent.  One
   use is for the x-priority field: move messages with a priority
   greater than 3 to the "work on later" folder.  Mail could also be
   sorted by the from address.  Those userids that start with 'a'-'m' =
go
   to one folder, and the rest go to another folder. =20
   The sieve script can also determine the number of fields in the
   header, or the number of addresses in a recipient field.  For
   example: are there more than 5 addresses in the to and cc fields. =20
2. Comparators
   This document does not define any comparators or exempt any
   comparators from the require clause.  Any comparator used, other =
than
   "i;octet" and "i;ascii-casemap", MUST be declared a require clause =
as
   defined in [SIEVE]. =20
   The "i;ascii-numeric" comparator, as defined in [ACAP], MUST be
   supported for any implementation of this extension.  The comparator
   "i;ascii-numeric" MUST support at least 32 bit unsigned integers. =20
   Larger integers MAY be supported.  Note: the "i;ascii-numeric"
   comparator does not support negative numbers. =20
3. Match Type
   This document defines two new match types.  They are the VALUE match
   type and the COUNT match type. =20
   The syntax is:
       MATCH-TYPE =3D/ COUNT / VALUE
       COUNT =3D ":count" relational-match
       VALUE =3D ":value" relational-match
       relational-match =3D DQUOTE ( "gt" / "ge" / "lt"
                                   / "le" / "eq" / "ne" ) DQUOTE
          ; "gt" means "greater than", the C operator ">".
          ; "ge" means "greater than or equal", the C operator ">=3D".
          ; "lt" means "less than", the C operator "<".
          ; "le" means "less than or equal", the C operator "<=3D".
W. Segmuller, B. Leiba    Expires August 2005                  [Page 3]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
          ; "eq" means "greater than", the C operator "=3D=3D".
          ; "ne" means "greater than", the C operator "!=3D".
3.1.  Match Type Value
   The VALUE match type does a relational comparison between strings. =20
   The VALUE match type may be used with any comparator which returns
   sort information. =20
   Leading and trailing white space MUST be removed from the value of
   the message for the comparison.  White space is defined as=20
       SP / HTAB / CRLF
   A value from the message is considered the left side of the =
relation.=20
   A value from the test expression, the key-list for address, =
envelope,
   and header tests, is the right side of the relation. =20
   If there are multiple values on either side or both sides, the test
   is considered true, if any pair is true.
3.2.  Match Type Count
   The COUNT match type first determines the number of the specified
   entities in the message and does a relational comparison of the
   number of entities to the values specified in the test expression. =20
   The COUNT match type SHOULD only be used with numeric comparators. =20
   The Address Test counts the number of recipients in the specified
   fields.  Group names are ignored. =20
   The Envelope Test counts the number of recipients in the specified
   envelope parts.  The envelope "to" will always have only one entry,
   which is the address of the user for whom the sieve script is
   running.  There is no way a sieve script can determine if the =
message
   was actually sent to someone else using this test.  The envelope
   "from" will be 0 if the MAIL FROM is blank, or 1 if MAIL FROM is not
   blank. =20
   The Header Test counts the total number of instances of the =
specified
   fields.  This does not count individual addresses in the "to", "cc",
   and other recipient fields. =20
   In all cases, if more than one field name is specified, the counts
   for all specified fields are added together to obtain the number for
W. Segmuller, B. Leiba    Expires August 2005                  [Page 4]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   comparison.  Thus, specifying ["to", "cc"] in an address COUNT test,
   comparing the total number of "to" and "cc" addresses; if separate
   counts are desired, they must be done in two comparisons, perhaps
   joined by "allof" or "anyof". =20
4. Example
   Using the message:=20
       received: ...
       received: ...
       subject: example
       to: [e-mail], [e-mail]
       cc: [e-mail]
   The test:=20
       address :count "ge" :comparator "i;ascii-numeric"
                       ["to", "cc"] ["3"]
   would be true and the test=20
       anyof ( address :count "ge" :comparator "i;ascii-numeric"
                       ["to"] ["3"],
               address :count "ge" :comparator "i;ascii-numeric"
                       ["cc"] ["3"] )
   would be false. =20
   To check the number of received fields in the header, the following
   test may be used:=20
       header :count "ge" :comparator "i;ascii-numeric"
                       ["received"] ["3"]
   This would return false.  But
       header :count "ge" :comparator "i;ascii-numeric"
                       ["received", "subject"] ["3"]
   would return true. =20
   The test:=20
       header :count "ge" :comparator "i;ascii-numeric"
                       ["to", "cc"] ["3"]
   will always return false on an RFC 2822 compliant message [RFC2822],
W. Segmuller, B. Leiba    Expires August 2005                  [Page 5]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   since a message can have at most one "to" field and at most one "cc"
   field.  This test counts the number of fields, not the number of
   addresses. =20
5. Extended Example
   require ["relational", "comparator-i;ascii-numeric"];
   if header :value "lt" :comparator "i;ascii-numeric"
             ["x-priority"] ["3"]
   {
      fileinto "Priority";
   }
   elseif address :count "gt" :comparator "i;ascii-numeric"
              ["to"] ["5"]
   {
      # everything with more than 5 recipients in the "to" field
      # is considered SPAM
      fileinto "SPAM";
   }
   elseif address :value "gt" :all :comparator "i;ascii-casemap"
              ["from"] ["M"]
   {
      fileinto "From N-Z";
   } else {
      fileinto "From A-M";
   }
   if allof ( address :count "eq" :comparator "i;ascii-numeric"
                      ["to", "cc"] ["1"] ,
              address :all :comparator "i;ascii-casemap"
                      ["to", "cc"] ["[e-mail]"]
   {
      fileinto "Only me";
   }
6.  IANA Considerations
   This document requests that the IANA update the entry for the
   "relational" Sieve extension to point to this document.
7. Security Considerations
   Security considerations are discussed in [SIEVE]. =20
W. Segmuller, B. Leiba    Expires August 2005                  [Page 6]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   An implementation MUST ensure that the test for envelope "to" only
   reflects the delivery to the current user.  It MUST not be possible
   for a user to determine if this message was delivered to someone =
else
   using this test.
8. Normative References
   [SIEVE]; Showalter, T.; "Sieve: A Mail Filtering Language"; RFC =
3028;
   January 2001.
   [Keywords]; Bradner, S.; "Key words for use in RFCs to
   IndicateRequirement Levels"; BCP 14; RFC 2119; March 1997.
   [ABNF]; Crocker, D.; "Augmented BNF for Syntax Specifications: =
ABNF";
   RFC 2234; November 1997. =20
   [RFC2822]; Resnick, P.; "Internet Message Format"; RFC 2822; April
   2001.
9. Non-Normative References
   [ACAP]; Newman, C. and J. G. Myers; "ACAP -- Application
   Configuration Access Protocol"; RFC 2244; November 1997.
10. Authors' Addresses
   Wolfgang Segmuller
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   Phone: [phone]
   Email: [e-mail]
   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   Phone: [phone]
   Email: [e-mail]
W. Segmuller, B. Leiba    Expires August 2005                  [Page 7]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
Intellectual Property Statement
   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].
Disclaimer of Validity
   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.
Acknowledgment
   Funding for the RFC Editor function is currently provided by the
   Internet Society.
W. Segmuller, B. Leiba    Expires August 2005                  [Page 8]

--==========1DBF34C61EEBD0FF3C8D==========--





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 j1G2gl7Z023270; Tue, 15 Feb 2005 18:42:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G2gk3N023267; Tue, 15 Feb 2005 18:42:46 -0800 (PST)
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 j1G2ggQZ023226 for <[e-mail]>; Tue, 15 Feb 2005 18:42:42 -0800 (PST) (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 j1G2gXBW011195 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 15 Feb 2005 18:42:34 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com j1G2gXBW011195
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=f3GXixydgKlpxBRfnK+n/l27WCH3hkKK1/feHiHi1y+2OnaaWYa4KOkh8kWCEh7jP Ls3nF0aebkbaju/XHCR8CpUCSgas29obiA/9kIa+v42J7E3sQMvWtvZDgZCWdJV8u5/ cLAZ2J5MtrrOV8HDEu3xfHN8rTYK8cVp85EAiRo=
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 j1G2gXT3026434; Tue, 15 Feb 2005 18:42:33 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: Sieve base-spec revision I-D 
In-reply-to: <[e-mail]> 
References: <[e-mail]>  <[e-mail]> 
Date: Tue, 15 Feb 2005 18:42:33 -0800
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:
>On Tue, 2005-02-15 at 16:22 -0800, Philip Guenther wrote:
...
>>  3. Replace "e-mail" with "email"
>
>I think this is the wrong way around, no one pronounces "e-mail" in a
>manner consistent with the spelling "email" ;-).  however, using _both_
>spellings as in 3028 certainly isn't ideal.

<shrug>  Looking again, I see the various IETF webpages aren't
consist on this, some using "email" or "Email", others using "e-mail"
or "E-mail".  I find Donald Knuth's argument for "email", as
reproduced by W. Richard Stevens at:
	http://www.kohala.com/start/papers.others/knuth.email.html

persuasive, but if there's consensus to go the other way I'll change it.


...
>>  7. Start to update grammar to only permit legal UTF-8 (incomplete)
>>     and correct various other errors and typos
>
>too bad RFC 3629 didn't include a syntax class for UTF-8 sans control
>codes, I'm sure this will be needed elsewhere, too.  if you are
>pedantic, 0x80..0x9F are also code points used for control codes.  so,
>don't use UTF8-2, but define your own

While the prose of RFC 3028 at least partially addresses the presence
of NUL, HTAB, CR, and LF in scripts, it doesn't ban any other valid
UTF-8 character.  Can you speak more on why you think control codes
should be banned from strings and comments?


...
>> I have some additional fixes for the grammar already queued up for
>> the -01 rev, so you can probably hold off on picking nits there for
>> now.  The only open issue I need feedback on there is where bare
>> CR and LF characters should be allowed.  In comments?  In strings?
>> In multiline literals?
>
>do we gain anything by supporting bare CR or LF?  I think we should
>disallow control characters altogether (except CRLF and HTAB, of
>course).  is this too big a change?  I note that 3028 only accepts NUL
>inside /**/ comments (gotcha!), so arbitrary binary data isn't supported
>currently.
>
>if we keep control characters, solitary CR or LF should be accepted just
>as any other odd control character.

<editor hat off>

If I want to search for control characters in a message's subject
(or body, using the body extension) or include them in a vacation
reply or notification message, why shouldn't I be able to?

<editor hat on>


>you are aware that quoted-string is hopelessly broken, I'm sure.

Already fixed in my copy.  :-)


>wrt bracket-comment, I don't think you need to complicate it much more:
>
>bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
>"*/"

That, like the version in 3028, permits "*/" in the middle of a
comment.  I know how to write the grammar for C-style comments; I
just need the consensus on what characters are permitted.


...
>a clarification about ":matches" would be useful: the pattern must match
>the entire string.

How about the following for 2.7.1, paragraph 5, first sentence:
	The ":matches" match type specifies a wildcard match using
	the characters "*" and "?"; the entire value must be matched.


Philip Guenther
[e-mail]



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 j1G24ReT019225; Tue, 15 Feb 2005 18:04:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G24R6B019224; Tue, 15 Feb 2005 18:04:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G24OIn019196 for <[e-mail]>; Tue, 15 Feb 2005 18:04:25 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 3E5953668; Wed, 16 Feb 2005 03:04:10 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j1G1xMu7010721; Wed, 16 Feb 2005 02:59:22 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j1G1xLgK010719; Wed, 16 Feb 2005 02:59:21 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: Sieve base-spec revision I-D
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Feb 2005 02:59:18 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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, 2005-02-15 at 16:22 -0800, Philip Guenther wrote:
> 	http://sendmail.org/draft-ietf-sieve-3028bis-00.txt
> 
> Changes from RFC 3028
>  1. Split references into normative and informative
>  2. Update references to current versions of DSN, IMAP, MDN, and UTF-8 RFCs
>  3. Replace "e-mail" with "email"

I think this is the wrong way around, no one pronounces "e-mail" in a
manner consistent with the spelling "email" ;-).  however, using _both_
spellings as in 3028 certainly isn't ideal.

>  4. Incorporate RFC 3028 errata
>  5. The "reject" action cancels the implicit keep
>  6. Replace references to ACAP with references to the i18n-comparator draft.
>     Further work is needed to completely sync with that draft.
>  7. Start to update grammar to only permit legal UTF-8 (incomplete)
>     and correct various other errors and typos

too bad RFC 3629 didn't include a syntax class for UTF-8 sans control
codes, I'm sure this will be needed elsewhere, too.  if you are
pedantic, 0x80..0x9F are also code points used for control codes.  so,
don't use UTF8-2, but define your own

  UTF8-2-NO-CTL = %xC2 %xA0-BF / %C3-DF UTF8-tail  ; excludes U+0080..U
+009F

I think defining

  UTF8-NO-CTL = UTF8-1-NO-CTL / UTF8-2-NO-CTL / UTF8-3 / UTF8-4
  UTF8-1-NO-CTL = %x20-7F

will make the rest of your grammar more readable.

> I have some additional fixes for the grammar already queued up for
> the -01 rev, so you can probably hold off on picking nits there for
> now.  The only open issue I need feedback on there is where bare
> CR and LF characters should be allowed.  In comments?  In strings?
> In multiline literals?

do we gain anything by supporting bare CR or LF?  I think we should
disallow control characters altogether (except CRLF and HTAB, of
course).  is this too big a change?  I note that 3028 only accepts NUL
inside /**/ comments (gotcha!), so arbitrary binary data isn't supported
currently.

if we keep control characters, solitary CR or LF should be accepted just
as any other odd control character.

you are aware that quoted-string is hopelessly broken, I'm sure.

wrt bracket-comment, I don't think you need to complicate it much more:

bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
"*/"

> The other open issues on my list are:
> 
> 1) removal of the "Tests MUST NOT have side effects" restriction.
>    We must permit the behavior of the 'variables' extension; do we
>    still want to discourage side-effects in general or should the
>    last two paragraphs of section 2.5 simply be dropped?
> 
> 2) some other clarifications that Cyrus forwarded to me that I
>    haven't rolled in yet.  (sorry)

a clarification about ":matches" would be useful: the pattern must match
the entire string.

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 j1G0MvR7010547; Tue, 15 Feb 2005 16:22:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G0Mu8t010546; Tue, 15 Feb 2005 16:22:56 -0800 (PST)
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 j1G0MunL010536 for <[e-mail]>; Tue, 15 Feb 2005 16:22:56 -0800 (PST) (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 j1G0Mq1r029053 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Tue, 15 Feb 2005 16:22:52 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com j1G0Mq1r029053
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=kgvMfFM4kO6ZAieR6oypxF81/kfoSRXJvp1r6ZEuGxmq2HG9K/RShMQq2Wfsgb+s9 LY3QKlIFAUAc5ji+buycHkzRxkhOVZwXHJIbZ8jLe7nMzVFrtNqCHDzdy6xsnyt1zMR 3DR5nxxfffWc8VpAQjFj5K+eIMXTJQhJoxdpTGo=
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 j1G0Mq0U013635 for <[e-mail]>; Tue, 15 Feb 2005 16:22:52 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Sieve base-spec revision I-D
Date: Tue, 15 Feb 2005 16:22:52 -0800
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>

It missed at least one of the deadlines, so the I-D for the revision
of RFC 3028 can be found at:
	http://sendmail.org/draft-ietf-sieve-3028bis-00.txt

Changes from RFC 3028
 1. Split references into normative and informative
 2. Update references to current versions of DSN, IMAP, MDN, and UTF-8 RFCs
 3. Replace "e-mail" with "email"
 4. Incorporate RFC 3028 errata
 5. The "reject" action cancels the implicit keep
 6. Replace references to ACAP with references to the i18n-comparator draft.
    Further work is needed to completely sync with that draft.
 7. Start to update grammar to only permit legal UTF-8 (incomplete)
    and correct various other errors and typos
 8. Update IPR broilerplate


I have some additional fixes for the grammar already queued up for
the -01 rev, so you can probably hold off on picking nits there for
now.  The only open issue I need feedback on there is where bare
CR and LF characters should be allowed.  In comments?  In strings?
In multiline literals?

The other open issues on my list are:

1) removal of the "Tests MUST NOT have side effects" restriction.
   We must permit the behavior of the 'variables' extension; do we
   still want to discourage side-effects in general or should the
   last two paragraphs of section 2.5 simply be dropped?

2) some other clarifications that Cyrus forwarded to me that I
   haven't rolled in yet.  (sorry)

3) are there other changes that should be made to synchronize with
   the i18n-comparator draft?


Respectfully submitted,

Philip Guenther
[e-mail]



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 j1CLcPKE017163; Sat, 12 Feb 2005 13:38:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1CLcPZ1017162; Sat, 12 Feb 2005 13:38:25 -0800 (PST)
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 j1CLcOkV017154 for <[e-mail]>; Sat, 12 Feb 2005 13:38:24 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 29832 invoked by uid 101); 12 Feb 2005 16:38:21 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 12 Feb 2005 16:38:21 -0500
To: [e-mail]
Cc: Matthew Elvey <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <006601c50ab9$b1ed3eb0$6501a8c0@nigelhome> <[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 Sat, Feb 12, 2005 at 12:45:42PM -0800, [e-mail] wrote:
> >>FWIW, I personally don't see any need for more levels, but I have seen
> >>some user requests for this and I understand others have seen considerable
> >>demand for it.
> 
> >Any of it compelling?
> 
> The one I find somewhat compelling is the desire to convert to existing uses
> and cutoff values for SpamAssassin to sieve and spamtest. SpamAssassin uses
> real numbered scores and the obvious mapping to a 1-10 scale is a bit too
> grainy. A 1-100 scale, OTOH, is more than sufficient.

I'm kind of on the middle on this one.  In general I like to avoid
hardwiring runtime elements into the language, preferring instead to
give options to the script writers.  You just can't always predict what
people want, so trying not to guess is best.  My ideal would be to say
"the spam test returns a value of this type" where "type" could include
a fundamental data type (e.g. an integer, a string, a floating point
number) as well as a range (e.g. integer between 6 and 10, a string
containing one of a number of keywords, and so forth).  Much of that
doesn't fit here, of course.

But indeed I have heard from people who want far greater ranges than
0 to 10.  To quote one anonymously, specifically about spam scores:

    You can't easily use those results from procmail, as it can't do
    numeric comparisons like 'if ( ( prob >= 99.0 ) && ( prob < 99.9 ) )
    ...' to decide where to file; you need to write them in terms of
    pattern matching which gets messy.

So there's at least one person calling for a range of 0 to 1000!

There are other analyzers out there that return a floating point spam
score, although they tend to have their own ability to emit a summary
header based on a threshold.

Personally I'd try to find a way to say "map the spam test into a range
from m to n" rather than hardwiring one or two ranges in advance.  There
would be no problem in having a default (e.g. m=0, n=10).

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 j1CKo0qf014545; Sat, 12 Feb 2005 12:50:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1CKo00T014544; Sat, 12 Feb 2005 12:50:00 -0800 (PST)
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 j1CKnser014535 for <[e-mail]>; Sat, 12 Feb 2005 12:49:55 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 12 Feb 2005 12:49:48 -0800 (PST)
Cc: [e-mail], IETF MTA Filters List <[e-mail]>
Date: Sat, 12 Feb 2005 12:45:42 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Sat, 12 Feb 2005 10:42:20 -0800" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <006601c50ab9$b1ed3eb0$6501a8c0@nigelhome> <[e-mail]> <[e-mail]>
Subject: Re: spamtestbis
To: Matthew Elvey <[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 2/4/2005 10:41 AM, [e-mail] sent forth electrons to convey:

> >
> >
> >>>>FYI the draft for the new version of the spamtest extension is now
> >>>>available. The only change between this and the current RFC is the addition
> >>>>of a :percent argument to the spamtest test to allow for a numeric range of
> >>>>0 - 100. The value -1 is used to indicate a message that was not
> >>>>categorised in anyway.
> >>>>
> >>>>
> >
> >
> >
> >>I'm surprised we need a percentage spam score... I would have thought 10
> >>levels was enough.  Indeed in your example you use level 30(%) = 3.
> >>
> >>
> >
> >FWIW, I personally don't see any need for more levels, but I have seen
> >some user requests for this and I understand others have seen considerable
> >demand for it.
> >
> >

> Any of it compelling?

The one I find somewhat compelling is the desire to convert to existing uses
and cutoff values for SpamAssassin to sieve and spamtest. SpamAssassin uses
real numbered scores and the obvious mapping to a 1-10 scale is a bit too
grainy. A 1-100 scale, OTOH, is more than sufficient.

> Sometimes, there's considerable demand for bad
> ideas (e.g. to accept spam from open relays, e.g. from an  EFF founder -
> http://www.toad.com/gnu/)  I thought we discussed this and decided 10
> was enough levels, but I find no mention of it in the archives.

This is a long way from being a bad idea.

				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 j1CIgW4I008268; Sat, 12 Feb 2005 10:42:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1CIgWAe008267; Sat, 12 Feb 2005 10:42:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1CIgR4b008261 for <[e-mail]>; Sat, 12 Feb 2005 10:42:31 -0800 (PST) (envelope-from [e-mail])
Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 7F999C5722E; Sat, 12 Feb 2005 13:42:22 -0500 (EST)
X-Sasl-enc: thpP9jmEoNPY3ZbhlFpylQ 1108233741
Received: from [192.168.2.85] (adsl-67-123-77-49.dsl.snfc21.pacbell.net [67.123.77.49]) by frontend2.messagingengine.com (Postfix) with ESMTP id F348775E; Sat, 12 Feb 2005 13:42:20 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 10:42:20 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis
References: <[e-mail]> <[e-mail]> <006601c50ab9$b1ed3eb0$6501a8c0@nigelhome> <[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>

On 2/4/2005 10:41 AM, [e-mail] sent forth electrons to convey:

>  
>
>>>>FYI the draft for the new version of the spamtest extension is now
>>>>available. The only change between this and the current RFC is the addition
>>>>of a :percent argument to the spamtest test to allow for a numeric range of
>>>>0 - 100. The value -1 is used to indicate a message that was not
>>>>categorised in anyway.
>>>>        
>>>>
>
>  
>
>>I'm surprised we need a percentage spam score... I would have thought 10
>>levels was enough.  Indeed in your example you use level 30(%) = 3.
>>    
>>
>
>FWIW, I personally don't see any need for more levels, but I have seen
>some user requests for this and I understand others have seen considerable
>demand for it.
>  
>
Any of it compelling?  Sometimes, there's considerable demand for bad 
ideas (e.g. to accept spam from open relays, e.g. from an  EFF founder - 
http://www.toad.com/gnu/)  I thought we discussed this and decided 10 
was enough levels, but I find no mention of it in the archives.



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 j1CFuMf3097126; Sat, 12 Feb 2005 07:56:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1CFuMRL097125; Sat, 12 Feb 2005 07:56:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1CFuFsp097114 for <[e-mail]>; Sat, 12 Feb 2005 07:56:19 -0800 (PST) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id CC7DFC56483 for <[e-mail]>; Sat, 12 Feb 2005 10:56:11 -0500 (EST)
X-Sasl-enc: WS7o1fPk6aR5eabZ7dbJ3Q 1108223771
Received: from [192.168.2.86] (adsl-216-100-137-15.dsl.snfc21.pacbell.net [216.100.137.15]) by frontend3.messagingengine.com (Postfix) with ESMTP id EEB05247F3; Sat, 12 Feb 2005 10:56:10 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 07:56:10 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric SOHIER <[e-mail]>
Cc: [e-mail]
Subject: Re: Regulate sieve which does not go!
References: <000f01c50c28$274781b0$0864a8c0@eric>
In-Reply-To: <000f01c50c28$274781b0$0864a8c0@eric>
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>

On 2/6/2005 12:45 AM, Eric SOHIER sent forth electrons to convey:

>Hello,
>
> 
>
>I'm a new member of the list and I use the service fmailbox which manages
>the rules sieve.
>
> 
>
>I would like to know how to describe a rule which makes it possible to move
>a message which contains a specific address "from"?
>  
>
This kind of question would be more appropriate to ask (or self-answer) 
starting here:
http://wiki.fastmail.fm/index.php/SieveExamples, such as on the fastmail 
forum.

Your sieve has a syntax error (the ":" is in the wrong place).

> 
>
>I tested this:
>
> 
>
>If header: contains ["To"] ["[e-mail]"] {fileinto
>"INBOX.Astronomie.astrocam";}
>
> 
>
>But that does not go on this message:
>
> 
>
>X-Sender: [e-mail]
>
>X-Apparently-To: [e-mail]
>
>Received: (qmail 26728 invoked from network); 21 Jan 2005 13:46:09 -0000
>
>Received: from unknown (66.218.66.218)
>
>  by m17.grp.scd.yahoo.com with QMQP; 21 Jan 2005 13:46:09 -0000
>
>Received: from unknown (HELO hotmail.com) (65.54.185.29)
>
>  by mta3.grp.scd.yahoo.com with SMTP; 21 Jan 2005 13:46:09 -0000
>
>Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
>
>      Fri, 21 Jan 2005 05:42:02 -0800
>
>Message-ID: <[e-mail]>
>
>Received: from 84.195.167.88 by by15fd.bay15.hotmail.msn.com with HTTP;
>
>     Fri, 21 Jan 2005 13:41:05 GMT
>
>X-Originating-Email: [[e-mail]]
>
>X-Sender: [e-mail]
>
>To: [e-mail], [e-mail],
>
>     [e-mail]
>
>X-OriginalArrivalTime: 21 Jan 2005 13:42:02.0351 (UTC)
>FILETIME=[FCCEFFF0:01C4FFBE]
>
>X-eGroups-Remote-IP: 65.54.185.29
>
>From: "patricia david" <[e-mail]>
>
>X-Originating-IP: [84.195.167.88]
>
>X-Yahoo-Profile: astrobourlingueurs
>
>MIME-Version: 1.0
>
>Mailing-List: list [e-mail]; contact
>[e-mail]
>
>Delivered-To: mailing list [e-mail]
>
>Precedence: bulk
>
>List-Unsubscribe: <mailto:[e-mail]>
>
>Date: Fri, 21 Jan 2005 13:41:05 +0000
>
>Subject: [astrocam] Tete de cheval
>
>Content-Type: multipart/mixed;
>
> boundary="----=_NextPart_000_4a7a_535c_14b6"
>
> 
>
>Why ?
>
> 
>
>Thanks by advance.
>
> 
>
>-- Eric SOHIER
>
> 
>
>
>  
>



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 j1BDwoj9072005; Fri, 11 Feb 2005 05:58:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1BDwoQQ072004; Fri, 11 Feb 2005 05:58:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BDwgZp071990 for <[e-mail]>; Fri, 11 Feb 2005 05:58:44 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 11 Feb 2005 13:56:16 +0000
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 13:56:14 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
References: <[e-mail]>	 <[e-mail]>  <[e-mail]>	 <[e-mail]>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Kjetil Torgrim Homme wrote:

>On Fri, 2005-02-11 at 00:03 +0000, Alexey Melnikov wrote:
>  
>
>>Kjetil Torgrim Homme wrote:
>>    
>>
>>>>>Does each string in "list-of-flags" contain exactly one flag, or can
>>>>>each string be a list of flags as in other usage?
>>>>>          
>>>>>
>>>>The intention was to have the former. I will try to clarify.
>>>>        
>>>>
>>>if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
>>>to be in conflict with RFC 3028.  see section 2.4.2.1:
>>>      
>>>
>>You assume that a list-of-flags = ["A", "B"] is the same as ["A B"]. I 
>>originally didn't make such assumption, but I might be convinced that 
>>this is the right thing to do.
>>    
>>
>
>I'm not sure I do.  what is clear:  the argument is a list of strings.
>according to 3028, a list containing only one string may omit the
>brackets.  in other words,
>["A B"] MUST be the same as "A B".
>
I've just realized that we are talking about different things. The 
original question was whether "A B" is interpreted as ["A", "B"]. And as 
you pointed out below, the answer I gave to Mark recent was wrong.

And yes, ["A B"] is the same as "A B", even for the hasflag test.

>  whether this is the same as ["A",
>"B"] is a matter open for debate, but your draft currently say that they
>are:
>
>   hasflag :is "MyFlags" "b A"
>   [...] can be also written as
>   hasflag "MyFlags" ["b","A"]
>  
>



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 j1BDohD7071179; Fri, 11 Feb 2005 05:50:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1BDoflp071175; Fri, 11 Feb 2005 05:50:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BDoBgv071071 for <[e-mail]>; Fri, 11 Feb 2005 05:50:20 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 13BBB36AB; Fri, 11 Feb 2005 14:49:09 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j1BDinl0012344; Fri, 11 Feb 2005 14:44:49 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j1BDilK8012342; Fri, 11 Feb 2005 14:44:47 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[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
Content-Transfer-Encoding: 7bit
Date: Fri, 11 Feb 2005 14:44:46 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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, 2005-02-11 at 00:03 +0000, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >>>Does each string in "list-of-flags" contain exactly one flag, or can
> >>>each string be a list of flags as in other usage?
> >>
> >>The intention was to have the former. I will try to clarify.
> >
> >if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
> >to be in conflict with RFC 3028.  see section 2.4.2.1:
>
> You assume that a list-of-flags = ["A", "B"] is the same as ["A B"]. I 
> originally didn't make such assumption, but I might be convinced that 
> this is the right thing to do.

I'm not sure I do.  what is clear:  the argument is a list of strings.
according to 3028, a list containing only one string may omit the
brackets.  in other words,
["A B"] MUST be the same as "A B".  whether this is the same as ["A",
"B"] is a matter open for debate, but your draft currently say that they
are:

   hasflag :is "MyFlags" "b A"
   [...] can be also written as
   hasflag "MyFlags" ["b","A"]
-- 
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 j1BAg4q3013703; Fri, 11 Feb 2005 02:42:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1BAg40t013702; Fri, 11 Feb 2005 02:42:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BAg1lC013584 for <[e-mail]>; Fri, 11 Feb 2005 02:42:03 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 11 Feb 2005 10:42:01 +0000
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 00:03:37 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
References: <[e-mail]>	 <[e-mail]>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Kjetil Torgrim Homme wrote:

>On Wed, 2005-02-09 at 18:55 +0000, Alexey Melnikov wrote:
>  
>
>>Mark E. Mallett wrote:
>>    
>>
>>>4.  Test hasflag
>>>
>>>I'm having a hard time understanding what this test does in other than
>>>simple cases.  
>>>
>>>  > The "hasflag" test evaluates to true if any of the variables matches any
>>>  > flag name.
>>>
>>>Does this mean "contains any of the flags listed in list-of-flags" ?
>>>or "contains all of the flags listed in list-of-flags"?
>>>or "matches (according to match-type) the concatenation of flags
>>>contained in all of the list-of-flags strings, subject to canonical
>>>re-ordering"?
>>>      
>>>
>>"any flag name" means the first choice.
>>    
>>
>
>yes, this is in line with the behaviour of other tests, e.g.
>
>  address :localpart ["To", "Cc"] ["kjetilho", "alexey"]
>  
>
Exactly.

>>>Does each string in "list-of-flags" contain exactly one flag, or can
>>>each string be a list of flags as in other usage?
>>>      
>>>
>>The intention was to have the former. I will try to clarify.
>>    
>>
>
>if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
>to be in conflict with RFC 3028.  see section 2.4.2.1:
>  
>
You assume that a list-of-flags = ["A", "B"] is the same as ["A B"]. I 
originally didn't make such assumption, but I might be convinced that 
this is the right thing to do.

>   Conversely, in any case where a list of strings is appropriate, a
>   single string is allowed without being a member of a list: it is
>   equivalent to a list with a single member.  This means that the test
>   `exists "To"' is equivalent to the test `exists ["To"]'.
>  
>




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 j1BAg3Y1013689; Fri, 11 Feb 2005 02:42:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1BAg3aS013688; Fri, 11 Feb 2005 02:42:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BAg1lB013584 for <[e-mail]>; Fri, 11 Feb 2005 02:42:02 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 11 Feb 2005 10:41:39 +0000
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2005 22:57:49 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Mark E. Mallett wrote:

>On Wed, Feb 09, 2005 at 06:55:14PM +0000, Alexey Melnikov wrote:
>  
>
>>Mark E. Mallett wrote:
>>    
>>
>>>10. Extended example
>>>
>>> > elsif anyof (not address :all :contains
>>> >                ["To", "Cc"] "[e-mail]",
>>> >              header :matches "subject"
>>> >                ["*make*money*fast*", "*university*dipl*mas*"])
>>> >         {
>>> >         remove "MyFlags" "\\Flagged";
>>> >         # If message header does not contain my address,
>>> >         # it's from a list.
>>> >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
>>> >         }
>>> > else
>>> >         {
>>> >         # Move all other (non-company) mail to "personal"
>>> >         # folder.
>>>
>>>My eyes may be glazing over, but have we really established
>>>"non-company" mail at this point?  One of the ways we get here
>>>is if "to" or "cc" contain "[e-mail]"
>>>      
>>>
>>Everything which is not from the known mailing lists, non-company 
>>related (not sent/addressed by/to people from the company) and addressed 
>>to me goes to "personal".
>>    
>>
>
>The point is that I don't think that's true where that comment says
>it is.  When you get to that point, you can have the "To" or "Cc"
>field containing "[e-mail]" which seems to indicate a
>company-related message.
>  
>
Right, we are actually talking about the same thing :-).
When we get to this branch, it means that a message was sent by somebody 
outside of the company.
I called this "personal" mail.

So yes, the comment should be updated.

>Is my mental interpreter failing?
>  
>
No, I needed to reboot mine :-).




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 j19LE3W6062779; Wed, 9 Feb 2005 13:14:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19LE3ct062778; Wed, 9 Feb 2005 13:14:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19LE2v8062755 for <[e-mail]>; Wed, 9 Feb 2005 13:14:02 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 558F23A93; Wed,  9 Feb 2005 22:13:48 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j19L9cCs007333; Wed, 9 Feb 2005 22:09:38 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j19L9bA7007331; Wed, 9 Feb 2005 22:09:37 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 09 Feb 2005 22:09:36 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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, 2005-02-09 at 18:55 +0000, Alexey Melnikov wrote:
> Mark E. Mallett wrote:
> >4.  Test hasflag
> >
> >I'm having a hard time understanding what this test does in other than
> >simple cases.  
> >
> >   > The "hasflag" test evaluates to true if any of the variables matches any
> >   > flag name.
> >
> >Does this mean "contains any of the flags listed in list-of-flags" ?
> >or "contains all of the flags listed in list-of-flags"?
> >or "matches (according to match-type) the concatenation of flags
> >contained in all of the list-of-flags strings, subject to canonical
> >re-ordering"?
>
> "any flag name" means the first choice.

yes, this is in line with the behaviour of other tests, e.g.

  address :localpart ["To", "Cc"] ["kjetilho", "alexey"]

> >Does each string in "list-of-flags" contain exactly one flag, or can
> >each string be a list of flags as in other usage?
>
> The intention was to have the former. I will try to clarify.

if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
to be in conflict with RFC 3028.  see section 2.4.2.1:

   Conversely, in any case where a list of strings is appropriate, a
   single string is allowed without being a member of a list: it is
   equivalent to a list with a single member.  This means that the test
   `exists "To"' is equivalent to the test `exists ["To"]'.

-- 
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 j19JSG2l056551; Wed, 9 Feb 2005 11:28:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19JSG7O056550; Wed, 9 Feb 2005 11:28:16 -0800 (PST)
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 j19JSFs9056543 for <[e-mail]>; Wed, 9 Feb 2005 11:28:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 54372 invoked by uid 101); 9 Feb 2005 14:28:12 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 9 Feb 2005 14:28:12 -0500
To: Alexey Melnikov <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
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 Wed, Feb 09, 2005 at 06:55:14PM +0000, Alexey Melnikov wrote:
> Mark E. Mallett wrote:

> >10. Extended example
> >
> >  > elsif anyof (not address :all :contains
> >  >                ["To", "Cc"] "[e-mail]",
> >  >              header :matches "subject"
> >  >                ["*make*money*fast*", "*university*dipl*mas*"])
> >  >         {
> >  >         remove "MyFlags" "\\Flagged";
> >  >         # If message header does not contain my address,
> >  >         # it's from a list.
> >  >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
> >  >         }
> >  > else
> >  >         {
> >  >         # Move all other (non-company) mail to "personal"
> >  >         # folder.
> >
> >My eyes may be glazing over, but have we really established
> >"non-company" mail at this point?  One of the ways we get here
> >is if "to" or "cc" contain "[e-mail]"
> > 
> >
> Everything which is not from the known mailing lists, non-company 
> related (not sent/addressed by/to people from the company) and addressed 
> to me goes to "personal".

The point is that I don't think that's true where that comment says
it is.  When you get to that point, you can have the "To" or "Cc"
field containing "[e-mail]" which seems to indicate a
company-related message.

Is my mental interpreter failing?

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 j19JG37D055621; Wed, 9 Feb 2005 11:16:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19JG3N6055620; Wed, 9 Feb 2005 11:16:03 -0800 (PST)
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 j19JG2md055614 for <[e-mail]>; Wed, 9 Feb 2005 11:16:02 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 49097 invoked by uid 101); 9 Feb 2005 14:16:01 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 9 Feb 2005 14:16:01 -0500
To: [e-mail]
Cc: Mark E Mallett <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Message-ID: <[e-mail]>
References: <[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, Feb 09, 2005 at 10:39:32AM -0800, [e-mail] wrote:
> > On Tue, Feb 08, 2005 at 04:28:06PM -0800, [e-mail] wrote:
> > > Without setflag I would expect to see stuff of the form
> > >
> > >     set "foo" "";
> > >     addflag "foo" "bar";
> 
> > Is the first line strictly necessary?  i.e. can you manipulate variables
> > via addflag et al if those variables haven't been instantiated?
> 
> You can but it is beside the point. The issue is that the variable may
> have been previously initialized to have some other value.

Yeah, I would say that it would be poor practice to reference an
uninitialized variable.  The question about being able to reference an
unitialized variable was a tangential wondering.

As to whether you would always see those pairs of statements together:
probably not, at least for me.  In practice I would probably initialize
the variable in some preamble and then adjust it as necessary.
Certainly another "set" to "" could be used if needed.


> > > Whether or not this savings warrants an entire action is a judgement call.
> > > Having implemented it I can say that for me at least supporting setflag only
> > > amounted to about 15 additional lines of code and one additional table entry.
> 
> > I think having extra stuff in the language is more the point than how
> > hard it is to add that extra stuff.  I would also prefer not to have
> > verbs that aren't really needed.
> 
> Implementation difficulty is definitely a factor to consider IMO, as is whether
> or not the verb will actually be used. Stuff that's hard to implement increases
> the liklihood of bugs, as does having stuff that's rarely used (rarely used
> code is often a place where bugs lurk).

OK, but "let's avoid it because it's hard to implement" is quite different
from "let's add it in because it's easy to implement."  My point is
let's consider whether we need it or not, and not just add it because
it's easy.  Syntax clutter is still clutter even if it's easy.

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 j19ItoTd054542; Wed, 9 Feb 2005 10:55:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19ItoLN054541; Wed, 9 Feb 2005 10:55:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19ItnHB054533 for <[e-mail]>; Wed, 9 Feb 2005 10:55:49 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.126] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 9 Feb 2005 18:55:17 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 18:55:14 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: "Mark E. Mallett" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
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>

Mark E. Mallett wrote:

>Some more random comments.
>
>1. Introduction
>
>   > This extension depends on the presence of "variables" extension
>   > [Variables].
>
>Should you mention that this isn't an automatic dependency?  i.e.
>that the script writer still has to require variables?
>
I've added:
   This means that a script using this extension MUST list both 
"variables" and "imap4flags" in a require statement.

in order to clarify.

>><<Extension name has been changed as revision 03 of this document is widely
>>deployed in CMU Cyrus server>>
>>    
>>
>
>Isn't this problematic in terms of the relationship between drafts
>and implementations?
>  
>
It is surely is, but I don't know a generic solution for the problem.

>2.1. General requirements for flag handling
>
>   >  A string
>   > containing a space separated list of flags ...
>
>nit:  "space-separated"
>(repeat for other occurances in the document)
>  
>
fixed.

>   > If a flag validity check fails the flag should be silently
>   > dropped, but a warning message should be logged by the Sieve interpreter.
>
>nit one:  I would say "ignored" since "dropped" could be read as
>"removed from the message" rather than "not paid attention to in the
>Sieve statement."  (Even though the flag wouldn't be associated with the
>message if it's invalid: but I'm talking English grammar here, not
>logic.)
>  
>
Ok.

>nit two:  I would use a word other than "logged" -- warnings may
>be issued in other ways than logging.
>
>nit three: should "should" be "SHOULD" ?
>  
>
Yes.

>nit four: if the error should be reported, in what way is it silently
>ignored?
>
Maybe the better way of conveying my idea is to say that a failure to 
set a certain flag doesn't stop other flags from being set and doesn't 
cause a runtime error.

>
>
>
>3. Actions
>
>   > The "set" action
>   > defined in [Variables] can be used to replaces an existing set of flags
>   > with a new set as well.
>
>nit: "replace" (instead of "replaces")
>  
>
Thanks.

>3.1. Setflag Action
>
>        > if header :contains "from" "[e-mail]" {
>
>Prohibition on using real domain names in documents?  (i.e.,
>"example.edu")  Repeat for other occurances in the document.
>  
>
Fixed.

>4.  Test hasflag
>
>I'm having a hard time understanding what this test does in other than
>simple cases.  
>
>   > The "hasflag" test evaluates to true if any of the variables matches any
>   > flag name.
>
>Does this mean "contains any of the flags listed in list-of-flags" ?
>or "contains all of the flags listed in list-of-flags"?
>or "matches (according to match-type) the concatenation of flags
>contained in all of the list-of-flags strings, subject to canonical
>re-ordering"?
>
"any flag name" means the first choice.

>
>Does each string in "list-of-flags" contain exactly one flag, or can
>each string be a list of flags as in other usage?
>
The intention was to have the former. I will try to clarify.

>Perhaps more examples would help.
>
Yes.

>
>
>
>6. Implementation Notes
>
>   > "addflag <variable> <flag>" can be implemented as:
>   > 
>   >  if not string :matches :comparator "i;ascii-casemap"
>   >     " ${<variable>} " "* <flag> *" {
>   >      set <variable> "${<variable>} <flag>"
>   >  }
>
>Note that you'll get a superfluous leading space if <variable> starts
>out empty.  Probably doesn't need saying, though, except that the
>following "removeflag" example goes to great pains to remove leading
>and trailing spaces.
>
Ok.

>
>
>   > "removeflag <variable> <flag>" can be implemented as:
>   > 
>   >  if string :matches :comparator "i;ascii-casemap" " ${<variable>} "
>   >     "* <flag> *" {
>   >      set <variable> "${1}${2}";
>   >  }
>
>Should be "${1} ${2}", no?
>
Good catch, thanks.

>
>10. Extended example
>
>   > elsif anyof (not address :all :contains
>   >                ["To", "Cc"] "[e-mail]",
>   >              header :matches "subject"
>   >                ["*make*money*fast*", "*university*dipl*mas*"])
>   >         {
>   >         remove "MyFlags" "\\Flagged";
>   >         # If message header does not contain my address,
>   >         # it's from a list.
>   >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
>   >         }
>   > else
>   >         {
>   >         # Move all other (non-company) mail to "personal"
>   >         # folder.
>
>My eyes may be glazing over, but have we really established
>"non-company" mail at this point?  One of the ways we get here
>is if "to" or "cc" contain "[e-mail]"
>  
>
Everything which is not from the known mailing lists, non-company 
related (not sent/addressed by/to people from the company) and addressed 
to me goes to "personal".

Thank you for the comments!
Alexey



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 j19Il4sN053869; Wed, 9 Feb 2005 10:47:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19Il425053868; Wed, 9 Feb 2005 10:47:04 -0800 (PST)
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 j19Il3sN053835 for <[e-mail]>; Wed, 9 Feb 2005 10:47:03 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 09 Feb 2005 10:46:46 -0800 (PST)
Cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Date: Wed, 09 Feb 2005 10:39:32 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Wed, 09 Feb 2005 12:00:56 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
To: Mark E Mallett <[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 Tue, Feb 08, 2005 at 04:28:06PM -0800, [e-mail] wrote:
> > Without setflag I would expect to see stuff of the form
> >
> >     set "foo" "";
> >     addflag "foo" "bar";

> Is the first line strictly necessary?  i.e. can you manipulate variables
> via addflag et al if those variables haven't been instantiated?

You can but it is beside the point. The issue is that the variable may
have been previously initialized to have some other value.

> I would think that you could.

You can, but again, that's beside the point.
 
> > Whether or not this savings warrants an entire action is a judgement call.
> > Having implemented it I can say that for me at least supporting setflag only
> > amounted to about 15 additional lines of code and one additional table entry.

> I think having extra stuff in the language is more the point than how
> hard it is to add that extra stuff.  I would also prefer not to have
> verbs that aren't really needed.

Implementation difficulty is definitely a factor to consider IMO, as is whether
or not the verb will actually be used. Stuff that's hard to implement increases
the liklihood of bugs, as does having stuff that's rarely used (rarely used
code is often a place where bugs lurk).

This, BTW, is why I'm basically opposed to the proposals to add associative
arrays to the language. Implementation of such facilities is going to be
complex and since it will have to be a separate extension the odds of it
being widely used are low. This is a recipe for bugs, and when you consider
that there are other ways to do all of this...

				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 j19HphpT049720; Wed, 9 Feb 2005 09:51:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19HphTe049718; Wed, 9 Feb 2005 09:51:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19HpgXR049710 for <[e-mail]>; Wed, 9 Feb 2005 09:51:42 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.126] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 9 Feb 2005 17:51:30 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 17:51:25 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Mark E. Mallett wrote:

>On Tue, Feb 08, 2005 at 04:28:06PM -0800, [e-mail] wrote:
>  
>
>>Without setflag I would expect to see stuff of the form
>>
>>    set "foo" "";
>>    addflag "foo" "bar";
>>    
>>
>
>Is the first line strictly necessary?  i.e. can you manipulate variables
>via addflag et al if those variables haven't been instantiated?
>I would think that you could.
>  
>
I guess you are right (assuming the script writer is not reusing the 
variable "foo"), but I am not sure I approve this as a good script 
writing technique.

>>Whether or not this savings warrants an entire action is a judgement call.
>>Having implemented it I can say that for me at least supporting setflag only
>>amounted to about 15 additional lines of code and one additional table entry.
>>    
>>
>
>I think having extra stuff in the language is more the point than how
>hard it is to add that extra stuff.  I would also prefer not to have
>verbs that aren't really needed.
>  
>
I prefer to have "setflag" for consistency.



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 j19H7MPQ046520; Wed, 9 Feb 2005 09:07:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19H7M0Z046519; Wed, 9 Feb 2005 09:07:22 -0800 (PST)
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 j19H7LOh046512 for <[e-mail]>; Wed, 9 Feb 2005 09:07:21 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 98449 invoked by uid 101); 9 Feb 2005 12:07:21 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 9 Feb 2005 12:07:21 -0500
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
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>

Some more random comments.

1. Introduction

   > This extension depends on the presence of "variables" extension
   > [Variables].

Should you mention that this isn't an automatic dependency?  i.e.
that the script writer still has to require variables?


> <<Extension name has been changed as revision 03 of this document is widely
> deployed in CMU Cyrus server>>

Isn't this problematic in terms of the relationship between drafts
and implementations?


2.1. General requirements for flag handling

   >  A string
   > containing a space separated list of flags ...

nit:  "space-separated"
(repeat for other occurances in the document)


   > If a flag validity check fails the flag should be silently
   > dropped, but a warning message should be logged by the Sieve interpreter.

nit one:  I would say "ignored" since "dropped" could be read as
"removed from the message" rather than "not paid attention to in the
Sieve statement."  (Even though the flag wouldn't be associated with the
message if it's invalid: but I'm talking English grammar here, not
logic.)

nit two:  I would use a word other than "logged" -- warnings may
be issued in other ways than logging.

nit three: should "should" be "SHOULD" ?

nit four: if the error should be reported, in what way is it silently
ignored?


3. Actions

   > The "set" action
   > defined in [Variables] can be used to replaces an existing set of flags
   > with a new set as well.

nit: "replace" (instead of "replaces")



3.1. Setflag Action

        > if header :contains "from" "[e-mail]" {

Prohibition on using real domain names in documents?  (i.e.,
"example.edu")  Repeat for other occurances in the document.



4.  Test hasflag

I'm having a hard time understanding what this test does in other than
simple cases.  

   > The "hasflag" test evaluates to true if any of the variables matches any
   > flag name.

Does this mean "contains any of the flags listed in list-of-flags" ?
or "contains all of the flags listed in list-of-flags"?
or "matches (according to match-type) the concatenation of flags
contained in all of the list-of-flags strings, subject to canonical
re-ordering"?

Does each string in "list-of-flags" contain exactly one flag, or can
each string be a list of flags as in other usage?

Perhaps more examples would help.



6. Implementation Notes

   > "addflag <variable> <flag>" can be implemented as:
   > 
   >  if not string :matches :comparator "i;ascii-casemap"
   >     " ${<variable>} " "* <flag> *" {
   >      set <variable> "${<variable>} <flag>"
   >  }

Note that you'll get a superfluous leading space if <variable> starts
out empty.  Probably doesn't need saying, though, except that the
following "removeflag" example goes to great pains to remove leading
and trailing spaces.


   > "removeflag <variable> <flag>" can be implemented as:
   > 
   >  if string :matches :comparator "i;ascii-casemap" " ${<variable>} "
   >     "* <flag> *" {
   >      set <variable> "${1}${2}";
   >  }

Should be "${1} ${2}", no?



10. Extended example

   > elsif anyof (not address :all :contains
   >                ["To", "Cc"] "[e-mail]",
   >              header :matches "subject"
   >                ["*make*money*fast*", "*university*dipl*mas*"])
   >         {
   >         remove "MyFlags" "\\Flagged";
   >         # If message header does not contain my address,
   >         # it's from a list.
   >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
   >         }
   > else
   >         {
   >         # Move all other (non-company) mail to "personal"
   >         # folder.

My eyes may be glazing over, but have we really established
"non-company" mail at this point?  One of the ways we get here
is if "to" or "cc" contain "[e-mail]"

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 j19H0x3A046126; Wed, 9 Feb 2005 09:00:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19H0xxU046125; Wed, 9 Feb 2005 09:00:59 -0800 (PST)
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 j19H0wse046118 for <[e-mail]>; Wed, 9 Feb 2005 09:00:58 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 95032 invoked by uid 101); 9 Feb 2005 12:00:56 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 9 Feb 2005 12:00:56 -0500
To: [e-mail]
Cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
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 Tue, Feb 08, 2005 at 04:28:06PM -0800, [e-mail] wrote:
> Without setflag I would expect to see stuff of the form
> 
>     set "foo" "";
>     addflag "foo" "bar";

Is the first line strictly necessary?  i.e. can you manipulate variables
via addflag et al if those variables haven't been instantiated?
I would think that you could.

 
> Whether or not this savings warrants an entire action is a judgement call.
> Having implemented it I can say that for me at least supporting setflag only
> amounted to about 15 additional lines of code and one additional table entry.

I think having extra stuff in the language is more the point than how
hard it is to add that extra stuff.  I would also prefer not to have
verbs that aren't really needed.

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 j19E3VQc033034; Wed, 9 Feb 2005 06:03:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19E3V0F033033; Wed, 9 Feb 2005 06:03:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19E3UlO033027 for <[e-mail]>; Wed, 9 Feb 2005 06:03:30 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.126] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 9 Feb 2005 14:03:25 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 14:03:23 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
References: <[e-mail]>	 <[e-mail]>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Kjetil Torgrim Homme wrote:

>On Wed, 2005-02-09 at 11:35 +0000, Alexey Melnikov wrote:
>  
>
>>Kjetil Torgrim Homme wrote:
>>    
>>
>>>the default comparator is always "i;ascii-casemap", so it can be omitted
>>>      
>>>
>>>from the examples.
>>
>>"i;ascii-casemap" is not used in examples, it is used in the
>>Implementation Notes section, where it is required.
>>    
>>
>I don't think so.
>
>RFC 3028, 2.7.3.   Comparators
>   [...]
>   All implementations MUST support the "i;octet" comparator (simply
>   compares octets) and the "i;ascii-casemap" comparator (which treats
>   uppercase and lowercase characters in the ASCII subset of UTF-8 as
>   the same).  If left unspecified, the default is "i;ascii-casemap".
>  
>
Fine :-). I certainly didn't remember this, so I don't think it hurts to 
be explicit.

Alexey



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 j19DsMPx032566; Wed, 9 Feb 2005 05:54:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19DsMs8032565; Wed, 9 Feb 2005 05:54:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19DsLWt032541 for <[e-mail]>; Wed, 9 Feb 2005 05:54:21 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 161523A1D; Wed,  9 Feb 2005 14:54:09 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j19Do3QU006476; Wed, 9 Feb 2005 14:50:03 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j19Do1fJ006474; Wed, 9 Feb 2005 14:50:01 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 09 Feb 2005 14:50:00 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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, 2005-02-09 at 11:35 +0000, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >the default comparator is always "i;ascii-casemap", so it can be omitted
> >from the examples.
>
> "i;ascii-casemap" is not used in examples, it is used in the
> Implementation Notes section, where it is required.

I don't think so.

RFC 3028, 2.7.3.   Comparators
   [...]
   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase characters in the ASCII subset of UTF-8 as
   the same).  If left unspecified, the default is "i;ascii-casemap".

-- 
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 j19BaQbt097783; Wed, 9 Feb 2005 03:36:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19BaQPK097782; Wed, 9 Feb 2005 03:36:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19BaJNJ097647 for <[e-mail]>; Wed, 9 Feb 2005 03:36:23 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.126] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 9 Feb 2005 11:35:47 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 11:35:43 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Kjetil Torgrim Homme wrote:

>a few comments:
>
>the default comparator is always "i;ascii-casemap", so it can be omitted
>from the examples.
>  
>
"i;ascii-casemap" is not used in examples, it is used in the Implementation Notes section, where it is required.




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 j190WPcM049744; Tue, 8 Feb 2005 16:32:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j190WP1J049743; Tue, 8 Feb 2005 16:32:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j190WO0O049721 for <[e-mail]>; Tue, 8 Feb 2005 16:32:25 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Feb 2005 16:31:52 -0800 (PST)
Cc: [e-mail]
Date: Tue, 08 Feb 2005 16:28:06 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Wed, 09 Feb 2005 00:29:33 +0100" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
To: Kjetil Torgrim Homme <[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>

> a few comments:

> the default comparator is always "i;ascii-casemap", so it can be omitted
> from the examples.

> the actions and tests allows a list of flags to be specified as a space
> delimited string.  I assume this is intended to allow variable
> references.  e.g.:

>   set "s" "\\Answered Closed";
>   setflag "f" ["${s}", "\\Deleted"];
>   if hasflag "${f}" "${s}" ...

> do we really need "setflag"?  it is equivalent with "set", except it
> allows some syntax checking of the arguments,

And possibily duplicate elimination and reordering.

> but as you can see above,
> it can't really do much of it statically anyhow.

Yes, but runtime checking is possible.

> I think most users
> will use "addflag" almost exclusively.

Without setflag I would expect to see stuff of the form

    set "foo" "";
    addflag "foo" "bar";

Whether or not this savings warrants an entire action is a judgement call.
Having implemented it I can say that for me at least supporting setflag only
amounted to about 15 additional lines of code and one additional table entry.

				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 j18NXpHj046956; Tue, 8 Feb 2005 15:33:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18NXpE8046955; Tue, 8 Feb 2005 15:33:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18NXoN8046934 for <[e-mail]>; Tue, 8 Feb 2005 15:33:50 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 9F15E389A for <[e-mail]>; Wed,  9 Feb 2005 00:33:37 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j18NTZN9002537 for <[e-mail]>; Wed, 9 Feb 2005 00:29:35 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j18NTYcv002535 for [e-mail]; Wed, 9 Feb 2005 00:29:34 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 09 Feb 2005 00:29:33 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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>

a few comments:

the default comparator is always "i;ascii-casemap", so it can be omitted
from the examples.

the actions and tests allows a list of flags to be specified as a space
delimited string.  I assume this is intended to allow variable
references.  e.g.:

  set "s" "\\Answered Closed";
  setflag "f" ["${s}", "\\Deleted"];
  if hasflag "${f}" "${s}" ...

do we really need "setflag"?  it is equivalent with "set", except it
allows some syntax checking of the arguments, but as you can see above,
it can't really do much of it statically anyhow.  I think most users
will use "addflag" almost exclusively.

-- 
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 j18KeglR036640; Tue, 8 Feb 2005 12:40:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Keg4Z036639; Tue, 8 Feb 2005 12:40:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18KegMC036632 for <[e-mail]>; Tue, 8 Feb 2005 12:40:42 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15454; Tue, 8 Feb 2005 15:40:40 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-rfc3598bis-00.txt
Date: Tue, 08 Feb 2005 15:40:40 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering -- Subaddress Extension
	Author(s)	: K. Murchison
	Filename	: draft-ietf-sieve-rfc3598bis-00.txt
	Pages		: 12
	Date		: 2005-2-8
	
On email systems that allow for "subaddressing" or "detailed
   addressing" (e.g., "[e-mail]") it is sometimes
   desirable to make comparisons against these sub-parts of addresses.
   This document defines an extension to the Sieve mail filtering
   language that allows users to compare against the user and detail
   parts of an address.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-rfc3598bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-rfc3598bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-rfc3598bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-rfc3598bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




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 j18KeS9U036618; Tue, 8 Feb 2005 12:40:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18KeSUp036617; Tue, 8 Feb 2005 12:40:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18KeR6Y036611 for <[e-mail]>; Tue, 8 Feb 2005 12:40:28 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15382; Tue, 8 Feb 2005 15:40:25 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Date: Tue, 08 Feb 2005 15:40:25 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-00.txt
	Pages		: 0
	Date		: 2005-2-8
	
Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-imapflags-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-imapflags-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-imapflags-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-imapflags-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




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 j18KQkfm035348; Tue, 8 Feb 2005 12:26:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18KQkZQ035347; Tue, 8 Feb 2005 12:26:46 -0800 (PST)
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 j18KQbqh035338 for <[e-mail]>; Tue, 8 Feb 2005 12:26:42 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 47223 invoked by uid 101); 8 Feb 2005 15:26:30 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 8 Feb 2005 15:26:30 -0500
To: Nigel Swinson <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <00b501c50d20$15926f40$6501a8c0@nigelhome>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00b501c50d20$15926f40$6501a8c0@nigelhome>
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 Mon, Feb 07, 2005 at 02:19:47PM -0000, Nigel Swinson wrote:
> > BTW I think this is the kind of extension that could be solved with
> > better fundamental language elements and/or better coordination between
> > language extensions.
> > 
> > For example, one could build on the proposed "variables" extension by
> > imagining a new set of read-only variables within specific namespaces
> > (per the old namespace idea, a la dates and timezones).  Imagine:
> > 
> >    require "variables";
> >    require [ "relational", "comparator-i;ascii-numeric" ];
> > 
> >    set "spamval" "${spamtest::value}"
> >    set "spampct" "${spamtest::pctvalue}"
> >    set "spamtext" "${spamtest::text}"
> > 
> >    if string :value "ge"
> >              :comparator "i;ascii-numeric"
> >      "${spamval}" "3" { ... }
> >    if string :value "ge"
> >              :comparator "i;ascii-numeric"
> >              "${spamtest::pctvalue}" "30" { ... }
> > 
> > Time travel might be required though.
> 
> Or better still why not just refer to the variables direct in the string test?
> 
>     if string :value "ge"
>               :comparator "i;ascii-numeric"
>               "${spamtest.value}" "3" { ... }

My second example quoted above had that (but with improper namespace
syntax-- somehow I thought that namespaces had been removed and
completely glossed over them in the latest variables draft).


> One problem here is that it costs resources to obtain the spam score
> and virus score, and part of the reason you might be using sieve would
> be to refine which messages would result in those resources being used
> up.  So you might still want to somehow specify or recommend that the
> implementation make the variables in the namespace available in a lazy
> fashion.

Indeed, that's what I had in mind as well in that particular example.

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 j18Hg6ES024139; Tue, 8 Feb 2005 09:42:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Hg6Uh024138; Tue, 8 Feb 2005 09:42:06 -0800 (PST)
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 j18Hg4lE024132 for <[e-mail]>; Tue, 8 Feb 2005 09:42:05 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed; charset=iso-8859-1; reply-type=original
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Feb 2005 09:42:01 -0800 (PST)
Cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Date: Tue, 08 Feb 2005 09:35:18 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Tue, 08 Feb 2005 17:11:53 +0000" <004101c50e01$89e6d610$[e-mail]>
Message-id: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome> <[e-mail]> <007c01c50d43$7ae2c8e0$[e-mail]> <[e-mail]> <002f01c50dcd$be717310$6501a8c0@nigelhome> <[e-mail]> <[e-mail]> <004101c50e01$89e6d610$[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[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>

> > > I don't think it is meaningful to add a general function.  consider
> > > SETDATE, which had an optional parameter for the timezone.

> > I agree. The need for extension-specific parameters makes a general
> > function infeasible.

> <snip>

> > I agree here as well. The cost of doing what's necessary to bind a fair
> > number of different variables to a set of values is the only thing that
> > makes this whole idea somewhat attractive. But the code of binding
> > one or two variables, which is what you'd have in the case of spamtest
> > or virustest, is so short that I just don't see the need for a separate
> > variable binding action.

> Great, well as you can guess I'd much rather these variables were just made
> available, and we didn't need a setvariables, so where are we now?

My position is that none of this is really needed, but if we have to have it
needs to take the form of a separate extension or set of extensions to define 
the needed actions to set the variables. Additionally, the only case I've seen
where I view the marginal utility as being being sufficient to bother is the
that of setheadervariables (or whatever you want to call it).

> Are we
> saying that spamtest should be revised to specify that it defines certain
> variables in a spamtest namespace, and we have a new extension that if
> requested makes a list of message attributes available as variables, and we
> don't need any special action to ask that they be initialised?

Absolutely not. IMO none of this has any business being added to spamtest.
Let's please remember that spamtest is defined in a standards-track RFC, and
any enhancements to it have to be done as a separate extension. It could
be incorporated into a revised RFC as a separate extension, but again,
I don't think the benefits in the case of spamtest are really there.

> Instead
> sensible implementations will only evaluate costly variables in a lazy
> fashion so as to avoid resource overhead?

> So my SMS string has become:
>  set "Message" "[To: {$header.to} From: ${header.from}] ${header.subject}"
> And my "magic string" has become:
>  addheader "X-Spam-Score" "${spamscore.score}";

I don't see any variable setting actions here, so this is IMO incomplete.

				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 j18HDsNw022510; Tue, 8 Feb 2005 09:13:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18HDsLs022509; Tue, 8 Feb 2005 09:13:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18HDsSR022498 for <[e-mail]>; Tue, 8 Feb 2005 09:13:54 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (scotty.rockliffe.com [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Tue, 8 Feb 2005 09:13:42 -0800
Message-ID: <004101c50e01$89e6d610$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>, "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome> <[e-mail]> <007c01c50d43$7ae2c8e0$[e-mail]> <[e-mail]> <002f01c50dcd$be717310$6501a8c0@nigelhome> <[e-mail]> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Tue, 8 Feb 2005 17:11:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

>> I don't think it is meaningful to add a general function.  consider
>> SETDATE, which had an optional parameter for the timezone.
>
> I agree. The need for extension-specific parameters makes a general 
> function
> infeasible.
<snip>
> I agree here as well. The cost of doing what's necessary to bind a fair
> number of different variables to a set of values is the only thing that
> makes this whole idea somewhat attractive. But the code of binding
> one or two variables, which is what you'd have in the case of spamtest
> or virustest, is so short that I just don't see the need for a separate
> variable binding action.

Great, well as you can guess I'd much rather these variables were just made 
available, and we didn't need a setvariables, so where are we now?  Are we 
saying that spamtest should be revised to specify that it defines certain 
variables in a spamtest namespace, and we have a new extension that if 
requested makes a list of message attributes available as variables, and we 
don't need any special action to ask that they be initialised?  Instead 
sensible implementations will only evaluate costly variables in a lazy 
fashion so as to avoid resource overhead?

So my SMS string has become:
 set "Message" "[To: {$header.to} From: ${header.from}] ${header.subject}"
And my "magic string" has become:
 addheader "X-Spam-Score" "${spamscore.score}";


?

Nigel 



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 j18GoUgX020877; Tue, 8 Feb 2005 08:50:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18GoUvO020876; Tue, 8 Feb 2005 08:50:30 -0800 (PST)
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 j18GoTO7020870 for <[e-mail]>; Tue, 8 Feb 2005 08:50:29 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Feb 2005 08:50:24 -0800 (PST)
Cc: Nigel Swinson <[e-mail]>, [e-mail], [e-mail]
Date: Tue, 08 Feb 2005 08:45:58 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Tue, 08 Feb 2005 16:18:13 +0100" <[e-mail]>
Message-id: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome> <[e-mail]> <007c01c50d43$7ae2c8e0$[e-mail]> <[e-mail]> <002f01c50dcd$be717310$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
To: Kjetil Torgrim Homme <[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 Tue, 2005-02-08 at 11:02 +0000, Nigel Swinson wrote:
> > Ok, so what if we have an action which requests certain variables
> > associated with an extension to be made available in it's namespace.
> >
> >    setvariables <extension-name: string> [<list-of-variables: string-list>]
> >
> > If you don't supply a list of variables that you want access to, it
> > will activate all variables the extension defines, else it will only
> > activate the list of variables that you were interested in.  This
> > might help with the issue of only wanting to use processing resources
> > (av/as?) for some messages.

> the analysis of the script to find the variables actually used is so
> trivial I don't think it is worthwhile to burden the script writer with
> replicating it.

> I don't think it is meaningful to add a general function.  consider
> SETDATE, which had an optional parameter for the timezone.

I agree. The need for extension-specific parameters makes a general function
infeasible.

> for many extensions, I don't think an explicit action is needed, and in
> my view that includes the spamscore extension.  there is one advantage
> to doing it, though.  if you require only "spamscore", and not
> "variables", strings like "${spamscore.value}" will still be legal, they
> will just not be interpreted.  a separate extension name which makes a
> setter function available may make such errors less likely.

I agree here as well. The cost of doing what's necessary to bind a fair
number of different variables to a set of values is the only thing that
makes this whole idea somewhat attractive. But the code of binding
one or two variables, which is what you'd have in the case of spamtest
or virustest, is so short that I just don't see the need for a separate
variable binding action.

				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 j18FMUVX013539; Tue, 8 Feb 2005 07:22:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18FMUKs013538; Tue, 8 Feb 2005 07:22:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18FMTlD013509 for <[e-mail]>; Tue, 8 Feb 2005 07:22:29 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id E5523390A; Tue,  8 Feb 2005 16:22:16 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j18FIHsA002003; Tue, 8 Feb 2005 16:18:17 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j18FIGTP002001; Tue, 8 Feb 2005 16:18:16 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: Sieve-Notify and potential associative arrays.
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <002f01c50dcd$be717310$6501a8c0@nigelhome>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome> <[e-mail]> <007c01c50d43$7ae2c8e0$[e-mail]> <[e-mail]> <002f01c50dcd$be717310$6501a8c0@nigelhome>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 08 Feb 2005 16:18:13 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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, 2005-02-08 at 11:02 +0000, Nigel Swinson wrote:
> Ok, so what if we have an action which requests certain variables
> associated with an extension to be made available in it's namespace.
> 
>    setvariables <extension-name: string> [<list-of-variables: string-list>]
> 
> If you don't supply a list of variables that you want access to, it
> will activate all variables the extension defines, else it will only
> activate the list of variables that you were interested in.  This
> might help with the issue of only wanting to use processing resources
> (av/as?) for some messages.

the analysis of the script to find the variables actually used is so
trivial I don't think it is worthwhile to burden the script writer with
replicating it.

I don't think it is meaningful to add a general function.  consider
SETDATE, which had an optional parameter for the timezone.

for many extensions, I don't think an explicit action is needed, and in
my view that includes the spamscore extension.  there is one advantage
to doing it, though.  if you require only "spamscore", and not
"variables", strings like "${spamscore.value}" will still be legal, they
will just not be interpreted.  a separate extension name which makes a
setter function available may make such errors less likely.
-- 
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 j18B35ng046830; Tue, 8 Feb 2005 03:03:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18B35gs046823; Tue, 8 Feb 2005 03:03:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18B30Qm046676 for <[e-mail]>; Tue, 8 Feb 2005 03:03:02 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.209]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Tue, 8 Feb 2005 03:02:48 -0800
Message-ID: <002f01c50dcd$be717310$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome> <[e-mail]> <007c01c50d43$7ae2c8e0$[e-mail]> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Tue, 8 Feb 2005 11:02:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18B33Qm046791
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>

> > Slightly better, but still a bit ugly...  Perhaps instead define some new
> > action who's sole purpose is to populate the spamscore or header namespace.
> 
> That's a much better idea, actually. I could live with this approach.
> Something like:
> 
>    headervariables list-of-header-fields
> 
> We could even make the "header." prefix settable.

Ok, so what if we have an action which requests certain variables associated with an extension to be made available in it's namespace.

   setvariables <extension-name: string> [<list-of-variables: string-list>]

If you don't supply a list of variables that you want access to, it will activate all variables the extension defines, else it will only activate the list of variables that you were interested in.  This might help with the issue of only wanting to use processing resources (av/as?) for some messages.

If we were all happy with this approach, it would seem to me to be a good addition to the variables spec?

Nigel



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 j17NWlDJ082854; Mon, 7 Feb 2005 15:32:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NWlmv082853; Mon, 7 Feb 2005 15:32:47 -0800 (PST)
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 j17NWkw3082842 for <[e-mail]>; Mon, 7 Feb 2005 15:32:46 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed; charset=Windows-1252; reply-type=original
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 07 Feb 2005 15:32:38 -0800 (PST)
Cc: [e-mail], [e-mail]
Date: Mon, 07 Feb 2005 15:25:28 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Mon, 07 Feb 2005 18:33:05 +0000" <007c01c50d43$7ae2c8e0$[e-mail]>
Message-id: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome> <[e-mail]> <007c01c50d43$7ae2c8e0$[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[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>

> >> Actually I think what I'm proposing will make it easier for a gui, not
> >> harder.
> >
> > Perhaps in this specific case, but in general, no. The problem with  the
> > idea
> > of having "special" variables show up is that it won't be limited to
> > accessing
> > the header. You yourself used the notion of extending it to spamtest. This
> > sort of thing requires fairly deep knowledge of each extension in the GUI.

> I can see it's a nice goal to have a generic gui for building any old sieve
> script, but I don't think we can really get away from having to do some
> development work for each extension to make it available more neatly to the
> user.

For seamless integration, sure, but it would really be nice if basic
integration didn't require such in-depth knowledge.

> > I'd much rather have the binding from various information sources to
> > variables be explicit. It may not be possible to present this sort of
> > thing in a very pretty way, but at least it should be possible to
> > accmodate
> > extensions more easily.

> Could we instead say that the spamscore namespace is populated after the
> first instance of using the spamtest test?

This makes some things better, others worse. Better in the sense that
at least the variables aren't quite as magic. Worse in the sense that 
it creates a magic side effect.

> That would make my magic string:

> if spamtest :matches "*" {}
> addheader "X-Spam-Score" "${spamscore.score}";

> Slightly better, but still a bit ugly...  Perhaps instead define some new
> action who's sole purpose is to populate the spamscore or header namespace.

That's a much better idea, actually. I could live with this approach.
Something like:

   headervariables list-of-header-fields

We could even make the "header." prefix settable.

> Something like the getdate (?) action from a much earlier revision of the
> variables spec?

I believe it was setdate, but yes, I found the setdate thing to be fairly
reasonable.

> >> I've had to solve this in the past by having large "magic strings" like
> >> this:
> >
> >>  if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore"
> >> "${1}";}
> >>  addheader "X-Spam-Score" "${spamscore}";
> >
> > Which I think is fine.
> >
> >> Where the presence or absence of the entire two lines is controlled by a
> >> checkbox.  It would have been much easier if I had a ${spamscore.score}
> >> or a
> >> ${MESSAGE['SpamScore']} available to me.
> >
> > Yeech. This is exactly the sort of thing I think we need to avoid at all
> > costs.

> If you like my existing magic string, then you could rephrase my request to
> say that I'd like to change my magic string to just:

>   addheader "X-Spam-Score" "${spamscore.score}";

> What's Yeech about that?  It's less than half the syntax and the intent is
> much clearer.

The issue was more the array notation and the creep into multiple extensions.

				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 j17Kl33B063861; Mon, 7 Feb 2005 12:47:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Kl3XX063860; Mon, 7 Feb 2005 12:47:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Kl2vY063846 for <[e-mail]>; Mon, 7 Feb 2005 12:47:02 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12384; Mon, 7 Feb 2005 15:46:59 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-01.txt
Date: Mon, 07 Feb 2005 15:46:59 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: Variables Extension
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-01.txt
	Pages		: 14
	Date		: 2005-2-4
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-variables-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-variables-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-variables-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




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 j17Kkqta063815; Mon, 7 Feb 2005 12:46:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KkqsB063814; Mon, 7 Feb 2005 12:46:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KkpBU063807 for <[e-mail]>; Mon, 7 Feb 2005 12:46:51 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12364; Mon, 7 Feb 2005 15:46:48 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-editheader-00.txt
Date: Mon, 07 Feb 2005 15:46:48 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: Editheader Extension
	Author(s)	: J. Degener, P. Guenther
	Filename	: draft-ietf-sieve-editheader-00.txt
	Pages		: 0
	Date		: 2005-2-7
	
This document defines two new actions for the "sieve"
   language that add and delete email header fields.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-editheader-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-editheader-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-editheader-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




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 j17KkInH063774; Mon, 7 Feb 2005 12:46:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KkIxF063773; Mon, 7 Feb 2005 12:46:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KkHtR063767 for <[e-mail]>; Mon, 7 Feb 2005 12:46:17 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12271; Mon, 7 Feb 2005 15:46:14 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-body-00.txt
Date: Mon, 07 Feb 2005 15:46:14 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: Body Extension
	Author(s)	: J. Degener, P. Guenther
	Filename	: draft-ietf-sieve-body-00.txt
	Pages		: 0
	Date		: 2005-2-7
	
This document defines a new primitive for the "Sieve" email filtering
   language that tests for the occurrence of one or more strings in the
   body of an email message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-body-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-body-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-body-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-body-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




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 j17IXGO1046959; Mon, 7 Feb 2005 10:33:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IXGsm046958; Mon, 7 Feb 2005 10:33:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IXFmd046927 for <[e-mail]>; Mon, 7 Feb 2005 10:33:15 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (scotty.rockliffe.com [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Mon, 7 Feb 2005 10:33:12 -0800
Message-ID: <007c01c50d43$7ae2c8e0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 18:33:05 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

>> Actually I think what I'm proposing will make it easier for a gui, not
>> harder.
>
> Perhaps in this specific case, but in general, no. The problem with  the 
> idea
> of having "special" variables show up is that it won't be limited to 
> accessing
> the header. You yourself used the notion of extending it to spamtest. This
> sort of thing requires fairly deep knowledge of each extension in the GUI.

I can see it's a nice goal to have a generic gui for building any old sieve 
script, but I don't think we can really get away from having to do some 
development work for each extension to make it available more neatly to the 
user.

> I'd much rather have the binding from various information sources to
> variables be explicit. It may not be possible to present this sort of
> thing in a very pretty way, but at least it should be possible to 
> accmodate
> extensions more easily.

Could we instead say that the spamscore namespace is populated after the 
first instance of using the spamtest test?  That would make my magic string:

if spamtest :matches "*" {}
addheader "X-Spam-Score" "${spamscore.score}";

Slightly better, but still a bit ugly...  Perhaps instead define some new 
action who's sole purpose is to populate the spamscore or header namespace. 
Something like the getdate (?) action from a much earlier revision of the 
variables spec?

>> I've had to solve this in the past by having large "magic strings" like 
>> this:
>
>>  if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore" 
>> "${1}";}
>>  addheader "X-Spam-Score" "${spamscore}";
>
> Which I think is fine.
>
>> Where the presence or absence of the entire two lines is controlled by a
>> checkbox.  It would have been much easier if I had a ${spamscore.score} 
>> or a
>> ${MESSAGE['SpamScore']} available to me.
>
> Yeech. This is exactly the sort of thing I think we need to avoid at all
> costs.

If you like my existing magic string, then you could rephrase my request to 
say that I'd like to change my magic string to just:

  addheader "X-Spam-Score" "${spamscore.score}";

What's Yeech about that?  It's less than half the syntax and the intent is 
much clearer.

Nigel 



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 j17IXGu4046964; Mon, 7 Feb 2005 10:33:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IXGb6046963; Mon, 7 Feb 2005 10:33:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IXFme046927 for <[e-mail]>; Mon, 7 Feb 2005 10:33:15 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (scotty.rockliffe.com [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Mon, 7 Feb 2005 10:33:04 -0800
Message-ID: <007901c50d43$75ddd790$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <00b901c50d20$1ab60c20$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 18:33:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

> I think we agreed previously that 3028bis should be more explicit about
> the meaning of wildcards in the argument to :matches. I think it is
> non-controversial, though, nobody would expect "abc" to match "b*".

That's a good example, thanks :o)

> I would prefer the list of supported header names was explicit, though,
> so that the extension could do the relevant decoding for the user.
> notice that I omitted the number suffix for header.date, since RFC 2822
> explicitly says there should be 1 and only 1 "Date" header.

But all headers are subject to RFC2047 and unwrapping aren't they?  If we 
explicitly list all headers available in the header scope, then that means 
when somebody decides to use a new X- header or something like that, then 
they would need to write their own Sieve extension to make it available in 
the/another namespace.  This sounds overburdensome to me.  While I recognise 
that the standard says that there are limits on certain headers like the 
Data header, I think I'd much rather have the header "namespace" or array or 
whatever generically hold all 2822 headers.

If there is some extra parsing or meaning to a particular header, then I 
could see we could define a new namespace to access the headers in the more 
specific way with access to the more specific parsing.  Perhaps:

headers.content-type = "TEXT/PLAIN; charset=Windows-1252"
mimeheaders.content-type.type = "TEXT"
mimeheaders.content-type.subtype = "PLAIN"
mimeheaders.content-type.charset = "Windows-1252"

> > I think it preferable to allow array syntax instead of variables
> > starting with numbers.
>
> I'm afraid I don't see that happening, the variables draft is too close
> publication for such a change to the syntax.

So you are saying you'd prefer us to publish variables, then later realise 
we needed this and have to have another standard or revision to allow us to 
use array notation?  I guess this is heading in the direction of Mark's 
comments, now it seems we are talking about "stringvariables" not really 
generic variables which will meet all the languages needs.

I suppose I was hoping to hear some technical reasons for why we wouldn't 
want [] and rather have a completely non standard way of providing access to 
what is really an array.

> > If we were to do this then where would such a mechanism be specified?
> > 3028bis, variables, new draft? I'd love it to be available in the
> > variables spec...
>
> the namespace feature of the variables draft was specifically added to
> allow independent extensions to add "magic" variables.

Perhaps if we groups several generic namespaces together which apply to all 
messages then we'd have enough for another spec.  Perhaps headers, envelope, 
message, server?  It seems to be an excellent addition to the variables 
extension if you ask me, but I recognize that this would all take a while to 
hammer out.  I just hope we don't go with a variables spec which limits our 
choices when we get there :o(

Nigel 



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 j17GjYIa034931; Mon, 7 Feb 2005 08:45:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17GjYpC034930; Mon, 7 Feb 2005 08:45:34 -0800 (PST)
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 j17GjVwl034911 for <[e-mail]>; Mon, 7 Feb 2005 08:45:32 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=Windows-1252
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 07 Feb 2005 08:45:24 -0800 (PST)
Cc: [e-mail], [e-mail]
Date: Mon, 07 Feb 2005 08:31:14 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Mon, 07 Feb 2005 14:19:48 +0000" <00b801c50d20$19615190$6501a8c0@nigelhome>
Message-id: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]> <00b801c50d20$19615190$6501a8c0@nigelhome>
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[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>

> > This begs the question of whether or not complex header transformations are
> > something we should be doing with sieve. I happen to think the answer to this
> > particular question is "no".

> I agree.

> > Copying a subject and perhaps a couple of other
> > fields into a new message is about as far as I think sieve needs to go.

> I agree.  So the question is restated as should the set of "other fields" be
> predefined and fixed, or generic and able to cope with all current and future
> needs?  The existing $subject" strategy seems to make a very limited and fixed
> set of message attributes available, and I'm concerned that this isn't going to
> meet our future needs and barely meets our current needs.

Oops, I missed the fact that you were talking about the specific (and overly
limited) approach taken in the long-expired notification draft. I have been
assuming that the existing $subject strategy would vanish now that we have
variables. I regard it as much clear to do a

   if header :matches "subject" "*" {set "subject" "${0}"}
   else {set "subject" ""}

sort of thing than to have a couple of magic variables, or associative arrays
of headers for that matter.

> > Of course there are all sorts of more complex things people will want to do.
> > But this is a seriously slippery slope, because lurking not far away are
> > things like content summaries, keyword extraction, translation services,
> > content shaping, and so on. This stuff has "research problem" written all
> > over it, and IMO sieve needs to stay away from this space.

> Content summaries sound quite useful :o)

Yes, well, it seemed useful when I first heard a presentation on this general
area by Minski back in 1977. However, at the time I wasn't at all impressed by
the approaches being taken, and here it is, almost 30 years later, and look at
all the progress we've made. Personally, I'm not holding my breath...

> I suppose were they to stabalize then I'd like them to be made available
> through other Sieve extensions which would make new variables available to the
> script author for testing or use in creating new messages.

Again, I'm not holding my breath...

> > > Do you/we favour the $subject$ approach?
> >
> > I think it is just sufficient to get the jobs appropriate for sieve done.

> If we are to keep it then I hope we at least change it to ${subject} or
> ${headers.subject}

I'd rather get rid of it entirely and use variables instead.

> > > I guess I would accept some implementation complexity
> > > if it means the language is easier to use....
> >
> > Ease of use is a two-edged sword. One of the things sieve is used for is
> > as an output format for GUI filter builder utilities. Variables are already
> > pretty hard to handle in such tools, things like associative arrays
> > are really over the top.

> Actually I think what I'm proposing will make it easier for a gui, not
> harder.

Perhaps in this specific case, but in general, no. The problem with  the idea
of having "special" variables show up is that it won't be limited to accessing
the header. You yourself used the notion of extending it to spamtest. This
sort of thing requires fairly deep knowledge of each extension in the GUI.
I'd much rather have the binding from various information sources to
variables be explicit. It may not be possible to present this sort of
thing in a very pretty way, but at least it should be possible to accmodate
extensions more easily.

> I've had to solve this in the past by having large "magic strings" like this:

>  if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore" "${1}";}
>  addheader "X-Spam-Score" "${spamscore}";

Which I think is fine.

> Where the presence or absence of the entire two lines is controlled by a
> checkbox.  It would have been much easier if I had a ${spamscore.score} or a
> ${MESSAGE['SpamScore']} available to me.

Yeech. This is exactly the sort of thing I think we need to avoid at all
costs.

				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 j17FALpX024657; Mon, 7 Feb 2005 07:10:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17FALwA024656; Mon, 7 Feb 2005 07:10:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17FAKjP024621 for <[e-mail]>; Mon, 7 Feb 2005 07:10:20 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 8A972367D; Mon,  7 Feb 2005 16:10:07 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j17F6F4E000676; Mon, 7 Feb 2005 16:06:15 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j17F6FIt000674; Mon, 7 Feb 2005 16:06:15 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: Sieve-Notify and potential associative arrays.
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <00b901c50d20$1ab60c20$6501a8c0@nigelhome>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <00b901c50d20$1ab60c20$6501a8c0@nigelhome>
Content-Type: text/plain; charset=windows-1251
Date: Mon, 07 Feb 2005 16:06:13 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j17FALjP024651
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 Mon, 2005-02-07 at 14:19 +0000, Nigel Swinson wrote:
> > > Each phone number must begin with a + and
> > > include the country code to ensure that the script will work
> > > regardless of location of server/script.
> > 
> > is it important to trap this at compile-time?
> 
> I think it's similair to the desire to catch invalid variable names at
> compile time.  So yes, I think so.

I agree it is desirable, and if we have mechanism specific keywords,
arguments should be syntax checked as much as possible.

> > > if header :matches "*" "To" {
> >
> > (you'll have to switch the arguments, it's header COMPARATOR header-name
> > pattern)

sorry, this should say "header MATCH-TYPE header-name pattern"

> Ug I never did find the order intuative...

it is intuitive if you use the default match-type ":is".  the
non-intuitive bit is the placement of the match-type, but it is a basis
for the syntax that all tagged arguments appear before positional
arguments.

> > greediness doesn't come into play here, as :matches "*" == :regex
> > "^(.*)$"
> 
> I'm happy that that is the case but is that obvious to everyone?  It
> wasn't obvious to me, and I don't recall reading that it was ever
> specified.  I think we have another thread on this topic though...

I think we agreed previously that 3028bis should be more explicit about
the meaning of wildcards in the argument to :matches.  I think it is
non-controversial, though, nobody would expect "abc" to match "b*".

> > > $HEADERS[‘Received’][0] = "from p01m168.mxlogic.net [bla bla] "
> > > $HEADERS[‘Received’][1] = "from unknown [208.184.76.39] [bla bla] "
> > > $HEADERS[‘Date’][0] = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
> > 
> > this is just a different syntax for:
> > 
> > ${header.received.n1} = "from p01m168.mxlogic.net [bla bla] "
> > ${header.received.n2} = from unknown [208.184.76.39] [bla bla] "
> > ${header.date} = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
> 
> Yes, I would have suggested that instead, but I suppose I wondered if
> such a mechanism would mean we'd have to predefine all header names
> we'd ever use.  I thought perhaps the use of the associative array
> made it clearer that the header might not actually exist in the email,
> and therefore cope with all future header names.

that's really for the extension to decide.  the variables draft doesn't
rule out having variables spring to life when referenced -- it only
specifies the syntax of the names.   how the variables inside a
namespace work is left for the extension to define.

I would prefer the list of supported header names was explicit, though,
so that the extension could do the relevant decoding for the user.
notice that I omitted the number suffix for header.date, since RFC 2822
explicitly says there should be 1 and only 1 "Date" header.

> > (the variables draft doesn't allow the last component of the variable
> > name to be a number.  I think that is an aspect we can change if we want
> > to, but it must be done now.)
> 
> I think it preferable to allow array syntax instead of variables
> starting with numbers.

I'm afraid I don't see that happening, the variables draft is too close
publication for such a change to the syntax.

> > anyhow, doing it via a namespace makes it more natural to present the
> > information in a parsed manner. e.g., you could have an
> > header.date.year == "2005" in addition.
> 
> Indeed, that might work neatly!
> 
> If we were to do this then where would such a mechanism be specified?
> 3028bis, variables, new draft?  I'd love it to be available in the
> variables spec...

the namespace feature of the variables draft was specifically added to
allow independent extensions to add "magic" variables.
-- 
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 j17EK3tj019152; Mon, 7 Feb 2005 06:20:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17EK3pV019151; Mon, 7 Feb 2005 06:20:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17EK2en019083 for <[e-mail]>; Mon, 7 Feb 2005 06:20:03 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.208]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Mon, 7 Feb 2005 06:19:51 -0800
Message-ID: <00b901c50d20$1ab60c20$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 14:19:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1251"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j17EK3el019136
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>

> as a general point, I think it's not worthwhile to standardise
> specifically on SMS. it's not _that_ universal, and it's also being
> phased out by MMS, which is just good old MIME documents (transported by
> HTTP for the last hops, but SMTP for routing).

I don't yet know enough about MMS sadly to make comment :o(

> a limit on message length is a good option to add, but it shouldn't be
> based on SMS chunk size.

Why are they setting a limit though?  Partly due to how much text they want to scroll through, but more todo with how much it's going to cost them.  Isn't it the standardised SMS chunk size the root of the cost for SMS just now? If we make the limit based on message length, then we require that our users have some knowledge of how long a message they can have for one SMS chunk and therefore keep their costs down.

> > Each phone number must begin with a + and
> > include the country code to ensure that the script will work
> > regardless of location of server/script.
> 
> is it important to trap this at compile-time?

I think it's similair to the desire to catch invalid variable names at compile time.  So yes, I think so.

> > if header :matches "*" "To" {
> > set "Recipient" "${1}"
> > }
> > if header :matches "*" "From" {
> > set "Sender" "${1}"
> > }
> > if header :matches "*" "Subject" {
> > set "Subject" "${1}"
> > }
> > set "Message" "[To: {$Recipient} From: {$Sender}] {$Subject}"
> 
> (you'll have to switch the arguments, it's header COMPARATOR header-name
> pattern)

Ug I never did find the order intuative...

> > (I note that my intuative use of * won't work cos * in matches
> > according to variables is non-greedy, yet * with regex is greedy, but
> > I thought I'd do that deliberately to make you think...)
> 
> greediness doesn't come into play here, as :matches "*" == :regex
> "^(.*)$"

I'm happy that that is the case but is that obvious to everyone?  It wasn't obvious to me, and I don't recall reading that it was ever specified.  I think we have another thread on this topic though...
 
> > $HEADERS[‘Received’][0] = "from p01m168.mxlogic.net [bla bla] "
> > $HEADERS[‘Received’][1] = "from unknown [208.184.76.39] [bla bla] "
> > $HEADERS[‘Date’][0] = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
> 
> this is just a different syntax for:
> 
> ${header.received.n1} = "from p01m168.mxlogic.net [bla bla] "
> ${header.received.n2} = from unknown [208.184.76.39] [bla bla] "
> ${header.date} = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"

Yes, I would have suggested that instead, but I suppose I wondered if such a mechanism would mean we'd have to predefine all header names we'd ever use.  I thought perhaps the use of the associative array made it clearer that the header might not actually exist in the email, and therefore cope with all future header names.

> (the variables draft doesn't allow the last component of the variable
> name to be a number.  I think that is an aspect we can change if we want
> to, but it must be done now.)

I think it preferable to allow array syntax instead of variables starting with numbers.

> anyhow, doing it via a namespace makes it more natural to present the
> information in a parsed manner. e.g., you could have an
> header.date.year == "2005" in addition.

Indeed, that might work neatly!

If we were to do this then where would such a mechanism be specified?  3028bis, variables, new draft?  I'd love it to be available in the variables spec...

Nigel



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 j17EK3tS019144; Mon, 7 Feb 2005 06:20:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17EK3U8019139; Mon, 7 Feb 2005 06:20:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17EK2em019083 for <[e-mail]>; Mon, 7 Feb 2005 06:20:02 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.208]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Mon, 7 Feb 2005 06:19:49 -0800
Message-ID: <00b801c50d20$19615190$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 14:19:48 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j17EK3el019131
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>

> This begs the question of whether or not complex header transformations are
> something we should be doing with sieve. I happen to think the answer to this
> particular question is "no". 

I agree.

> Copying a subject and perhaps a couple of other
> fields into a new message is about as far as I think sieve needs to go.

I agree.  So the question is restated as should the set of "other fields" be predefined and fixed, or generic and able to cope with all current and future needs?  The existing $subject" strategy seems to make a very limited and fixed set of message attributes available, and I'm concerned that this isn't going to meet our future needs and barely meets our current needs.

> Of course there are all sorts of more complex things people will want to do.
> But this is a seriously slippery slope, because lurking not far away are
> things like content summaries, keyword extraction, translation services,
> content shaping, and so on. This stuff has "research problem" written all
> over it, and IMO sieve needs to stay away from this space.

Content summaries sound quite useful :o)  I suppose were they to stabalize then I'd like them to be made available through other Sieve extensions which would make new variables available to the script author for testing or use in creating new messages.

> > Do you/we favour the $subject$ approach?
> 
> I think it is just sufficient to get the jobs appropriate for sieve done.

If we are to keep it then I hope we at least change it to ${subject} or ${headers.subject}

> > I guess I would accept some implementation complexity
> > if it means the language is easier to use....
> 
> Ease of use is a two-edged sword. One of the things sieve is used for is
> as an output format for GUI filter builder utilities. Variables are already
> pretty hard to handle in such tools, things like associative arrays
> are really over the top.

Actually I think what I'm proposing will make it easier for a gui, not harder.  I'm imagining a gui with checkboxes along these lines:

Send an SMS to your phone including the following attributes:
- Sender
- Subject
- Message Body
- Spam Score
- Priority

Then depending on which checkboxes were ticked would change what message string we authored, where the checkbox would either add or remove a $HEADERS['Subject'] from the message string.  Without this kind of mechanism, we have to not only add the string to the message, but also use a header test before hand to make sure we have that variable available to us to use in this message.  

I've had to solve this in the past by having large "magic strings" like this:

 if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore" "${1}";}
 addheader "X-Spam-Score" "${spamscore}";

Where the presence or absence of the entire two lines is controlled by a checkbox.  It would have been much easier if I had a ${spamscore.score} or a ${MESSAGE['SpamScore']} available to me.

I would doubt that any gui builder out there can handle every corner case of every part of Sieve, but rather makes the most useful subset available to the user and surrenders to a text editor if the nesting/syntax goes beyond the scope of what can be easily communicated through form controls.

Nigel



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 j17EK2A4019129; Mon, 7 Feb 2005 06:20:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17EK2xT019128; Mon, 7 Feb 2005 06:20:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17EK2el019083 for <[e-mail]>; Mon, 7 Feb 2005 06:20:02 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.208]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Mon, 7 Feb 2005 06:19:42 -0800
Message-ID: <00b501c50d20$15926f40$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: "IETF MTA Filters List" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: spamtestbis
Date: Mon, 7 Feb 2005 14:19:47 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j17EK2el019123
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>

> BTW I think this is the kind of extension that could be solved with
> better fundamental language elements and/or better coordination between
> language extensions.
> 
> For example, one could build on the proposed "variables" extension by
> imagining a new set of read-only variables within specific namespaces
> (per the old namespace idea, a la dates and timezones).  Imagine:
> 
>    require "variables";
>    require [ "relational", "comparator-i;ascii-numeric" ];
> 
>    set "spamval" "${spamtest::value}"
>    set "spampct" "${spamtest::pctvalue}"
>    set "spamtext" "${spamtest::text}"
> 
>    if string :value "ge"
>              :comparator "i;ascii-numeric"
>      "${spamval}" "3" { ... }
>    if string :value "ge"
>              :comparator "i;ascii-numeric"
>              "${spamtest::pctvalue}" "30" { ... }
> 
> Time travel might be required though.

Or better still why not just refer to the variables direct in the string test?

    if string :value "ge"
              :comparator "i;ascii-numeric"
              "${spamtest.value}" "3" { ... }
    if string :value "ge"
              :comparator "i;ascii-numeric"
              "${spamtest.pctvalue}" "30" { ... }

This is certainly on a similar tack to my post relating to associative arrays and sms notification, so unsurprisingly I would really like to see something along these lines, but I'm not sure how we get there.  Indeed  I think it's this kind of thing that gives the variables extension a large amount of it's value.  The variables spec does make reference to:

   Namespaces are meant for future extensions which make internal state
   available through variables.  These variables SHOULD be put in a
   namespace with the same name as its capability string.  Notice that
   the user can not specify a namespace when setting variables with SET.

I wondered if we would therefore say things like if you require "spamtest", then a namespace called spamtest would be defined containing variables called value and text which contain etc.  It then seems to make sense to specify in the spamtest spec what variables it would define.  Do we have time to add such a section to spamtestbis?

One problem here is that it costs resources to obtain the spam score and virus score, and part of the reason you might be using sieve would be to refine which messages would result in those resources being used up.  So you might still want to somehow specify or recommend that the implementation make the variables in the namespace available in a lazy fashion.

Nigel



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 j170EoeP006105; Sun, 6 Feb 2005 16:14:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j170Eo69006104; Sun, 6 Feb 2005 16:14:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j170EmKD006064 for <[e-mail]>; Sun, 6 Feb 2005 16:14:49 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 715FE39A3; Mon,  7 Feb 2005 01:14:43 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j170Att9032190; Mon, 7 Feb 2005 01:10:55 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j170AsXV032188; Mon, 7 Feb 2005 01:10:54 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: Sieve-Notify and potential associative arrays.
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <015501c508cd$f508ce00$6501a8c0@nigelhome>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome>
Content-Type: text/plain; charset=windows-1251
Date: Mon, 07 Feb 2005 01:10:53 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j170EnKD006099
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, 2005-02-02 at 02:21 +0000, Nigel Swinson wrote:
> It seems to me that the notify extension is trying to do too much in
> supporting notification by email, SMS or indeed any arbitrary
> notification mechanism.  It was pointed out quickly how many complex
> internationalization issues you have to deal with when composing
> emails, but you have completely different concerns when dealing with
> SMS messages, so I'm not sure it makes sense to bundle them.  I think
> we should therefore have something more along these lines:
> 
> Syntax:   sms [":recipient" <recipient-numbers: string-list>] [:limit <number>] <message: string>

as a general point, I think it's not worthwhile to standardise
specifically on SMS.  it's not _that_ universal, and it's also being
phased out by MMS, which is just good old MIME documents (transported by
HTTP for the last hops, but SMTP for routing).

a limit on message length is a good option to add, but it shouldn't be
based on SMS chunk size.

> The :recipient tag specifies the target phone numbers to send this SMS
> to.  If not present, the implementation should try to send the SMS to
> the owner of the script where the number is held by the sieve
> implementation, ie a mailbox property.  If present, specifies the
> target number, and it can also be a list of numbers if more than one
> recipient is desired.  Each phone number must begin with a + and
> include the country code to ensure that the script will work
> regardless of location of server/script.

is it important to trap this at compile-time?

> The proposal in draft-ietf-sieve-notify-02.txt is this:
>  
>     Syntax:   notify [":method" string]
>                [":id" string]
>                [":options" 1*(string-list / number)]
>                [<":low" / ":normal" / ":high">]
>                ["message:" string]
> 
> I'm thinking it's got too many things in it which are trying to be
> super-generic to cover all uses (:method/:id/:options), but in actual
> fact we'll quickly regret this and prefer specific extensions for
> notifying through different channels with well defined and well
> documented arguments.

you may be right.  separate extension names for each notify method may
be the way to go.  how many methods are we talking about?  we've been
loosely discussing a Jabber notification method where I work.  (SMS/MMS
costs money :)

> Which brings me on to variables.  Each of these different notification
> types, and also the vacation extension to a certain degree, has the
> need to author messages, and likely include sections of the triggering
> message.  So suppose I want to author what I think is a fairly
> reasonable SMS which looks like this:
>            [To:<recipient-addresss>From:<sender-address>] <Subject>\r\n<body>
> 
> One way to get his is using the proposed $name$ variables which seem
> pretty ugly next to what we've worked so hard on with the variables
> extension, and also is pretty inflexible.  If we use the variables
> extension as is, then we could do this:
> 
> if header :matches “*” “To” {
>   set “Recipient” “${1}”
> }
> if header :matches “*” “From” {
>   set “Sender” “${1}”
> }
> if header :matches “*” “Subject” {
>   set “Subject” “${1}”
> }
> set “Message” “[To: {$Recipient} From: {$Sender}] {$Subject}”

(you'll have to switch the arguments, it's header COMPARATOR header-name
pattern)

> (I note that my intuative use of * won't work cos * in matches
> according to variables is non-greedy, yet * with regex is greedy, but
> I thought I'd do that deliberately to make you think...)

greediness doesn't come into play here, as :matches "*" == :regex
"^(.*)$"

> This seems like a lot of work to do something pretty "standard".

agreed.

> I wonder if it would make sense for us to add associative arrays
> containing entries of specific interest to the sieve script author.
> [...]
> Then I would end up with an array like this:
> 
> This would produce an array with these entries:
> $HEADERS[‘Received’][0] = “from p01m168.mxlogic.net [bla bla] ”
> $HEADERS[‘Received’][1] = “from unknown [208.184.76.39] [bla bla] ”
> $HEADERS[‘Date’][0] = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
> $HEADERS[‘To’][0] = “[e-mail]”
> $HEADERS[‘From’][0] = “[e-mail]”
> $HEADERS[‘Subject’][0] = “Welcome to ietf-mta-filters”

this is just a different syntax for:

  ${header.received.n1} = “from p01m168.mxlogic.net [bla bla] ”
  ${header.received.n2} = from unknown [208.184.76.39] [bla bla] ”
  ${header.date} = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”

(the variables draft doesn't allow the last component of the variable
name to be a number.  I think that is an aspect we can change if we want
to, but it must be done now.)

anyhow, doing it via a namespace makes it more natural to present the
information in a parsed manner.  e.g., you could have an
header.date.year == "2005" in addition.

(the variables draft allows header.date and header.date.year to
co-exist, as the namespace is defined as the bit before the last full
stop.)

-- 



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 j16NjVcw004113; Sun, 6 Feb 2005 15:45:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16NjVcr004112; Sun, 6 Feb 2005 15:45:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16NjU5m004067 for <[e-mail]>; Sun, 6 Feb 2005 15:45:30 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 51D2D3918; Mon,  7 Feb 2005 00:45:18 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j16NfUKw032172; Mon, 7 Feb 2005 00:41:30 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j16NfTXR032170; Mon, 7 Feb 2005 00:41:29 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
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]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 07 Feb 2005 00:41:26 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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, 2005-02-05 at 17:01 -0500, Mark E. Mallett wrote:
> I would like to include by reference, without going on about it further
> here, my earlier remarks about choices of keywords that might be likely
> to collide with future language enhancements.  Those issues are still
> important, if only to me.

please put forward suitable wording for use in the document?

> Also I have a few new niggling comments, as follows.
> 
> 3.
>    > "When a string is evaluated ..."
> 
> I'm not sure that the concept of evaluating a string has been
> introduced, so the "when a string is evaluated" is not strictly clear
> (even if everybody probably knows what it means).  So perhaps lay the
> groundwork of saying that this extension enables interpretation of
> strings at the moment they are used during runtime , and then say "when
> a string is interpreted..."   or just change the word to "interpreted" :-)

I agree, "interpreted" is better.

> 3.2.  Numbered variables
> 
>    > For ":matches"...
>    > The wildcards match as little as possible (non-greedy matching).
> 
> Even though I am in favor of this: this is a refinement of RFC3028
> (which is silent on the greediness issue).  Does this need to be
> explicitly stated?  I would think this should be an item for 3028bis or
> whatever the next SIEVE base draft is, as well.  (Being able to specify
> the :matches greediness would be a plus.)

I think it is essential that greediness behaviour is defined.  it cannot
be observed by the mechanisms in 3028 (or 3028bis) since it doesn't
change _what_ matches, only _how_ it matches, so it is natural that the
facility which makes observation possible also defines what should be
observed.

>    > The first string in the list has index 1.  If the index is out of
>    > range, the empty string will be substituted.  Index 0 returns the
>    > number of strings in the list as a decimal number.
> 
> Hmm, I glossed over this before.  There are other environments
> (including typical regex implementations) where it's common to have
> submatch 0 represent the entire matched string.  Access to the number of
> strings is useful, but so is access to the entire match (probably more
> so than the number of matches, since that's predictable from the pattern
> used).  Since it's nice to be consistent with what people might already
> be used to, I'd recommend having index 0 be the entire match, and something
> else be the count of the matches.  Maybe a special ${#} for the number
> of matches.

I think too little is gained by this change to incorporate it at this
stage.

> Or keep ${0} as the count, and add something else (e.g. ${*}) as the
> complete match string.

explicit is better than implicit -- users can just add an extra pair of
parentheses.  (this only applies to :regex.  for :matches, the match
string is always equal to the source string.)

> 4.  Action set
> 
>    > An illegal name MUST cause a syntax error.
> 
> "MUST be detected as a syntax error" ?  (at compile time?  runtime?)

from RFC 3028, 2.10.6:

   In any programming language, there are compile-time and run-time
   errors.

   Compile-time errors are ones in syntax that are detectable if a
   syntax check is done.

so compile-time.

> 4.1.  Modifiers
> 
>    > More than one modifier can be specified, in which case
>    > they are applied according to this precedence list, highest value
>    > first:
> 
> I think this has been addressed before, but "highest value" is still
> ambiguous because "highness" isn't really an attribute of a number, and
> the word "precedence" implies doing things in numeric order, 1, 2, 3.
> So some people, if not most people, will think of the "highest
> precedence value" as having the smallest numeric value.  Maybe:
> 
>    More than one modifier can be specified, in which case they are
>    applied in reverse order of precedence value, i.e. from largest to
>    smallest, according to this table:
> 
> I would personally make it smallest value first, but either way as long
> as it's clear.

I can do s/highest/largest/ if you think that's better.  introducing
some "order of precedence value" will surely only muddle the issue.

> 5.  Test string
> 
> I agree with another commenter's earlier remark that :count is silly.
> Unless the intent is to count the number of matches, rather than the
> number of strings?  It doesn't say that, though-- and I don't really
> know why that would be useful, either.

leaving it out will introduce an area of undefined behaviour, which IMO
would be bad and unnecessary.
-- 
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 j168jDcr068351; Sun, 6 Feb 2005 00:45:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j168jD13068350; Sun, 6 Feb 2005 00:45:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j168j87L068304 for <[e-mail]>; Sun, 6 Feb 2005 00:45:12 -0800 (PST) (envelope-from [e-mail])
Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 927D4C53192 for <[e-mail]>; Sun,  6 Feb 2005 03:45:05 -0500 (EST)
X-Sasl-enc: z0pAH3AjMWZy7XQryGIR6A 1107679504
Received: from eric (AFontenayssB-152-1-46-221.w83-114.abo.wanadoo.fr [83.114.188.221]) by frontend2.messagingengine.com (Postfix) with ESMTP id 675DD75E for <[e-mail]>; Sun,  6 Feb 2005 03:45:04 -0500 (EST)
From: "Eric SOHIER" <[e-mail]>
To: <[e-mail]>
Subject: Regulate sieve which does not go!
Date: Sun, 6 Feb 2005 09:45:02 +0100
Message-ID: <000f01c50c28$274781b0$0864a8c0@eric>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C50C30.890BE9B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C50C30.890BE9B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

I'm a new member of the list and I use the service fmailbox which manages
the rules sieve.

 

I would like to know how to describe a rule which makes it possible to move
a message which contains a specific address "from"?

 

I tested this:

 

If header: contains ["To"] ["[e-mail]"] {fileinto
"INBOX.Astronomie.astrocam";}

 

But that does not go on this message:

 

X-Sender: [e-mail]

X-Apparently-To: [e-mail]

Received: (qmail 26728 invoked from network); 21 Jan 2005 13:46:09 -0000

Received: from unknown (66.218.66.218)

  by m17.grp.scd.yahoo.com with QMQP; 21 Jan 2005 13:46:09 -0000

Received: from unknown (HELO hotmail.com) (65.54.185.29)

  by mta3.grp.scd.yahoo.com with SMTP; 21 Jan 2005 13:46:09 -0000

Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;

      Fri, 21 Jan 2005 05:42:02 -0800

Message-ID: <[e-mail]>

Received: from 84.195.167.88 by by15fd.bay15.hotmail.msn.com with HTTP;

     Fri, 21 Jan 2005 13:41:05 GMT

X-Originating-Email: [[e-mail]]

X-Sender: [e-mail]

To: [e-mail], [e-mail],

     [e-mail]

X-OriginalArrivalTime: 21 Jan 2005 13:42:02.0351 (UTC)
FILETIME=[FCCEFFF0:01C4FFBE]

X-eGroups-Remote-IP: 65.54.185.29

From: "patricia david" <[e-mail]>

X-Originating-IP: [84.195.167.88]

X-Yahoo-Profile: astrobourlingueurs

MIME-Version: 1.0

Mailing-List: list [e-mail]; contact
[e-mail]

Delivered-To: mailing list [e-mail]

Precedence: bulk

List-Unsubscribe: <mailto:[e-mail]>

Date: Fri, 21 Jan 2005 13:41:05 +0000

Subject: [astrocam] Tete de cheval

Content-Type: multipart/mixed;

 boundary="----=_NextPart_000_4a7a_535c_14b6"

 

Why ?

 

Thanks by advance.

 

-- Eric SOHIER

 


------=_NextPart_000_0010_01C50C30.890BE9B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.StyleCourrierlectronique17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Hello,</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I&#8217;m a new member of the list and I use =
the
service fmailbox which manages the rules sieve.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I would like to know how to describe a rule =
which
makes it possible to move a message which contains a specific address
&#8220;from&#8221;?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I tested this:</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>If header: contains =
[&#8220;To&#8221;]
[&#8220;[e-mail]&#8221;] {fileinto =
&#8220;INBOX.Astronomie.astrocam&#8221;;}</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>But that does not =
go on this
message:</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span lang=3DDE
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Sender:
[e-mail]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span lang=3DDE
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Apparently-To: =
[e-mail]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: (qmail =
26728
invoked from network); </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>21 Jan 2005</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> </span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:"Courier New"'>13:46:09</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from =
unknown
(66.218.66.218)</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp; by
m17.grp.scd.yahoo.com with QMQP; </span></font><font
 face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'>21 Jan
 2005</span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:
"Courier New"'> </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>13:46:09</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from =
unknown (HELO
hotmail.com) (65.54.185.29)</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp; by =
mta3.grp.scd.yahoo.com
with SMTP; </span></font><font face=3D"Courier New"><span lang=3DEN-GB
 style=3D'font-family:"Courier New"'>21 Jan 2005</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> </span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:"Courier New"'>13:46:09</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from mail =
pickup
service by hotmail.com with Microsoft SMTPSVC;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;</span></font><font face=3D"Courier =
New"><span lang=3DEN-GB style=3D'font-family:"Courier New"'>Fri, 21 Jan
 2005</span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:
"Courier New"'> </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>05:42:02</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0800</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Message-ID:
&lt;[e-mail]&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from =
84.195.167.88
by by15fd.bay15.hotmail.msn.com with HTTP;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font face=3D"Courier =
New"><span lang=3DEN-GB style=3D'font-family:"Courier New"'>Fri, 21 Jan
 2005</span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:
"Courier New"'> </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>13:41:05 GMT</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>X-Originating-Email:
[[e-mail]]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Sender:
[e-mail]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>To:
[e-mail], [e-mail],</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>X-OriginalArrivalTime: </span></font><font face=3D"Courier =
New"><span lang=3DEN-GB style=3D'font-family:"Courier New"'>21 Jan =
2005</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'>
13:42:02.0351 (UTC) FILETIME=3D[FCCEFFF0:01C4FFBE]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>X-eGroups-Remote-IP:
65.54.185.29</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>From: =
&quot;patricia david&quot;
&lt;[e-mail]&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Originating-IP:
[84.195.167.88]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Yahoo-Profile: =
astrobourlingueurs</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>MIME-Version: =
1.0</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Mailing-List: list
[e-mail]; contact =
[e-mail]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Delivered-To: =
mailing list
[e-mail]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Precedence: =
bulk</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>List-Unsubscribe:
&lt;mailto:[e-mail]&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>Date: Fri, 21 Jan 2005 13:41:05 =
+0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>Subject: [astrocam] Tete de =
cheval</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>Content-Type: =
multipart/mixed;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>&nbsp;</span></font><font face=3D"Courier =
New"><span
lang=3DEN-GB style=3D'font-family:"Courier =
New"'>boundary=3D&quot;----=3D_NextPart_000_4a7a_535c_14b6&quot;</span></=
font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>Why ?</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>Thanks by advance.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-- Eric SOHIER</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0010_01C50C30.890BE9B0--



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 j164r24Y097749; Sat, 5 Feb 2005 20:53:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j164r2p1097748; Sat, 5 Feb 2005 20:53:02 -0800 (PST)
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 j164qvkI097738 for <[e-mail]>; Sat, 5 Feb 2005 20:52:57 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 52265 invoked by uid 101); 5 Feb 2005 23:52:56 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 5 Feb 2005 23:52:56 -0500
To: Cyrus Daboo <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis
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 Thu, Feb 03, 2005 at 04:14:34PM -0500, Cyrus Daboo wrote:
> FYI the draft for the new version of the spamtest extension is now 
> available.

Picky comments from mem..

I have a hard time reading this document, mainly because of phrases
that include "returning strings" and overloading of some words to
mean different things.  Perhaps it's just the way my brain works,
or doesn't work.  Specifically:


1.  Introduction and Overview

   > The purpose of this document is to introduce two SIEVE tests that can
   > be used to implement 'generic' tests for spam and viruses in messages
   > processed via SIEVE scripts.  These tests return a string containing
   > a range of numeric values that indicate the severity of spam or
   > viruses in a message, or a string that indicates the message has not
   > passed through any spam or virus checking tools.

When you talk about SIEVE tests, it reads as though you are talking
about SIEVE language elements.  Those elements won't really do those
things, it's the underlying filter implementation that would interpret
the result of spam or virus analysis and produce, conceptually, a string
(or strings) that can be used by those SIEVE language elements.  (The
next sentence says as much.)  Also, that conceptual string probably
contains "a number that lies within a range of numeric values" -- the
string would not contain "a range of numeric values."


3.1  General Considerations

   > The "spamtest" and "virustest" tests described below both return a
   > string that starts with a numeric value, followed by an optional
   > space (%x20) character and optional arbitrary text.

Here's where the trouble really lies.  This pretty clearly is talking
about SIEVE language statements -- and if it isn't, then the use of
those words is even more of a problem.  Those statements do not return a
string; they act upon the string that was returned by the underlying
tests.  (Or, rather, they act as if they did that: no string really has
to be present.)


   > The additional text can be used to carry implementation
   > specific details about the tests performed and descriptive comments
   > about the result.  Tests can be done using standard string
   > comparators against this text if it helps to refine behaviour,

Does "this text" refer to "The additional text" or to the entire string?
The English grammar implies the former, but text in the introduction
implies the latter.  For example, given a underlying spam test result
of:

   "4 too many recipients"

how does:

    if spamtest :is "too many recipients"  { ... }

evaluate?  IMHO testing against the "additional text" would be the most
useable.


   > The "spamtest" test evaluates to true if the spamtest result matches
   > the value.  The type of match is specified by the optional match

Another example where the word "spamtest" means two different things:
the SIEVE statement and the underlying test that produces a string for
use by that statement.  I'd recommend finding different ways to
refer to the SIEVE statement and the underlying analysis of spam and
virus results.

[ Imagine similar comments about similar sections ... ]



BTW I think this is the kind of extension that could be solved with
better fundamental language elements and/or better coordination between
language extensions.

For example, one could build on the proposed "variables" extension by
imagining a new set of read-only variables within specific namespaces
(per the old namespace idea, a la dates and timezones).  Imagine:

   require "variables";
   require [ "relational", "comparator-i;ascii-numeric" ];

   set "spamval" "${spamtest::value}"
   set "spampct" "${spamtest::pctvalue}"
   set "spamtext" "${spamtest::text}"

   if string :value "ge"
             :comparator "i;ascii-numeric"
	     "${spamval}" "3" { ... }
   if string :value "ge"
             :comparator "i;ascii-numeric"
             "${spamtest::pctvalue}" "30" { ... }

Time travel might be required 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 j15M1tGP058698; Sat, 5 Feb 2005 14:01:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15M1t9Y058697; Sat, 5 Feb 2005 14:01:55 -0800 (PST)
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 j15M1rMD058689 for <[e-mail]>; Sat, 5 Feb 2005 14:01:54 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 65525 invoked by uid 101); 5 Feb 2005 17:01:51 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 5 Feb 2005 17:01:51 -0500
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail], "Mark E. Mallett" <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
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, Feb 04, 2005 at 12:42:45PM +0100, Kjetil Torgrim Homme wrote:
> 
> I've updated the document and made quite a few changes, although they
> are all editorial.
> 
> Document: draft-ietf-sieve-variables-01.txt           University of Oslo


Hi-

I would like to include by reference, without going on about it further
here, my earlier remarks about choices of keywords that might be likely
to collide with future language enhancements.  Those issues are still
important, if only to me.

Also I have a few new niggling comments, as follows.

3.

   > "When a string is evaluated ..."

I'm not sure that the concept of evaluating a string has been
introduced, so the "when a string is evaluated" is not strictly clear
(even if everybody probably knows what it means).  So perhaps lay the
groundwork of saying that this extension enables interpretation of
strings at the moment they are used during runtime , and then say "when
a string is interpreted..."   or just change the word to "interpreted" :-)



3.2.  Numbered variables

   > For ":matches"...
   > The wildcards match as little as possible (non-greedy matching).

Even though I am in favor of this: this is a refinement of RFC3028
(which is silent on the greediness issue).  Does this need to be
explicitly stated?  I would think this should be an item for 3028bis or
whatever the next SIEVE base draft is, as well.  (Being able to specify
the :matches greediness would be a plus.)


   > The first string in the list has index 1.  If the index is out of
   > range, the empty string will be substituted.  Index 0 returns the
   > number of strings in the list as a decimal number.

Hmm, I glossed over this before.  There are other environments
(including typical regex implementations) where it's common to have
submatch 0 represent the entire matched string.  Access to the number of
strings is useful, but so is access to the entire match (probably more
so than the number of matches, since that's predictable from the pattern
used).  Since it's nice to be consistent with what people might already
be used to, I'd recommend having index 0 be the entire match, and something
else be the count of the matches.  Maybe a special ${#} for the number
of matches.

Or keep ${0} as the count, and add something else (e.g. ${*}) as the
complete match string.


4.  Action set

   > An illegal name MUST cause a syntax error.

"MUST be detected as a syntax error" ?  (at compile time?  runtime?)



4.1.  Modifiers

   > More than one modifier can be specified, in which case
   > they are applied according to this precedence list, highest value
   > first:

I think this has been addressed before, but "highest value" is still
ambiguous because "highness" isn't really an attribute of a number, and
the word "precedence" implies doing things in numeric order, 1, 2, 3.
So some people, if not most people, will think of the "highest
precedence value" as having the smallest numeric value.  Maybe:

   More than one modifier can be specified, in which case they are
   applied in reverse order of precedence value, i.e. from largest to
   smallest, according to this table:

I would personally make it smallest value first, but either way as long
as it's clear.


5.  Test string

I agree with another commenter's earlier remark that :count is silly.
Unless the intent is to count the number of matches, rather than the
number of strings?  It doesn't say that, though-- and I don't really
know why that would be useful, either.

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 j14MGnd2002194; Fri, 4 Feb 2005 14:16:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MGnCL002193; Fri, 4 Feb 2005 14:16:49 -0800 (PST)
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 j14MGmVb002178 for <[e-mail]>; Fri, 4 Feb 2005 14:16:48 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 14:16:39 -0800 (PST)
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Date: Fri, 04 Feb 2005 14:14:57 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Fri, 04 Feb 2005 12:42:45 +0100" <[e-mail]>
Message-id: <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
To: Kjetil Torgrim Homme <[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>

> I've updated the document and made quite a few changes, although they
> are all editorial.

> ...

> I haven't submitted this, because I'm not sure if it should be done by
> me or the chair?

The chair only has to deal with -00 submissions of WG drafts. After
the -00 version you should be able to do it yourself.

				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 j14JK6qY088683; Fri, 4 Feb 2005 11:20:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JK6S2088682; Fri, 4 Feb 2005 11:20:06 -0800 (PST)
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 j14JK3oi088675 for <[e-mail]>; Fri, 4 Feb 2005 11:20:05 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 11:20:01 -0800 (PST)
Cc: [e-mail], IETF MTA Filters List <[e-mail]>
Date: Fri, 04 Feb 2005 11:19:16 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Fri, 04 Feb 2005 14:06:56 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: spamtestbis
To: Cyrus Daboo <[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>

> Hi [e-mail],

> --On February 3, 2005 2:08:56 PM -0800 [e-mail] wrote:

> >> FYI the draft for the new version of the spamtest extension is now
> >> available. The only change between this and the current RFC is the
> >> addition of a :percent argument to the spamtest test to allow for a
> >> numeric range of 0 - 100. The value -1 is used to indicate a message
> >> that was not categorised in anyway.
> >
> > First, I don't think the -1 is a good idea because of how it interacts
> > with numeric comparators. I'd much rather retain 0 as the value
> > indicating no test was done.

> So we would have:

>     spamtest    interpretation
>     value

>    		 0          message was not tested for spam
>    		 1          message was tested and is clear of spam
>    	2 - 99     message was tested and has a varying likelihood of
>    		            containing spam in increasing order
>    		 100        message was tested and definitely contains spam

Yes, I think this is what we want.

> > The only other issue I see with the draft is the business of making
> > require "spamtest" and require "spamtestpercent" mutually exclusive. I
> > certainly agree that we want require "spamtestpercent" to subsume require
> > "spamtest" - - require lists in sieve can be really long - but I wonder
> > if making them mutually exclusive goes too far.

> I can change the 'MUST NOT' to a 'SHOULD NOT' for that requirement.

> > Additionally, one thing that isn't entirely clear with the current text
> > is that the following is legal:
> >
> >    require "spamtest"; if spamtest :contains "foo" ...
> >
> > That is, spamtest without a :percent is allowed when require
> > "spamtestpercent" is used. I think this should be clarified.
> >
> >

> Here is some alternative text for this:

> Old:

>    SIEVE implementations that implement the "spamtest" test have an
>    identifier of "spamtest" for use with the capability mechanism.  If
>    the ":percent" argument is used with any spamtest test, then the
>    capability idenitifier "spamtestpercent" MUST be present, and the
>    "spamtest" capability MUST NOT be present.

> New:

>    SIEVE implementations that implement the "spamtest" test use an
>    identifier of either "spamtest" or "spamtestpercent" for use with
>    the capability mechanism.

>    If the ":percent" argument is not used with any spamtest test, then
>    one of either the "spamtest" or "spamtestpercent" capability
>    identifiers MUST be present, though both SHOULD NOT be present together.

>    If the ":percent" argument is used with any spamtest test, then
>    the "spamtestpercent" capability identifier MUST be present, and
>    the "spamtest" capability identitifer SHOULD NOT be present.

Much better. I'm happy with this.

				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 j14J72dj087870; Fri, 4 Feb 2005 11:07:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14J72Bk087869; Fri, 4 Feb 2005 11:07:02 -0800 (PST)
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 j14J72na087861 for <[e-mail]>; Fri, 4 Feb 2005 11:07:02 -0800 (PST) (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 j14IxV6E028064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2005 13:59:32 -0500
Date: Fri, 04 Feb 2005 14:06:56 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (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 [e-mail],

--On February 3, 2005 2:08:56 PM -0800 [e-mail] wrote:

>> FYI the draft for the new version of the spamtest extension is now
>> available. The only change between this and the current RFC is the
>> addition of a :percent argument to the spamtest test to allow for a
>> numeric range of 0 - 100. The value -1 is used to indicate a message
>> that was not categorised in anyway.
>
> First, I don't think the -1 is a good idea because of how it interacts
> with numeric comparators. I'd much rather retain 0 as the value
> indicating no test was done.

So we would have:

    spamtest    interpretation
    value

   		 0          message was not tested for spam
   		 1          message was tested and is clear of spam
   	2 - 99     message was tested and has a varying likelihood of
   		            containing spam in increasing order
   		 100        message was tested and definitely contains spam

Perhaps those that requested the percent range could state whether this is 
acceptable.

> The only other issue I see with the draft is the business of making
> require "spamtest" and require "spamtestpercent" mutually exclusive. I
> certainly agree that we want require "spamtestpercent" to subsume require
> "spamtest" - - require lists in sieve can be really long - but I wonder
> if making them mutually exclusive goes too far.

I can change the 'MUST NOT' to a 'SHOULD NOT' for that requirement.

> Additionally, one thing that isn't entirely clear with the current text
> is that the following is legal:
>
>    require "spamtest"; if spamtest :contains "foo" ...
>
> That is, spamtest without a :percent is allowed when require
> "spamtestpercent" is used. I think this should be clarified.
>
>

Here is some alternative text for this:

Old:

   SIEVE implementations that implement the "spamtest" test have an
   identifier of "spamtest" for use with the capability mechanism.  If
   the ":percent" argument is used with any spamtest test, then the
   capability idenitifier "spamtestpercent" MUST be present, and the
   "spamtest" capability MUST NOT be present.

New:

   SIEVE implementations that implement the "spamtest" test use an
   identifier of either "spamtest" or "spamtestpercent" for use with
   the capability mechanism.

   If the ":percent" argument is not used with any spamtest test, then
   one of either the "spamtest" or "spamtestpercent" capability
   identifiers MUST be present, though both SHOULD NOT be present together.

   If the ":percent" argument is used with any spamtest test, then
   the "spamtestpercent" capability identifier MUST be present, and
   the "spamtest" capability identitifer SHOULD NOT be present.



-- 
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 j14IiNeo086258; Fri, 4 Feb 2005 10:44:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14IiN1w086257; Fri, 4 Feb 2005 10:44:23 -0800 (PST)
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 j14IiHM6086248 for <[e-mail]>; Fri, 4 Feb 2005 10:44:18 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 10:44:13 -0800 (PST)
Cc: Cyrus Daboo <[e-mail]>, IETF MTA Filters List <[e-mail]>
Date: Fri, 04 Feb 2005 10:41:03 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Fri, 04 Feb 2005 13:01:38 +0000" <006601c50ab9$b1ed3eb0$6501a8c0@nigelhome>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <006601c50ab9$b1ed3eb0$6501a8c0@nigelhome>
Subject: Re: spamtestbis
To: Nigel Swinson <[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>

> > > FYI the draft for the new version of the spamtest extension is now
> > > available. The only change between this and the current RFC is the addition
> > > of a :percent argument to the spamtest test to allow for a numeric range of
> > > 0 - 100. The value -1 is used to indicate a message that was not
> > > categorised in anyway.

> I'm surprised we need a percentage spam score... I would have thought 10
> levels was enough.  Indeed in your example you use level 30(%) = 3.

FWIW, I personally don't see any need for more levels, but I have seen
some user requests for this and I understand others have seen considerable
demand for it.
 
> > First, I don't think the -1 is a good idea because of how it interacts with
> > numeric comparators. I'd much rather retain 0 as the value indicating no test
> > was done.

> I agree.  I think many existing scripts will test for 0 as a way of finding
> out if the message was scanned, so why risk breaking them?  Personally I don't
> mind if "message is clear of spam" = 1%.  It's not really an exact science
> anyway...

Yeah, "the exact science of spam identification" is indeed an oxymoron. Its
the reason why 10 levels is enough for me at least.

				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 j14ID2Dl084039; Fri, 4 Feb 2005 10:13:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14ID2XF084038; Fri, 4 Feb 2005 10:13:02 -0800 (PST)
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 j14ICvYf084026 for <[e-mail]>; Fri, 4 Feb 2005 10:12:57 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed; charset=Windows-1252; reply-type=original
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 04 Feb 2005 10:12:45 -0800 (PST)
Cc: [e-mail], [e-mail]
Date: Fri, 04 Feb 2005 10:00:19 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Fri, 04 Feb 2005 13:45:00 +0000" <000a01c50abf$b9c0f8b0$[e-mail]>
Message-id: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]> <000a01c50abf$b9c0f8b0$[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[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>

> > I'm a fan of associative arrays, having first used them in the Sail quite some
> > time ago. (Anyone else remember Sail?) However, I have to say I think
> > associative arrays would be serious overkill for sieve. Yes, I realize they're
> > powerful, but they introduce significant language and implementation
> > complexity.

> It's really only read only associative arrays I was proposing, so that
> eliminates a large amount of complexity.  If read-only associative arrays
> are overkill for Sieve then how best can we support authoring of simple
> messages based on the content of the inbound mail?

This begs the question of whether or not complex header transformations are
something we should be doing with sieve. I happen to think the answer to this
particular question is "no". Copying a subject and perhaps a couple of other
fields into a new message is about as far as I think sieve needs to go.

Of course there are all sorts of more complex things people will want to do.
But this is a seriously slippery slope, because lurking not far away are
things like content summaries, keyword extraction, translation services,
content shaping, and so on. This stuff has "research problem" written all
over it, and IMO sieve needs to stay away from this space.

> Do you/we favour the $subject$ approach?

I think it is just sufficient to get the jobs appropriate for sieve done.

> I guess I would accept some implementation complexity
> if it means the language is easier to use....

Ease of use is a two-edged sword. One of the things sieve is used for is
as an output format for GUI filter builder utilities. Variables are already
pretty hard to handle in such tools, things like associative arrays
are really over the top.

				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 j14FoseH069018; Fri, 4 Feb 2005 07:50:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Fos9b069017; Fri, 4 Feb 2005 07:50:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Foq9s068943 for <[e-mail]>; Fri, 4 Feb 2005 07:50:52 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (scotty.rockliffe.com [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Fri, 4 Feb 2005 07:50:47 -0800
Message-ID: <005601c50ad1$4ae2d730$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Date: Fri, 4 Feb 2005 15:50:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

> a)   added example for string test

In the rest of your examples, the # comment inside the {} is only indented 
once, but here it's indented several times?  Looks a little odd....

> c)   added Syntax line for MODIFIER.

Aren't you missing an indent on syntax line for Modifiers?

> d)   added comment to an example showing that the non-greedy "*" still
>     matches everything due to implicit anchors.

I think this is an important enough concept to make more explicit.  Without 
this concept, I don't believe it's possible to get the entirity of a mail 
header into a Sieve Variable without using the regex extension, and I think 
this is something people will want to do.  Perhaps amend this paragraph:

   For ":matches", the list will contain one string for each wildcard
   ("?" and "*") in the match pattern.  Each string holds what the
   corresponding wildcard expands to, possibly the empty string.  The
   wildcards match as little as possible (non-greedy matching).

Not sure how it should be modified, I'd probably change it to say it does 
greedy matching ;o)

Nigel 



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 j14EZ7Xm062467; Fri, 4 Feb 2005 06:35:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14EZ6CQ062455; Fri, 4 Feb 2005 06:35:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14EXuSU062408 for <[e-mail]>; Fri, 4 Feb 2005 06:34:56 -0800 (PST) (envelope-from [e-mail])
Received: from chico.njus.no (80.80-202-166.nextgentel.com [80.202.166.80]) by mail.broadpark.no (Postfix) with ESMTP id 7B6A24189; Fri,  4 Feb 2005 12:46:21 +0100 (MET)
Received: from chico.njus.no (localhost.localdomain [127.0.0.1]) by chico.njus.no (8.12.11/8.12.11) with ESMTP id j14BgnWo018109; Fri, 4 Feb 2005 12:42:49 +0100
Received: (from kjetilho@localhost) by chico.njus.no (8.12.11/8.12.11/Submit) id j14BgltO018107; Fri, 4 Feb 2005 12:42:47 +0100
X-Authentication-Warning: chico.njus.no: kjetilho set sender to [e-mail] using -f
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]>
Content-Type: multipart/mixed; boundary="=-Ze05xgmdDdl5uJ7MBCLh"
Date: Fri, 04 Feb 2005 12:42:45 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.2 
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>

--=-Ze05xgmdDdl5uJ7MBCLh
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Tue, 2005-02-01 at 17:21 +0000, Alexey Melnikov wrote:
> The WGLC is over and I haven't seen any comments on the document. This 
> means that it is either perfect, or that people didn't have time to 
> review it.
> 
> Ned and myself have reviewed the document. Anybody else?
> Can I ask people who have reviewed the document to email me directly and 
> state that they found no problems with the document. I would appreciate 
> any feedback by February 7th (next Monday). Thanks!

I've updated the document and made quite a few changes, although they
are all editorial.

0.2.6.  Changes since -00 (WG series)

a)   added example for string test

b)   moved introductory text for MODIFIER from 5.1 into 5.0

c)   added Syntax line for MODIFIER.

d)   added comment to an example showing that the non-greedy "*" still
     matches everything due to implicit anchors.

e)   added example of expansion of string with unbalanced braces.

I haven't submitted this, because I'm not sure if it should be done by
me or the chair?
-- 
Kjetil T.

--=-Ze05xgmdDdl5uJ7MBCLh
Content-Disposition: attachment; filename=draft-ietf-sieve-variables-01.txt
Content-Type: text/plain; name=draft-ietf-sieve-variables-01.txt; charset=ISO-8859-1
Content-Transfer-Encoding: base64

DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEsuIFQuIEhvbW1lDQpVcGRhdGVzOiAzMDI4DQpEb2N1bWVudDogZHJh
ZnQtaWV0Zi1zaWV2ZS12YXJpYWJsZXMtMDEudHh0ICAgICAgICAgICBVbml2ZXJzaXR5IG9mIE9z
bG8NCkV4cGlyZXMgQXVnIDMsIDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMyBGZWIgMjAwNQ0KDQoNCg0KICAgICAgICAgICBTaWV2ZSBNYWlsIEZpbHRlcmlu
ZyBMYW5ndWFnZTogVmFyaWFibGVzIEV4dGVuc2lvbg0KDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVt
bw0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIHN1Ympl
Y3QgdG8gYWxsIHByb3Zpc2lvbnMNCiAgIG9mIHNlY3Rpb24gMyBvZiBSRkMgMzY2Ny4gIEJ5IHN1
Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaA0KICAgYXV0aG9yIHJlcHJlc2VudHMg
dGhhdCBhbnkgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZg0KICAgd2hp
Y2ggaGUgb3Igc2hlIGlzIGF3YXJlIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5k
IGFueSBvZg0KICAgd2hpY2ggaGUgb3Igc2hlIGJlY29tZSBhd2FyZSB3aWxsIGJlIGRpc2Nsb3Nl
ZCwgaW4gYWNjb3JkYW5jZSB3aXRoDQogICBSRkMgMzY2OC4NCg0KICAgSW50ZXJuZXQtRHJhZnRz
IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRh
c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl
IHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l
bnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy
YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBt
YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg
YXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh
ZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g
YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0
LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8x
aWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93
IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9z
aGFkb3cuaHRtbC4NCg0KICAgRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQu
DQoNCg0KQWJzdHJhY3QNCg0KICAgSW4gYWR2YW5jZWQgZmlsdGVyaW5nIHJ1bGUgc2V0cywgaXQg
aXMgdXNlZnVsIHRvIGtlZXAgc3RhdGUgb3INCiAgIGNvbmZpZ3VyYXRpb24gZGV0YWlscyBhY3Jv
c3MgcnVsZXMuICBUaGlzIGV4dGVuc2lvbiBjaGFuZ2VzIHRoZQ0KICAgaW50ZXJwcmV0YXRpb24g
b2Ygc3RyaW5ncywgYWRkcyBhbiBhY3Rpb24gdG8gc3RvcmUgZGF0YSBpbiB2YXJpYWJsZXMsDQog
ICBhbmQgc3VwcGxpZXMgYSBuZXcgdGVzdCBzbyB0aGF0IHRoZSB2YWx1ZSBvZiBhIHN0cmluZyBj
YW4gYmUNCiAgIGV4YW1pbmVkLg0KDQoNCg0KDQpIb21tZSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0
IERyYWZ0ICAgICAgICBTaWV2ZSAtLSBWYXJpYWJsZXMgRXh0ZW5zaW9uICAgICAgICAgICAgMyBG
ZWIgMjAwNQ0KDQoNCjAuICBNZXRhLWluZm9ybWF0aW9uIG9uIHRoaXMgZHJhZnQNCg0KICAgVGhp
cyBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBmYWNpbGl0YXRlIGRpc2N1c3Npb24uICBJdCB3
aWxsIGJlDQogICByZW1vdmVkIHdoZW4gdGhpcyBkb2N1bWVudCBsZWF2ZXMgdGhlIEludGVybmV0
LURyYWZ0IHN0YWdlLg0KDQoNCjAuMS4gIERpc2N1c3Npb24NCg0KICAgVGhpcyBkcmFmdCBpcyBp
bnRlbmRlZCB0byBiZSBhbiBleHRlbnNpb24gdG8gdGhlIFNpZXZlIG1haWwgZmlsdGVyaW5nDQog
ICBsYW5ndWFnZSwgYXZhaWxhYmxlIGZyb20gdGhlIFJGQyByZXBvc2l0b3J5IGFzDQogICA8ZnRw
Oi8vZnRwLmlldGYub3JnL3JmYy9yZmMzMDI4LnR4dD4uDQoNCiAgIFRoaXMgZHJhZnQgYW5kIHRo
ZSBTaWV2ZSBsYW5ndWFnZSBpdHNlbGYgYXJlIGJlaW5nIGRpc2N1c3NlZCBvbiB0aGUNCiAgIE1U
QSBGaWx0ZXJzIG1haWxpbmcgbGlzdCBhdCA8aWV0Zi1tdGEtZmlsdGVyc0BpbWMub3JnPi4gIFN1
YnNjcmlwdGlvbg0KICAgcmVxdWVzdHMgY2FuIGJlIHNlbnQgdG8gPGlldGYtbXRhLWZpbHRlcnMt
cmVxdWVzdEBpbWMub3JnPiAoc2VuZCBhbg0KICAgZW1haWwgbWVzc2FnZSB3aXRoIHRoZSB3b3Jk
ICJzdWJzY3JpYmUiIGluIHRoZSBib2R5KS4gIE1vcmUNCiAgIGluZm9ybWF0aW9uIG9uIHRoZSBt
YWlsaW5nIGxpc3QgYWxvbmcgd2l0aCBhIFdXVyBhcmNoaXZlIG9mIGJhY2sNCiAgIG1lc3NhZ2Vz
IGlzIGF2YWlsYWJsZSBhdCA8aHR0cDovL3d3dy5pbWMub3JnL2lldGYtbXRhLWZpbHRlcnMvPi4N
Cg0KDQowLjIuICBOb3RlZCBDaGFuZ2VzDQoNCjAuMi4xLiAgQ2hhbmdlcyBzaW5jZSAtMDANCg0K
YSkgICBhbGxvdyBnZW5lcmljIHRpbWUgem9uZSBuYW1lcywgd2l0aG91dCByZXF1aXJpbmcgaW1w
bGVtZW50YXRpb25zIHRvDQogICAgIHN1cHBvcnQgaXQuICBhZGRlZCBhICIke3RpbWV6b25lfSIg
dmFyaWFibGUgc28gdGhhdCB0aGUgdXNlciBjYW4NCiAgICAgY2hlY2sgaWYgdGhlIGltcGxlbWVu
dGF0aW9uIGRvZXMgc3VwcG9ydCB0aGUgdGltZSB6b25lIG5hbWUgaGUNCiAgICAgd2FudHMuICB0
aGUgZGVmYXVsdCB0aW1lIHpvbmUgd2FzIGNoYW5nZWQgdG8gbG9jYWx0aW1lIGFnYWluLg0KDQpi
KSAgIGFsbG93IGJhY2sgcmVmZXJlbmNlcyBmcm9tIDptYXRjaGVzIGFzIHdlbGwgYXMgOnJlZ2V4
Lg0KDQpjKSAgIGFkZGVkIGEgc2VjdGlvbiBvbiBpbXBsZW1lbnRhdGlvbiBsaW1pdHMuDQoNCmQp
ICAgY2xhcmlmaWVkIGdsb2JhbCBzY29wZSBzbyB0aGF0IGl0IHNwYW5zIGluY2x1ZGUuDQoNCmUp
ICAgY2xhcmlmaWVkIHRoYXQgdGhpcyBkcmFmdCBvbmx5IGFmZmVjdHMgc2NyaXB0cyB3aGljaCBy
ZXF1aXJlDQogICAgICJ2YXJpYWJsZXMiLg0KDQpmKSAgIGNoYW5nZWQgbW9kaWZpZXJzIGludG8g
YmVpbmcgdGFnZ2VkIGFyZ3VtZW50cyBmb3IgU0VULCBhZGRlZA0KICAgICBwcmVjZWRlbmNlIHRh
YmxlLg0KDQpnKSAgIGFkZGVkIG9wdGlvbmFsIENPTVBBUkFUT1IgdG8gU0VUIHRvIHNvbHZlIHRo
ZSBpbnRlcm5hdGlvbmFsaXNhdGlvbg0KICAgICBwcm9ibGVtIHdpdGggOmxvd2VyIGV0Yy4NCg0K
aCkgICB0aGUgbmFtZSBvZiB0aGUgdmFyaWFibGUgYmVpbmcgU0VUIGlzIHBhc3NlZCBpbiBhIHN0
cmluZyB0byBjb25mb3JtDQogICAgIHdpdGggb3ZlcmFsbCBTaWV2ZSBncmFtbWFyLiAgdGhpcyBz
dHJpbmcgaXMgZXhwbGljaXRseSBkaXNhbGxvd2VkDQogICAgIGZyb20gY29udGFpbmluZyB2YXJp
YWJsZSByZWZlcmVuY2VzLg0KDQoNCg0KDQpIb21tZSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0IERy
YWZ0ICAgICAgICBTaWV2ZSAtLSBWYXJpYWJsZXMgRXh0ZW5zaW9uICAgICAgICAgICAgMyBGZWIg
MjAwNQ0KDQoNCjAuMi4yLiAgQ2hhbmdlcyBzaW5jZSAtMDENCg0KYSkgICBjbGFyaWZ5IHRoYXQg
YSBjaGFyYWN0ZXIgaXMgYSBVbmljb2RlIGNoYXJhY3Rlci4NCg0KYikgICBhZGRlZCBwYXJhZ3Jh
cGggd2FybmluZyBhZ2FpbnN0IHJlbHlpbmcgb24gU2lldmUgZm9yIHZpcnVzIGNoZWNraW5nDQog
ICAgIHRvIHNlY3VyaXR5IHNlY3Rpb24uDQoNCmMpICAgYWRkZWQgYSBwYXJhZ3JhcGggZGVmaW5p
bmcgY29uc3RhbnQgc3RyaW5nLg0KDQpkKSAgIGFkZGVkIG5hbWVzcGFjZSB0byBncmFtbWFyLg0K
DQplKSAgIHJlbW92ZWQgU0VUREFURS4NCg0KZikgICBhZGRlZCB3b3JkaW5nIGFuZCBleGFtcGxl
IHJlcXVpcmluZyBzaG9ydC1jaXJjdWl0aW5nIG9mIHRlc3QNCiAgICAgZXZhbHVhdGlvbi4NCg0K
DQowLjIuMy4gIENoYW5nZXMgc2luY2UgLTAyDQoNCmEpICAgYWRkIHJlZmVyZW5jZXMgdG8gVW5p
Y29kZSBhbmQgVVRGLTgsIGFsc28gbW9yZSBib2lsZXJwbGF0ZQ0KDQpiKSAgIGZpeGVkIGEgbWVh
bmluZ2xlc3MgZXhhbXBsZS4NCg0KYykgICBjaGFuZ2VkIHRlcm0gIm51bWVyaWMgdmFyaWFibGVz
IiB0byAibnVtYmVyZWQgdmFyaWFibGVzIiB0byByZWR1Y2UNCiAgICAgdGhlIGNoYW5jZSBvZiBp
dCBiZWluZyBpbnRlcnByZXRlZCBhcyB2YXJpYWJsZXMgaG9sZGluZyBpbnRlZ2VyDQogICAgIHZh
bHVlcy4NCg0KZCkgICBhbGxvdyBmdXR1cmUgZXh0ZW5zaW9ucyB0byBhY2Nlc3MgdGhlIHJhdyBz
dHJpbmcgdmFsdWUuDQoNCmUpICAgYW4gdW5zdWNjZXNzZnVsIG1hdGNoIGRvZXMgTk9UIHJlc2V0
IHRoZSBudW1iZXJlZCB2YXJpYWJsZXMuDQoNCmYpICAgYWRkZWQgZGVmaW5pdGlvbiBvZiAic3Ry
aW5nIDpjb3VudCINCg0KZykgICBleGNlZWRpbmcgaW1wbGVtZW50YXRpb24gbGltaXRzIG9uIHZh
cmlhYmxlIGxlbmd0aHMgc2hvdWxkIG5vdCBtYWtlDQogICAgIHNjcmlwdHMgYWJvcnQuDQoNCg0K
MC4yLjQuICBDaGFuZ2VzIHNpbmNlIC0wMw0KDQphKSAgIGNsYXJpZnkgc2hvcnQtY2lyY3VpdGlu
Zy4NCg0KYikgICBlZGl0b3JpYWwgY2hhbmdlcy4NCg0KDQowLjIuNS4gIENoYW5nZXMgc2luY2Ug
LTA0DQoNCmEpICAgdGhlIHdpbGRjYXJkcyBpbiA6bWF0Y2hlcyB3YXMgY2hhbmdlZCBmcm9tIGdy
ZWVkeSB0byBub24tZ3JlZWR5IHRvDQogICAgIGJldHRlciBzdXBwb3J0ICJwcmluY2lwbGUgb2Yg
bGVhc3Qgc3VycHJpc2UiLiAgYWRkZWQgZXhhbXBsZSB0bw0KDQoNCg0KSG9tbWUgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDNd
DQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgU2lldmUgLS0gVmFyaWFibGVzIEV4dGVuc2lvbiAg
ICAgICAgICAgIDMgRmViIDIwMDUNCg0KDQogICAgIGlsbHVzdHJhdGUgdGhlIGRpZmZlcmVuY2Uu
DQoNCmIpICAgYWRkIGRlZmluaXRpb24gb2YgInZhcmlhYmxlIjsgY2xhcmlmeSBncmFtbWFyIGlz
IGJhc2VkIG9uIFtTSUVWRV07DQogICAgIGNsYXJpZnkgcm9sZSBvZiBuYW1lc3BhY2VzOyBhZGQg
aW5mb3JtYXRpdmUgcmVmZXJlbmNlcyBmb3IgW1JFR0VYXQ0KICAgICBhbmQgW1NQQU1URVNUXTsg
YWRkIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9yIFtSRUxBVElPTkFMXQ0KDQpjKSAgIHRoZSB1c2Ug
b2YgdW5zdXBwb3J0ZWQgbnVtYmVyZWQgdmFyaWFibGVzIG11c3QgYmUgZmxhZ2dlZCBhcyBhDQog
ICAgIHN5bnRheCBlcnJvciBieSBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KMC4yLjYuICBDaGFuZ2Vz
IHNpbmNlIC0wMCAoV0cgc2VyaWVzKQ0KDQphKSAgIGFkZGVkIGV4YW1wbGUgZm9yIHN0cmluZyB0
ZXN0DQoNCmIpICAgbW92ZWQgaW50cm9kdWN0b3J5IHRleHQgZm9yIE1PRElGSUVSIGZyb20gNS4x
IGludG8gNS4wDQoNCmMpICAgYWRkZWQgU3ludGF4IGxpbmUgZm9yIE1PRElGSUVSLg0KDQpkKSAg
IGFkZGVkIGNvbW1lbnQgdG8gYW4gZXhhbXBsZSBzaG93aW5nIHRoYXQgdGhlIG5vbi1ncmVlZHkg
IioiIHN0aWxsDQogICAgIG1hdGNoZXMgZXZlcnl0aGluZyBkdWUgdG8gaW1wbGljaXQgYW5jaG9y
cy4NCg0KZSkgICBhZGRlZCBleGFtcGxlIG9mIGV4cGFuc2lvbiBvZiBzdHJpbmcgd2l0aCB1bmJh
bGFuY2VkIGJyYWNlcy4NCg0KDQowLjMuICBPcGVuIElzc3Vlcw0KDQogICBUaGlzIGV4dGVuc2lv
biBpcyBpbiBjb25mbGljdCB3aXRoIGEgTVVTVCBpbiBbU0lFVkVdIDIuNDogIlRlc3RzIE1VU1QN
CiAgIE5PVCBoYXZlIHNpZGUgZWZmZWN0cy4iICBUaGlzIGRvY3VtZW50IHRoZXJlZm9yZSBjYW4n
dCBsZWF2ZSBkcmFmdA0KICAgc3RhdHVzIHVudGlsIGEgcmV2aXNlZCBTaWV2ZSBzcGVjaWZpY2F0
aW9uIGhhcyBiZWVuIGFjY2VwdGVkIGJ5IHRoZQ0KICAgSUVTRy4gIE5vIHNpZ25pZmljYW50IGNo
YW5nZXMgdG8gdGhpcyBkcmFmdCBhcmUgZm9yZXNlZW4gYmVmb3JlDQogICBzdWJtaXNzaW9uIGFz
IGEgcHJvcG9zZWQgc3RhbmRhcmQuDQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBUaGlzIGlz
IGFuIGV4dGVuc2lvbiB0byB0aGUgU2lldmUgbGFuZ3VhZ2UgZGVmaW5lZCBieSBbU0lFVkVdLiAg
SXQNCiAgIGFkZHMgc3VwcG9ydCBmb3Igc3RvcmluZyBhbmQgcmVmZXJlbmNpbmcgbmFtZWQgZGF0
YS4gIFRoZSBtZWNoYW5pc21zDQogICBkZXRhaWxlZCBpbiB0aGlzIGRvY3VtZW50IHdpbGwgb25s
eSBhcHBseSB0byBTaWV2ZSBzY3JpcHRzIHRoYXQNCiAgIGluY2x1ZGUgYSByZXF1aXJlIGNsYXVz
ZSBmb3IgdGhlICJ2YXJpYWJsZXMiIGV4dGVuc2lvbi4gIFRoZSByZXF1aXJlDQogICBjbGF1c2Vz
IHRoZW1zZWx2ZXMgYXJlIG5vdCBhZmZlY3RlZCBieSB0aGlzIGV4dGVuc2lvbi4NCg0KICAgQ29u
dmVudGlvbnMgZm9yIG5vdGF0aW9ucyBhcmUgYXMgaW4gW1NJRVZFXSBzZWN0aW9uIDEuMSwgaW5j
bHVkaW5nDQogICB1c2Ugb2YgW0tFWVdPUkRTXSBhbmQgW0FCTkZdLiAgVGhlIGdyYW1tYXIgYnVp
bGRzIG9uIHRoZSBncmFtbWFyIG9mDQogICBbU0lFVkVdLiAgSW4gdGhpcyBkb2N1bWVudCwgImNo
YXJhY3RlciIgbWVhbnMgYSBbVU5JQ09ERV0gY2hhcmFjdGVyLA0KICAgd2hpY2ggbWF5IGNvbnNp
c3Qgb2YgbXVsdGlwbGUgb2N0ZXRzIGNvZGVkIGluIFtVVEYtOF0sIGFuZCAidmFyaWFibGUiDQog
ICBpcyBhIG5hbWVkIHJlZmVyZW5jZSB0byBkYXRhIHN0b3JlZCBvciByZWFkIGJhY2sgdXNpbmcg
dGhlIG1lY2hhbmlzbXMNCiAgIG9mIHRoaXMgZXh0ZW5zaW9uLg0KDQoNCg0KDQpIb21tZSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh
Z2UgNF0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgICBTaWV2ZSAtLSBWYXJpYWJsZXMgRXh0ZW5z
aW9uICAgICAgICAgICAgMyBGZWIgMjAwNQ0KDQoNCjIuICBDYXBhYmlsaXR5IElkZW50aWZpZXIN
Cg0KICAgVGhlIGNhcGFiaWxpdHkgc3RyaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXh0ZW5zaW9u
IGRlZmluZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQgaXMgInZhcmlhYmxlcyIuDQoNCg0KMy4gIElu
dGVycHJldGF0aW9uIG9mIHN0cmluZ3MNCg0KICAgVGhpcyBleHRlbnNpb24gY2hhbmdlcyB0aGUg
c2VtYW50aWNzIG9mIHF1b3RlZC1zdHJpbmcsIG11bHRpLWxpbmUtDQogICBsaXRlcmFsIGFuZCBt
dWx0aS1saW5lLWRvdHN0dWZmIGZvdW5kIGluIFtTSUVWRV0gdG8gZW5hYmxlIHRoZQ0KICAgaW5j
bHVzaW9uIG9mIHRoZSB2YWx1ZSBvZiB2YXJpYWJsZXMuDQoNCiAgIFdoZW4gYSBzdHJpbmcgaXMg
ZXZhbHVhdGVkLCBzdWJzdHJpbmdzIG1hdGNoaW5nIHZhcmlhYmxlLXJlZiBTSEFMTCBiZQ0KICAg
cmVwbGFjZWQgYnkgdGhlIHZhbHVlIG9mIHZhcmlhYmxlLW5hbWUuICBPbmx5IG9uZSBwYXNzIHRo
cm91Z2ggdGhlDQogICBzdHJpbmcgU0hBTEwgYmUgZG9uZS4gIFZhcmlhYmxlIG5hbWVzIGFyZSBj
YXNlIGluc2Vuc2l0aXZlLCBzbyAiZm9vIg0KICAgYW5kICJGT08iIHJlZmVyIHRvIHRoZSBzYW1l
IHZhcmlhYmxlLiAgVW5rbm93biB2YXJpYWJsZXMgYXJlIHJlcGxhY2VkDQogICBieSB0aGUgZW1w
dHkgc3RyaW5nLg0KDQogICAgICB2YXJpYWJsZS1yZWYgICAgICAgID0gICIkeyIgdmFyaWFibGUt
bmFtZSAifSINCiAgICAgIHZhcmlhYmxlLW5hbWUgICAgICAgPSAgbnVtLXZhcmlhYmxlIC8gKm5h
bWVzcGFjZSBpZGVudGlmaWVyDQogICAgICBuYW1lc3BhY2UgICAgICAgICAgID0gIGlkZW50aWZp
ZXIgIi4iDQogICAgICBudW0tdmFyaWFibGUgICAgICAgID0gIDEqRElHSVQNCg0KICAgRXhhbXBs
ZXM6DQogICAgICAiJiUke30hIiAgICAgPT4gdW5jaGFuZ2VkLCBhcyB0aGUgZW1wdHkgc3RyaW5n
IGlzIGFuIGlsbGVnYWwNCiAgICAgICAgICAgICAgICAgICAgICBpZGVudGlmaWVyDQogICAgICAi
JHtkb2ghfSIgICAgPT4gdW5jaGFuZ2VkLCBhcyAiISIgaXMgaWxsZWdhbCBpbiBpZGVudGlmaWVy
cw0KDQogICAgICBUaGUgdmFyaWFibGUgY29tcGFueSBob2xkcyB0aGUgdmFsdWUgIkFDTUUiLiAg
Tm8gb3RoZXIgdmFyaWFibGVzDQogICAgICBhcmUgc2V0Lg0KDQogICAgICAiJHtmdWxsfSIgICAg
ID0+IHRoZSBlbXB0eSBzdHJpbmcNCiAgICAgICIke2NvbXBhbnl9IiAgPT4gIkFDTUUiDQogICAg
ICAiJHtQcmVzaWRlbnQsICR7Q29tcGFueX0gSW5jLn0iDQogICAgICAgICAgICAgICAgICAgID0+
ICIke1ByZXNpZGVudCwgQUNNRSBJbmMufSINCiAgICAgICIke0JBRCR7Q29tcGFueX0iPT4iJHtC
QURBQ01FIg0KDQogICBUaGUgZXhwYW5kZWQgc3RyaW5nIE1VU1QgdXNlIHRoZSB2YXJpYWJsZSB2
YWx1ZXMgd2hpY2ggYXJlIGN1cnJlbnQNCiAgIHdoZW4gY29udHJvbCByZWFjaGVzIHRoZSBzdGF0
ZW1lbnQgdGhlIHN0cmluZyBpcyBwYXJ0IG9mLg0KDQogICBTdHJpbmdzIHdoZXJlIG5vIHZhcmlh
YmxlIHN1YnN0aXR1dGlvbnMgdGFrZSBwbGFjZSBhcmUgcmVmZXJyZWQgdG8gYXMNCiAgIGNvbnN0
YW50IHN0cmluZ3MuICBGdXR1cmUgZXh0ZW5zaW9ucyBtYXkgc3BlY2lmeSB0aGF0IHBhc3Npbmcg
bm9uLQ0KICAgY29uc3RhbnQgc3RyaW5ncyBhcyBhcmd1bWVudHMgdG8gaXRzIGFjdGlvbnMgb3Ig
dGVzdHMgaXMgYW4gZXJyb3IuDQoNCiAgIE5hbWVzcGFjZXMgYXJlIG1lYW50IGZvciBmdXR1cmUg
ZXh0ZW5zaW9ucyB3aGljaCBtYWtlIGludGVybmFsIHN0YXRlDQogICBhdmFpbGFibGUgdGhyb3Vn
aCB2YXJpYWJsZXMuICBUaGVzZSB2YXJpYWJsZXMgU0hPVUxEIGJlIHB1dCBpbiBhDQogICBuYW1l
c3BhY2Ugd2l0aCB0aGUgc2FtZSBuYW1lIGFzIGl0cyBjYXBhYmlsaXR5IHN0cmluZy4gIE5vdGlj
ZSB0aGF0DQogICB0aGUgdXNlciBjYW4gbm90IHNwZWNpZnkgYSBuYW1lc3BhY2Ugd2hlbiBzZXR0
aW5nIHZhcmlhYmxlcyB3aXRoIFNFVC4NCg0KDQoNCkhvbW1lICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJu
ZXQgRHJhZnQgICAgICAgIFNpZXZlIC0tIFZhcmlhYmxlcyBFeHRlbnNpb24gICAgICAgICAgICAz
IEZlYiAyMDA1DQoNCg0KICAgVGVzdHMgb3IgYWN0aW9ucyBpbiBmdXR1cmUgZXh0ZW5zaW9ucyBt
YXkgbmVlZCB0byBhY2Nlc3MgdGhlDQogICB1bmV4cGFuZGVkIHZlcnNpb24gb2YgdGhlIHN0cmlu
ZyBhcmd1bWVudCBhbmQsIGUuZy4sIGRvIHRoZSBleHBhbnNpb24NCiAgIGFmdGVyIHNldHRpbmcg
dmFyaWFibGVzIGluIGl0cyBuYW1lc3BhY2UuICBUaGUgZGVzaWduIG9mIHRoZQ0KICAgaW1wbGVt
ZW50YXRpb24gc2hvdWxkIGFsbG93IHRoaXMuDQoNCg0KMy4xLiAgUXVvdGluZw0KDQogICBUaGUg
c2VtYW50aWNzIG9mIHF1b3RpbmcgdXNpbmcgYmFja3NsYXNoIGFyZSBub3QgY2hhbmdlZDogYmFj
a3NsYXNoDQogICBxdW90aW5nIGlzIHJlc29sdmVkIGJlZm9yZSBkb2luZyB2YXJpYWJsZSBzdWJz
dGl0dXRpb24uDQoNCiAgIEV4YW1wbGVzOg0KICAgICAgIiR7Zm9cb30iICA9PiAke2Zvb30gID0+
IHRoZSBleHBhbnNpb24gb2YgdmFyaWFibGUgZm9vLg0KICAgICAgIiR7Zm9cXG99IiA9PiAke2Zv
XG99ID0+IGlsbGVnYWwgaWRlbnRpZmllciA9PiBsZWZ0IHZlcmJhdGltLg0KICAgICAgIlwke2Zv
b30iICA9PiAke2Zvb30gID0+IHRoZSBleHBhbnNpb24gb2YgdmFyaWFibGUgZm9vLg0KICAgICAg
IlxcJHtmb299IiA9PiBcJHtmb299ID0+IGEgYmFja3NsYXNoIGNoYXJhY3RlciBmb2xsb3dlZCBi
eSB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHBhbnNpb24gb2YgdmFyaWFi
bGUgZm9vLg0KDQogICBJZiBpdCBpcyByZXF1aXJlZCB0byBpbmNsdWRlIGEgY2hhcmFjdGVyIHNl
cXVlbmNlIHN1Y2ggYXMgIiR7YmVlcH0iDQogICB2ZXJiYXRpbSBpbiBhIHRleHQgbGl0ZXJhbCwg
dGhlIHVzZXIgY2FuIGRlZmluZSBhIHZhcmlhYmxlIHRvDQogICBjaXJjdW12ZW50IGV4cGFuc2lv
biB0byB0aGUgZW1wdHkgc3RyaW5nLg0KDQogICBFeGFtcGxlOg0KICAgICAgc2V0ICJkb2xsYXIi
ICIkIjsNCiAgICAgIHNldCAidGV4dCIgInJlZ2FyZGluZyAke2RvbGxhcn17YmVlcH0iOw0KDQoN
CjMuMi4gIE51bWJlcmVkIHZhcmlhYmxlcw0KDQogICBUaGUgZGVjaW1hbCB2YWx1ZSBvZiB0aGUg
bnVtYmVyZWQgdmFyaWFibGUgbmFtZSB3aWxsIGluZGV4IHRoZSBsaXN0DQogICBvZiBtYXRjaGlu
ZyBzdHJpbmdzIGZyb20gdGhlIG1vc3QgcmVjZW50bHkgZXZhbHVhdGVkIHN1Y2Nlc3NmdWwgbWF0
Y2gNCiAgIG9mIHR5cGUgIjptYXRjaGVzIiBvciAiOnJlZ2V4IiAoc2VlIFtSRUdFWF0pLiAgVGhl
IGxpc3QgaXMgZW1wdHkgaWYNCiAgIG5vIG1hdGNoIGhhcyBiZWVuIHN1Y2Nlc3NmdWwuDQoNCiAg
IEZvciAiOm1hdGNoZXMiLCB0aGUgbGlzdCB3aWxsIGNvbnRhaW4gb25lIHN0cmluZyBmb3IgZWFj
aCB3aWxkY2FyZA0KICAgKCI/IiBhbmQgIioiKSBpbiB0aGUgbWF0Y2ggcGF0dGVybi4gIEVhY2gg
c3RyaW5nIGhvbGRzIHdoYXQgdGhlDQogICBjb3JyZXNwb25kaW5nIHdpbGRjYXJkIGV4cGFuZHMg
dG8sIHBvc3NpYmx5IHRoZSBlbXB0eSBzdHJpbmcuICBUaGUNCiAgIHdpbGRjYXJkcyBtYXRjaCBh
cyBsaXR0bGUgYXMgcG9zc2libGUgKG5vbi1ncmVlZHkgbWF0Y2hpbmcpLg0KDQogICBGb3IgIjpy
ZWdleCIsIHRoZSBsaXN0IHdpbGwgY29udGFpbiB0aGUgc3RyaW5ncyBjb3JyZXNwb25kaW5nIHRv
IHRoZQ0KICAgZ3JvdXAgb3BlcmF0b3JzLiAgVGhlIGdyb3VwcyBhcmUgb3JkZXJlZCBieSB0aGUg
cG9zaXRpb24gb2YgdGhlDQogICBvcGVuaW5nIHBhcmVudGhlc2lzLCBmcm9tIGxlZnQgdG8gcmln
aHQuICBOb3RlIHRoYXQgaW4gcmVndWxhcg0KICAgZXhwcmVzc2lvbnMsIGV4cGFuc2lvbnMgbWF0
Y2ggYXMgbXVjaCBhcyBwb3NzaWJsZSAoZ3JlZWR5IG1hdGNoaW5nKS4NCg0KICAgVGhlIGZpcnN0
IHN0cmluZyBpbiB0aGUgbGlzdCBoYXMgaW5kZXggMS4gIElmIHRoZSBpbmRleCBpcyBvdXQgb2YN
CiAgIHJhbmdlLCB0aGUgZW1wdHkgc3RyaW5nIHdpbGwgYmUgc3Vic3RpdHV0ZWQuICBJbmRleCAw
IHJldHVybnMgdGhlDQogICBudW1iZXIgb2Ygc3RyaW5ncyBpbiB0aGUgbGlzdCBhcyBhIGRlY2lt
YWwgbnVtYmVyLg0KDQoNCg0KDQpIb21tZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0IERyYWZ0ICAg
ICAgICBTaWV2ZSAtLSBWYXJpYWJsZXMgRXh0ZW5zaW9uICAgICAgICAgICAgMyBGZWIgMjAwNQ0K
DQoNCiAgIFRoZSBpbnRlcnByZXRlciBNVVNUIHNob3J0LWNpcmN1aXQgdGVzdHMsIGllLiBub3Qg
cGVyZm9ybSBtb3JlIHRlc3RzDQogICB0aGFuIG5lY2Vzc2FyeSB0byBmaW5kIHRoZSByZXN1bHQu
ICBFdmFsdWF0aW9uIG9yZGVyIE1VU1QgYmUgbGVmdCB0bw0KICAgcmlnaHQuICBJZiBhIHRlc3Qg
aGFzIHR3byBvciBtb3JlIGxpc3QgYXJndW1lbnRzLCB0aGUgaW1wbGVtZW50YXRpb24NCiAgIGlz
IGZyZWUgdG8gY2hvb3NlIHdoaWNoIHRvIGl0ZXJhdGUgb3ZlciBmaXJzdC4NCg0KICAgRXhhbXBs
ZToNCg0KICAgICAgcmVxdWlyZSBbICJmaWxlaW50byIsICJyZWdleCIsICJ2YXJpYWJsZXMiIF07
DQoNCiAgICAgIGlmIGhlYWRlciA6cmVnZXggIkxpc3QtSUQiICI8KC4qKUAiIHsNCiAgICAgICAg
ICBmaWxlaW50byAibGlzdHMuJHsxfSI7IHN0b3A7DQogICAgICB9DQoNCiAgICAgICMgVGhpcyB1
c3VhbGx5IGdpdmVzIHRoZSBzYW1lIHJlc3VsdCBhcyB0aGUgYWJvdmUNCiAgICAgIGlmIGhlYWRl
ciA6bWF0Y2hlcyAiTGlzdC1JRCIgIio8KkAqIiB7DQogICAgICAgICAgZmlsZWludG8gImxpc3Rz
LiR7Mn0iOyBzdG9wOw0KICAgICAgfQ0KDQogICAgICAjIEltYWdpbmUgdGhlIGhlYWRlcg0KICAg
ICAgIyBTdWJqZWN0OiBbYWNtZS11c2Vyc10gW2Z3ZF0gdmVyc2lvbiAxLjAgaXMgb3V0DQogICAg
ICBpZiBoZWFkZXIgOnJlZ2V4ICJTdWJqZWN0IiAiXlsoLiopXSAoLiopJCIgew0KICAgICAgICAg
ICMgJHsxfSB3aWxsIGhvbGQgImFjbWUtdXNlcnNdIFtmd2QiDQogICAgICB9DQogICAgICBpZiBo
ZWFkZXIgOm1hdGNoZXMgIlN1YmplY3QiICJbKl0gKiIgew0KICAgICAgICAgICMgJHsxfSB3aWxs
IGhvbGQgImFjbWUtdXNlcnMiLA0KICAgICAgICAgICMgJHsyfSB3aWxsIGhvbGQgIltmd2RdIHZl
cnNpb24gMS4wIGlzIG91dCINCiAgICAgICAgICBmaWxlaW5mbyAibGlzdHMuJHsxfSI7IHN0b3A7
DQogICAgICB9DQoNCiAgICAgIGlmIGFkZHJlc3MgOm1hdGNoZXMgWyAiVG8iLCAiQ2MiIF0gImNv
eW90ZUAqKi5jb20iIHsNCiAgICAgICAgICAjICR7MH0gaXMgYWx3YXlzICIyIiwgYW5kICR7MX0g
aXMgYWx3YXlzIHRoZSBlbXB0eSBzdHJpbmcuDQogICAgICAgICAgZmlsZWludG8gImJ1c2luZXNz
LiR7Mn0iOyBzdG9wOw0KICAgICAgfSBlbHNlIHsNCiAgICAgICAgICAjIENvbnRyb2wgY2FuJ3Qg
cmVhY2ggdGhpcyBibG9jayBpZiBhbnkgbWF0Y2ggd2FzDQogICAgICAgICAgIyBzdWNjZXNzZnVs
LCBzbyAkezB9IGlzIGFsd2F5cyAiMCIgaGVyZS4NCiAgICAgIH0NCg0KICAgICAgaWYgYW55b2Yg
KHRydWUsIGFkZHJlc3MgOmRvbWFpbiA6bWF0Y2hlcyAiVG8iICIqLmNvbSIpIHsNCiAgICAgICAg
ICAjIFNlY29uZCB0ZXN0IGlzIG5ldmVyIGV2YWx1YXRlZCwgc28gJHswfSBpcyBzdGlsbCAiMCIN
CiAgICAgICAgICBzdG9wOw0KICAgICAgfQ0KDQoNCjQuICBBY3Rpb24gc2V0DQoNCiAgIFN5bnRh
eDogICBzZXQgW01PRElGSUVSXSBbQ09NUEFSQVRPUl0gPG5hbWU6IHN0cmluZz4gPHZhbHVlOiBz
dHJpbmc+DQoNCiAgIFRoZSAic2V0IiBhY3Rpb24gc3RvcmVzIHRoZSBzcGVjaWZpZWQgdmFsdWUg
aW4gdGhlIHZhcmlhYmxlDQoNCg0KDQpIb21tZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0IERyYWZ0
ICAgICAgICBTaWV2ZSAtLSBWYXJpYWJsZXMgRXh0ZW5zaW9uICAgICAgICAgICAgMyBGZWIgMjAw
NQ0KDQoNCiAgIGlkZW50aWZpZWQgYnkgbmFtZS4gIFRoZSBuYW1lIE1VU1QgYmUgYSBjb25zdGFu
dCBzdHJpbmcgYW5kIGNvbmZvcm0NCiAgIHRvIHRoZSBzeW50YXggb2YgaWRlbnRpZmllci4gIEFu
IGlsbGVnYWwgbmFtZSBNVVNUIGNhdXNlIGEgc3ludGF4DQogICBlcnJvci4NCg0KICAgTW9kaWZp
ZXJzIGFyZSBhcHBsaWVkIG9uIGEgdmFsdWUgYmVmb3JlIGl0IGlzIHN0b3JlZCBpbiB0aGUgdmFy
aWFibGUuDQogICBTZWUgbmV4dCBzZWN0aW9uIGZvciBkZXRhaWxzLg0KDQogICBUaGUgZGVmYXVs
dCBjb21wYXJhdG9yIGlzICJpO2FzY2lpLWNhc2VtYXAiLiAgVGhlIGNvbXBhcmF0b3Igb25seQ0K
ICAgYWZmZWN0cyB0aGUgcmVzdWx0IHdoZW4gY2VydGFpbiBtb2RpZmllcnMgYXJlIHVzZWQuDQoN
CiAgIEFsbCB2YXJpYWJsZXMgaGF2ZSBnbG9iYWwgc2NvcGU6IHRoZXkgYXJlIHZpc2libGUgdW50
aWwgcHJvY2Vzc2luZw0KICAgc3RvcHMuICBWYXJpYWJsZSBuYW1lcyBhcmUgY2FzZSBpbnNlbnNp
dGl2ZS4NCg0KICAgRXhhbXBsZToNCiAgICAgIHNldCAiaG9ub3JpZmljIiAgIk1yIjsNCiAgICAg
IHNldCAiZmlyc3RfbmFtZSIgIldpbGUiOw0KICAgICAgc2V0ICJsYXN0X25hbWUiICAiQ295b3Rl
IjsNCiAgICAgIHNldCAidmFjYXRpb24iIHRleHQ6DQogICAgICBEZWFyICR7SE9OT1JJRklDfSAk
e2xhc3RfbmFtZX0sDQogICAgICBJJ20gb3V0LCBwbGVhc2UgbGVhdmUgYSBtZXNzYWdlIGFmdGVy
IHRoZSBtZWVwLg0KICAgICAgLg0KICAgICAgOw0KDQogICAic2V0IiBkb2VzIG5vdCBhZmZlY3Qg
dGhlIGltcGxpY2l0IGtlZXAuDQoNCg0KNC4xLiAgTW9kaWZpZXJzDQoNClN5bnRheDogICAiOmxv
d2VyIiAvICI6dXBwZXIiIC8gIjpsb3dlcmZpcnN0IiAvICI6dXBwZXJmaXJzdCIgLw0KICAgIjps
ZW5ndGgiDQoNCiAgIE1vZGlmaWVyIG5hbWVzIGFyZSBjYXNlIGluc2Vuc2l0aXZlLiAgVW5rbm93
biBtb2RpZmllcnMgTVVTVCB5aWVsZCBhDQogICBzeW50YXggZXJyb3IuICBNb3JlIHRoYW4gb25l
IG1vZGlmaWVyIGNhbiBiZSBzcGVjaWZpZWQsIGluIHdoaWNoIGNhc2UNCiAgIHRoZXkgYXJlIGFw
cGxpZWQgYWNjb3JkaW5nIHRvIHRoaXMgcHJlY2VkZW5jZSBsaXN0LCBoaWdoZXN0IHZhbHVlDQog
ICBmaXJzdDoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSG9tbWUgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhd
DQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgU2lldmUgLS0gVmFyaWFibGVzIEV4dGVuc2lvbiAg
ICAgICAgICAgIDMgRmViIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIHwgUHJlY2VkZW5j
ZSAgICAgTW9kaWZpZXIgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgfCAgICAgMyAgICAgICAg
ICA6bG93ZXIgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
OnVwcGVyICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgfCAgICAgMiAgICAgICAgICA6bG93
ZXJmaXJzdCAgfA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgOnVwcGVy
Zmlyc3QgIHwNCiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgfCAgICAgMSAgICAgICAgICA6bGVuZ3RoICAg
ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSsNCg0KICAgSWYgdHdvIG9yIG1vcmUgbW9kaWZpZXJzIG9mIHRoZSBzYW1lIHByZWNlZGVuY2Ug
YXJlIHVzZWQsIHRoZXkgY2FuIGJlDQogICBhcHBsaWVkIGluIGFueSBvcmRlci4NCg0KICAgRXhh
bXBsZXM6DQogICAgICBzZXQgImEiICJqdU1CbEVkIGxFVHRlUlMiOyAgICAgICAgICAgICA9PiAi
anVNQmxFZCBsRVR0ZVJTIg0KICAgICAgc2V0IDpsZW5ndGggImIiICIke2F9IjsgICAgICAgICAg
ICAgICAgPT4gIjE1Ig0KICAgICAgc2V0IDpsb3dlciAiYiIgIiR7YX0iOyAgICAgICAgICAgICAg
ICAgPT4gImp1bWJsZWQgbGV0dGVycyINCiAgICAgIHNldCA6dXBwZXJmaXJzdCAiYiIgIiR7YX0i
OyAgICAgICAgICAgID0+ICJKdU1CbEVkIGxFVHRlUlMiDQogICAgICBzZXQgOnVwcGVyZmlyc3Qg
Omxvd2VyICJiIiAiJHthfSI7ICAgICA9PiAiSnVtYmxlZCBsZXR0ZXJzIg0KDQoNCjQuMS4xLiAg
TW9kaWZpZXIgIjpsZW5ndGgiDQoNCiAgIFRoZSB2YWx1ZSBpcyB0aGUgZGVjaW1hbCBudW1iZXIg
b2YgY2hhcmFjdGVycyBpbiB0aGUgZXhwYW5zaW9uLA0KICAgY29udmVydGVkIHRvIGEgc3RyaW5n
Lg0KDQoNCjQuMS4yLiAgQ2FzZSBtb2RpZmllcnMNCg0KICAgVGhlc2UgbW9kaWZpZXJzIGNoYW5n
ZSB0aGUgbGV0dGVycyBvZiB0aGUgdGV4dCBmcm9tIHVwcGVyIHRvIGxvd2VyDQogICBjYXNlIG9y
IHZpY2UgdmVyc2EuICBUaGUgaW1wbGVtZW50YXRpb24gTVVTVCBzdXBwb3J0IFVTLUFTQ0lJLCBi
dXQgaXMNCiAgIG5vdCByZXF1aXJlZCB0byBoYW5kbGUgdGhlIGVudGlyZSBVbmljb2RlIHJlcGVy
dG9pcmUuICBUaGUgY29tcGFyYXRvcg0KICAgc3BlY2lmaWVkIFNIT1VMRCBiZSBjb25zdWx0ZWQg
dG8gZXN0YWJsaXNoIHdoaWNoIGxvY2FsZSB0byB1c2UuDQoNCg0KNC4xLjIuMS4gIE1vZGlmaWVy
ICI6dXBwZXIiDQoNCiAgIEFsbCBsb3dlciBjYXNlIGxldHRlcnMgYXJlIGNvbnZlcnRlZCB0byB0
aGVpciB1cHBlciBjYXNlIGNvdW50ZXJwYXJ0Lg0KDQoNCjQuMS4yLjIuICBNb2RpZmllciAiOmxv
d2VyIg0KDQogICBBbGwgdXBwZXIgY2FzZSBsZXR0ZXJzIGFyZSBjb252ZXJ0ZWQgdG8gdGhlaXIg
bG93ZXIgY2FzZSBjb3VudGVycGFydC4NCg0KDQoNCg0KDQoNCkhvbW1lICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0K
SW50ZXJuZXQgRHJhZnQgICAgICAgIFNpZXZlIC0tIFZhcmlhYmxlcyBFeHRlbnNpb24gICAgICAg
ICAgICAzIEZlYiAyMDA1DQoNCg0KNC4xLjIuMy4gIE1vZGlmaWVyICI6dXBwZXJmaXJzdCINCg0K
ICAgVGhlIGZpcnN0IGNoYXJhY3RlciBvZiB0aGUgc3RyaW5nIGlzIGNvbnZlcnRlZCB0byB1cHBl
ciBjYXNlIGlmIGl0IGlzDQogICBhIGxldHRlciBhbmQgc2V0IGluIGxvd2VyIGNhc2UuICBUaGUg
cmVzdCBvZiB0aGUgc3RyaW5nIGlzIGxlZnQNCiAgIHVuY2hhbmdlZC4NCg0KDQo0LjEuMi40LiAg
TW9kaWZpZXIgIjpsb3dlcmZpcnN0Ig0KDQogICBUaGUgZmlyc3QgY2hhcmFjdGVyIG9mIHRoZSBz
dHJpbmcgaXMgY29udmVydGVkIHRvIGxvd2VyIGNhc2UgaWYgaXQgaXMNCiAgIGEgbGV0dGVyIGFu
ZCBzZXQgaW4gdXBwZXIgY2FzZS4gIFRoZSByZXN0IG9mIHRoZSBzdHJpbmcgaXMgbGVmdA0KICAg
dW5jaGFuZ2VkLg0KDQoNCjUuICBUZXN0IHN0cmluZw0KDQogICBTeW50YXg6IHN0cmluZyBbTUFU
Q0gtVFlQRV0gW0NPTVBBUkFUT1JdDQogICAgICAgICAgIDxzb3VyY2U6IHN0cmluZy1saXN0PiA8
a2V5LWxpc3Q6IHN0cmluZy1saXN0Pg0KDQogICBUaGUgInN0cmluZyIgdGVzdCBldmFsdWF0ZXMg
dG8gdHJ1ZSBpZiBhbnkgb2YgdGhlIHNvdXJjZSBzdHJpbmdzDQogICBtYXRjaGVzIGFueSBrZXku
ICBUaGUgdHlwZSBvZiBtYXRjaCBkZWZhdWx0cyB0byAiOmlzIi4NCg0KICAgRXhhbXBsZToNCiAg
ICAgIHNldCAic3RhdGUiICIke3N0YXRlfSBwZW5kaW5nIjsNCiAgICAgIGlmIHN0cmluZyA6bWF0
Y2hlcyAiICR7c3RhdGV9ICIgIiogcGVuZGluZyAqIiB7DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAjIHRoZSBhYm92ZSB0ZXN0IGFsd2F5cyBzdWNjZWVkcw0K
ICAgICAgfQ0KDQogICBUaGUgInJlbGF0aW9uYWwiIGV4dGVuc2lvbiBbUkVMQVRJT05BTF0gYWRk
cyBhIG1hdGNoIHR5cGUgY2FsbGVkDQogICAiOmNvdW50Ii4gIFRoZSBjb3VudCBvZiBhIHNpbmds
ZSBzdHJpbmcgaXMgMCBpZiBpdCBpcyB0aGUgZW1wdHkNCiAgIHN0cmluZywgb3IgMSBvdGhlcndp
c2UuICBUaGUgY291bnQgb2YgYSBzdHJpbmcgbGlzdCBpcyB0aGUgc3VtIG9mIHRoZQ0KICAgY291
bnRzIG9mIHRoZSBtZW1iZXIgc3RyaW5ncy4NCg0KDQo2LiAgSW1wbGVtZW50YXRpb24gTGltaXRz
DQoNCiAgIEFuIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgZHJhZnQgTVVTVCBzdXBwb3J0IGF0IGxl
YXN0IDEyOCBkaXN0aW5jdA0KICAgdmFyaWFibGVzLiAgVGhlIHN1cHBvcnRlZCBsZW5ndGggb2Yg
dmFyaWFibGUgbmFtZXMgTVVTVCBiZSBhdCBsZWFzdA0KICAgMzIgY2hhcmFjdGVycy4gIEVhY2gg
dmFyaWFibGUgTVVTVCBiZSBhYmxlIHRvIGhvbGQgYXQgbGVhc3QgNDAwMA0KICAgY2hhcmFjdGVy
cy4gIEF0dGVtcHRzIHRvIHNldCB0aGUgdmFyaWFibGUgdG8gYSB2YWx1ZSBsYXJnZXIgdGhhbiB3
aGF0DQogICB0aGUgaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgU0hPVUxEIGJlIHJlcG9ydGVkIGFz
IGFuIGVycm9yIGF0DQogICBjb21waWxlLXRpbWUgaWYgcG9zc2libGUuICBJZiB0aGUgYXR0ZW1w
dCBpcyBkaXNjb3ZlcmVkIGR1cmluZyBydW4tDQogICB0aW1lLCB0aGUgdmFsdWUgU0hPVUxEIGJl
IHRydW5jYXRlZCBhbmQgaXQgTVVTVCBOT1QgYmUgdHJlYXRlZCBhcyBhbg0KICAgZXJyb3IuDQoN
CiAgIE51bWJlcmVkIHZhcmlhYmxlcyAkezF9IHRocm91Z2ggJHs5fSBNVVNUIGJlIHN1cHBvcnRl
ZC4gIFJlZmVyZW5jZXMNCiAgIHRvIGhpZ2hlciBpbmRpY2VzIHRoYW4gdGhlIGltcGxlbWVudGF0
aW9uIHN1cHBvcnRzIE1VU1QgYmUgdHJlYXRlZCBhcw0KICAgYSBzeW50YXggZXJyb3Igd2hpY2gg
U0hPVUxEIGJlIGRpc2NvdmVyZWQgYXQgY29tcGlsZS10aW1lLg0KDQoNCg0KSG9tbWUgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug
MTBdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgU2lldmUgLS0gVmFyaWFibGVzIEV4dGVuc2lv
biAgICAgICAgICAgIDMgRmViIDIwMDUNCg0KDQo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN
Cg0KICAgV2hlbiBudW1iZXJlZCB2YXJpYWJsZXMgYXJlIHVzZWQsIGFuZCB0aGUgYXV0aG9yIG9m
IHRoZSBzY3JpcHQgaXNuJ3QNCiAgIGNhcmVmdWwsIHN0cmluZ3MgY2FuIGNvbnRhaW4gYXJiaXRy
YXJ5IHZhbHVlcyBjb250cm9sbGVkIGJ5IHRoZQ0KICAgc2VuZGVyIG9mIHRoZSBlLW1haWwuDQoN
CiAgIFRoZSBpbnRyb2R1Y3Rpb24gb2YgdmFyaWFibGVzIG1ha2VzIGFkdmFuY2VkIGRlY2lzaW9u
IG1ha2luZyBlYXNpZXINCiAgIHRvIHdyaXRlLCBidXQgc2luY2Ugbm8gbG9vcGluZyBjb25zdHJ1
Y3QgaXMgcHJvdmlkZWQsIGFsbCBTaWV2ZQ0KICAgc2NyaXB0cyB3aWxsIHRlcm1pbmF0ZSBpbiBh
biBvcmRlcmx5IG1hbm5lci4NCg0KICAgU2lldmUgZmlsdGVyaW5nIHNob3VsZCBub3QgYmUgcmVs
aWVkIG9uIGFzIGEgc2VjdXJpdHkgbWVhc3VyZSBhZ2FpbnN0DQogICBob3N0aWxlIGUtbWFpbCBt
ZXNzYWdlcy4gIFNpZXZlIGlzIGRlc2lnbmVkIHRvIGRvIHNpbXBsZSwgbW9zdGx5DQogICBzdGF0
aWMgdGVzdHMsIGFuZCBpcyBub3Qgc3VpdGFibGUgZm9yIHVzZSBhcyBhIHNwYW0gb3IgdmlydXMg
Y2hlY2tlciwNCiAgIHdoZXJlIHRoZSBwZXJwZXRyYXRvciBoYXMgYSBtb3RpdmF0aW9uIHRvIHZh
cnkgdGhlIGZvcm1hdCBvZiB0aGUNCiAgIGVtYWlsIGluIG9yZGVyIHRvIGF2b2lkIGZpbHRlcmlu
ZyBydWxlcy4gIFNlZSBhbHNvIFtTUEFNVEVTVF0uDQoNCg0KOC4gIElBTkEgQ29uc2lkZXJhdGlv
bnMNCg0KICAgVGhlIGZvbGxvd2luZyB0ZW1wbGF0ZSBzcGVjaWZpZXMgdGhlIElBTkEgcmVnaXN0
cmF0aW9uIG9mIHRoZQ0KICAgdmFyaWFibGVzIFNpZXZlIGV4dGVuc2lvbiBzcGVjaWZpZWQgaW4g
dGhpcyBkb2N1bWVudDoNCg0KICAgVG86IGlhbmFAaWFuYS5vcmcNCiAgIFN1YmplY3Q6IFJlZ2lz
dHJhdGlvbiBvZiBuZXcgU2lldmUgZXh0ZW5zaW9uDQoNCiAgIENhcGFiaWxpdHkgbmFtZTogdmFy
aWFibGVzDQogICBDYXBhYmlsaXR5IGtleXdvcmQ6IHZhcmlhYmxlcw0KICAgQ2FwYWJpbGl0eSBh
cmd1bWVudHM6IE4vQQ0KICAgU3RhbmRhcmRzIFRyYWNrL0lFU0ctYXBwcm92ZWQgZXhwZXJpbWVu
dGFsIFJGQyBudW1iZXI6IHRoaXMgUkZDDQogICBQZXJzb24gYW5kIGVtYWlsIGFkZHJlc3MgdG8g
Y29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjoNCg0KICAgICAgS2pldGlsIFRvcmdyaW0g
SG9tbWUNCiAgICAgIFVuaXZlcnNpdHkgb2YgT3Nsbw0KICAgICAgUGIgMTA4MCwgQmxpbmRlcm4N
CiAgICAgIE5PLTAzMTYgT1NMTw0KDQogICAgICBFLW1haWw6IGtqZXRpbGhvQGlmaS51aW8ubm8N
Cg0KICAgVGhpcyBpbmZvcm1hdGlvbiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3Qgb2Ygc2ll
dmUgZXh0ZW5zaW9ucw0KICAgZ2l2ZW4gb24gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50
cy9zaWV2ZS1leHRlbnNpb25zLg0KDQo5LiAgQWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoYW5rcyB0
byBKdXR0YSBEZWdlbmVyLCBOZWQgRnJlZWQsIExhd3JlbmNlIEdyZWVuZmllbGQsIE1hcmsgRS4N
CiAgIE1hbGxldHQsIFBlZGVyIFN0cmF5IGFuZCBOaWdlbCBTd2luc29uIGZvciB2YWx1YWJsZSBm
ZWVkYmFjay4NCg0KDQoNCg0KDQoNCkhvbW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQgRHJhZnQg
ICAgICAgIFNpZXZlIC0tIFZhcmlhYmxlcyBFeHRlbnNpb24gICAgICAgICAgICAzIEZlYiAyMDA1
DQoNCg0KMTAuICBBdXRob3IncyBBZGRyZXNzDQoNCiAgIEtqZXRpbCBULiBIb21tZQ0KICAgVW5p
dmVyc2l0eSBvZiBPc2xvDQogICBQTyBCb3ggMTA4MA0KICAgMDMxNiBPc2xvLCBOb3J3YXkNCg0K
ICAgUGhvbmU6ICs0NyA5MzY2IDAwOTENCiAgIEUtbWFpbDoga2pldGlsaG9AaWZpLnVpby5ubw0K
DQoNCkFwcGVuZGl4IEEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQoNCiAgICAgW0FCTkZdICAg
ICAgIENyb2NrZXIsIEQuIGFuZCBPdmVyZWxsLCBQLiwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRh
eA0KICAgICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgMjIzNCwgTm92
ZW1iZXIgMTk5Nw0KDQogICAgIFtLRVlXT1JEU10gICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm
b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50
IExldmVscyIsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICAgIFtSRUxBVElPTkFMXSBTZWdt
dWxsZXIsIFcuLCAiU2lldmUgRXh0ZW5zaW9uOiBSZWxhdGlvbmFsIFRlc3RzIiwNCiAgICAgICAg
ICAgICAgICAgIFJGQyAzNDMxLCBEZWNlbWJlciAyMDAyDQoNCiAgICAgW1NJRVZFXSAgICAgIFNo
b3dhbHRlciwgVC4sICJTaWV2ZTogQSBNYWlsIEZpbHRlcmluZyBMYW5ndWFnZSIsIFJGQw0KICAg
ICAgICAgICAgICAgICAgMzAyOCwgSmFudWFyeSAyMDAxLg0KDQogICAgIFtTUEFNVEVTVF0gICBD
LiBEYWJvbywgIlNJRVZFIEVtYWlsIEZpbHRlcmluZzogU3BhbXRlc3QgYW5kDQogICAgICAgICAg
ICAgICAgICBWaXJ1c1Rlc3QgRXh0ZW5zaW9ucyIsIFJGQyAzNjg1LCBGZWJydWFyeSAyMDA0DQoN
CiAgICAgW1VOSUNPREVdICAgIFRoZSBVbmljb2RlIENvbnNvcnRpdW0sICJUaGUgVW5pY29kZSBT
dGFuZGFyZCAtLQ0KICAgICAgICAgICAgICAgICAgV29ybGR3aWRlIENoYXJhY3RlciBFbmNvZGlu
ZyAtLSBWZXJzaW9uIDEuMCIsIEFkZGlzb24tDQogICAgICAgICAgICAgICAgICBXZXNsZXksIFZv
bHVtZSAxLCAxOTkxLCBWb2x1bWUgMiwgMTk5Mi4NCg0KICAgICBbVVRGLThdICAgICAgWWVyZ2Vh
dSwgRi4sICJVVEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQgb2YNCiAgICAgICAgICAgICAg
ICAgIFVuaWNvZGUgYW5kIElTTyAxMDY0NiIsIFJGQyAyMDQ0LCBPY3RvYmVyIDE5OTYuDQoNCkEu
MSAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQoNCiAgICAgW1JFR0VYXSAgICAgIEsuIE11cmNo
aXNvbiwgIlNpZXZlIEVtYWlsIEZpbHRlcmluZyAtLSBSZWd1bGFyDQogICAgICAgICAgICAgICAg
ICBFeHByZXNzaW9uIEV4dGVuc2lvbiIsIFdvcmsgaW4gUHJvZ3Jlc3MuDQoNCg0KQXBwZW5kaXgg
Qi4gIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgU3RhdGVtZW50DQoNCiAgIFRoZSBJRVRG
IHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55
DQogICBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUg
Y2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRo
ZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KDQoNCg0KSG9tbWUgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRl
cm5ldCBEcmFmdCAgICAgICAgU2lldmUgLS0gVmFyaWFibGVzIEV4dGVuc2lvbiAgICAgICAgICAg
IDMgRmViIDIwMDUNCg0KDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2gg
YW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBh
dmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdA0KICAgaGFzIG1hZGUg
YW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbiBvbiB0
aGUNCiAgIElFVEYncyBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRh
cmRzLXRyYWNrIGFuZA0KICAgc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlvbiBjYW4gYmUg
Zm91bmQgaW4gQkNQLTExLiAgQ29waWVzIG9mDQogICBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZh
aWxhYmxlIGZvciBwdWJsaWNhdGlvbiBhbmQgYW55IGFzc3VyYW5jZXMgb2YNCiAgIGxpY2Vuc2Vz
IHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIGF0dGVtcHQgbWFkZSB0
bw0KICAgb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ug
b2Ygc3VjaA0KICAgcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudG9ycyBvciB1c2VycyBv
ZiB0aGlzIHNwZWNpZmljYXRpb24gY2FuDQogICBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIFNl
Y3JldGFyaWF0Lg0KDQoNCkFwcGVuZGl4IEMuICBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0K
ICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNCkuDQoNCiAgIFRoaXMg
ZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rp
b25zDQogICBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVy
ZWluLCB0aGUgYXV0aG9ycw0KICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCiAgIFRoaXMg
ZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRl
ZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5J
WkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSks
IFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRB
U0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAg
IElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBP
RiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRT
IE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkN
Cg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBv
ciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIg
cmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVt
ZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBk
b2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmln
aHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXBy
ZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVu
dGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIElFVEYncyBwcm9j
ZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gSUVURiBEb2N1bWVudHMgY2FuDQogICBi
ZSBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9z
dXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMg
b2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAg
IGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBm
b3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJz
IG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20g
dGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJp
bmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCg0KDQoNCkhvbW1lICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSW50ZXJu
ZXQgRHJhZnQgICAgICAgIFNpZXZlIC0tIFZhcmlhYmxlcyBFeHRlbnNpb24gICAgICAgICAgICAz
IEZlYiAyMDA1DQoNCg0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRp
b25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hu
b2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJk
LiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0IGlldGYtDQog
ICBpcHJAaWV0Zi5vcmcuDQoNCg0KQWNrbm93bGVkZ2VtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRo
ZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIElu
dGVybmV0IFNvY2lldHkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSG9tbWUgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTRd
DQo=


--=-Ze05xgmdDdl5uJ7MBCLh--



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 j14DjRkS057656; Fri, 4 Feb 2005 05:45:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14DjRaa057655; Fri, 4 Feb 2005 05:45:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Dj8sT057634 for <[e-mail]>; Fri, 4 Feb 2005 05:45:25 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (scotty.rockliffe.com [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Fri, 4 Feb 2005 05:45:02 -0800
Message-ID: <000a01c50abf$b9c0f8b0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Fri, 4 Feb 2005 13:45:00 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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>

> I'm a fan of associative arrays, having first used them in the Sail quite 
> some
> time ago. (Anyone else remember Sail?) However, I have to say I think
> associative arrays would be serious overkill for sieve. Yes, I realize 
> they're
> powerful, but they introduce significant language and implementation
> complexity.

It's really only read only associative arrays I was proposing, so that 
eliminates a large amount of complexity.  If read-only associative arrays 
are overkill for Sieve then how best can we support authoring of simple 
messages based on the content of the inbound mail?  Do you/we favour the 
$subject$ approach?  I guess I would accept some implementation complexity 
if it means the language is easier to use....

Nigel 



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 j14D2bdd042005; Fri, 4 Feb 2005 05:02:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14D2bgH042004; Fri, 4 Feb 2005 05:02:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14D2R5l041687 for <[e-mail]>; Fri, 4 Feb 2005 05:02:31 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.32.202]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Fri, 4 Feb 2005 05:01:50 -0800
Message-ID: <006601c50ab9$b1ed3eb0$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>
Cc: "IETF MTA Filters List" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: spamtestbis
Date: Fri, 4 Feb 2005 13:01:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j14D2V5l041953
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>

> > FYI the draft for the new version of the spamtest extension is now
> > available. The only change between this and the current RFC is the addition
> > of a :percent argument to the spamtest test to allow for a numeric range of
> > 0 - 100. The value -1 is used to indicate a message that was not
> > categorised in anyway.

I'm surprised we need a percentage spam score... I would have thought 10 levels was enough.  Indeed in your example you use level 30(%) = 3.
 
> First, I don't think the -1 is a good idea because of how it interacts with
> numeric comparators. I'd much rather retain 0 as the value indicating no test
> was done. 

I agree.  I think many existing scripts will test for 0 as a way of finding out if the message was scanned, so why risk breaking them?  Personally I don't mind if "message is clear of spam" = 1%.  It's not really an exact science anyway...

Nigel



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 j13MQbsv058688; Thu, 3 Feb 2005 14:26:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MQbEL058687; Thu, 3 Feb 2005 14:26:37 -0800 (PST)
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 j13MQWgg058677 for <[e-mail]>; Thu, 3 Feb 2005 14:26:32 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 03 Feb 2005 14:26:28 -0800 (PST)
Cc: IETF MTA Filters List <[e-mail]>
Date: Thu, 03 Feb 2005 14:08:56 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Thu, 03 Feb 2005 16:14:34 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: spamtestbis
To: Cyrus Daboo <[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>

> FYI the draft for the new version of the spamtest extension is now
> available. The only change between this and the current RFC is the addition
> of a :percent argument to the spamtest test to allow for a numeric range of
> 0 - 100. The value -1 is used to indicate a message that was not
> categorised in anyway.

First, I don't think the -1 is a good idea because of how it interacts with
numeric comparators. I'd much rather retain 0 as the value indicating no test
was done. 

The only other issue I see with the draft is the business of making require
"spamtest" and require "spamtestpercent" mutually exclusive. I certainly
agree that we want require "spamtestpercent" to subsume require "spamtest" -
- require lists in sieve can be really long - but I wonder if making
them mutually exclusive goes too far.

Additionally, one thing that isn't entirely clear with the current text is that
the following is legal:

   require "spamtest"; if spamtest :contains "foo" ...

That is, spamtest without a :percent is allowed when require "spamtestpercent"
is used. I think this should be clarified.

				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 j13LEecB051541; Thu, 3 Feb 2005 13:14:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13LEeQD051540; Thu, 3 Feb 2005 13:14:40 -0800 (PST)
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 j13LEb1H051524 for <[e-mail]>; Thu, 3 Feb 2005 13:14:40 -0800 (PST) (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 j13L7G6E032376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 3 Feb 2005 16:07:18 -0500
Date: Thu, 03 Feb 2005 16:14:34 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: spamtestbis
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a4 (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>

FYI the draft for the new version of the spamtest extension is now 
available. The only change between this and the current RFC is the addition 
of a :percent argument to the spamtest test to allow for a numeric range of 
0 - 100. The value -1 is used to indicate a message that was not 
categorised in anyway.

-- 
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 j13KvpZO050200; Thu, 3 Feb 2005 12:57:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13Kvpqw050199; Thu, 3 Feb 2005 12:57:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KvpS5050192 for <[e-mail]>; Thu, 3 Feb 2005 12:57:51 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08016; Thu, 3 Feb 2005 15:57:48 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-spamtestbis-00.txt
Date: Thu, 03 Feb 2005 15:57:48 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: SIEVE Email Filtering: Spamtest and Virustest Extensions
	Author(s)	: C. Daboo
	Filename	: draft-ietf-sieve-spamtestbis-00.txt
	Pages		: 10
	Date		: 2005-2-3
	
The SIEVE email filtering language "spamtest", "spamtestpercent" and
   "virustest" extensions permit users to use simple, portable commands
   for spam and virus tests on email messages.  Each extension provides
   a new test using matches against numeric 'scores'.  It is the
   responsibility of the underlying SIEVE implementation to do the
   actual checks that result in values returned by the tests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-spamtestbis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-spamtestbis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-spamtestbis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-spamtestbis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




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 j12Mkk45013366; Wed, 2 Feb 2005 14:46:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12MkklB013365; Wed, 2 Feb 2005 14:46:46 -0800 (PST)
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 j12Mkjr6013355 for <[e-mail]>; Wed, 2 Feb 2005 14:46:46 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=Windows-1252
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 02 Feb 2005 14:46:42 -0800 (PST)
Cc: [e-mail]
Date: Wed, 02 Feb 2005 14:42:32 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Wed, 02 Feb 2005 02:21:49 +0000" <015501c508cd$f508ce00$6501a8c0@nigelhome>
Message-id: <[e-mail]>
References: <015501c508cd$f508ce00$6501a8c0@nigelhome>
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[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>

> I wonder if it would make sense for us to add associative arrays containing
> entries of specific interest to the sieve script author.  So for example a
> $HEADERS array which contained all the header values.  So suppose my headers
> were:

I'm a fan of associative arrays, having first used them in the Sail quite some
time ago. (Anyone else remember Sail?) However, I have to say I think
associative arrays would be serious overkill for sieve. Yes, I realize they're
powerful, but they introduce significant language and implementation
complexity.

				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 j122Ltgt078074; Tue, 1 Feb 2005 18:21:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122LtYa078073; Tue, 1 Feb 2005 18:21:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122LtJL078064 for <[e-mail]>; Tue, 1 Feb 2005 18:21:55 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.209]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 1 Feb 2005 18:21:50 -0800
Message-ID: <015501c508cd$f508ce00$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Subject: Sieve-Notify and potential associative arrays.
Date: Wed, 2 Feb 2005 02:21:49 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j122LtJL078068
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>

Looking at the long since expired Sieve Notify extension, it seems somewhat ugly adjacent to the much newer variables extension, and I would suggest needs a lot of work.  I've had a number of thoughts on the subject, some of which may have an impact on the variables extension, although they are possibly sufficiently separate that they would make an extension on their own.

It seems to me that the notify extension is trying to do too much in supporting notification by email, SMS or indeed any arbitrary notification mechanism.  It was pointed out quickly how many complex internationalization issues you have to deal with when composing emails, but you have completely different concerns when dealing with SMS messages, so I'm not sure it makes sense to bundle them.  I think we should therefore have something more along these lines:

Syntax:   sms [":recipient" <recipient-numbers: string-list>] [:limit <number>] <message: string>

The :recipient tag specifies the target phone numbers to send this SMS to.  If not present, the implementation should try to send the SMS to the owner of the script where the number is held by the sieve implementation, ie a mailbox property.  If present, specifies the target number, and it can also be a list of numbers if more than one recipient is desired.  Each phone number must begin with a + and include the country code to ensure that the script will work regardless of location of server/script.

The message is a string, whereby variable expansion is also permitted. The limit is the maximum number of SMS messages that the server can send.  Given that each message typically has a cost associated with it, the limit by default will be whatever produces the least cost which in today’s terms is 1 message (140 bytes) but may change in the future.  They can use this optional tagged argument to override this such that they will receive a multipart SMS containing more content.  Although to be honest I'm not sure how multipart SMS messages work, but I did find a reference detailing that the standard is 140 bytes http://en.wikipedia.org/wiki/Short_message_service#Technical_details.

Messages are of course therefore in UTF8 and again I'm not sure how you do internationalization in SMS but it does appear to be possible.  If we have our UTF8 message and our limit of the number of SMS messages we need to send, then that hopefully should be enough to do a transformation into the SMS gateway with the right encoding/character set.

The proposal in draft-ietf-sieve-notify-02.txt is this:
 
    Syntax:   notify [":method" string]
               [":id" string]
               [":options" 1*(string-list / number)]
               [<":low" / ":normal" / ":high">]
               ["message:" string]

I'm thinking it's got too many things in it which are trying to be super-generic to cover all uses (:method/:id/:options), but in actual fact we'll quickly regret this and prefer specific extensions for notifying through different channels with well defined and well documented arguments.

Which brings me on to variables.  Each of these different notification types, and also the vacation extension to a certain degree, has the need to author messages, and likely include sections of the triggering message.  So suppose I want to author what I think is a fairly reasonable SMS which looks like this:
           [To:<recipient-addresss>From:<sender-address>] <Subject>\r\n<body>

One way to get his is using the proposed $name$ variables which seem pretty ugly next to what we've worked so hard on with the variables extension, and also is pretty inflexible.  If we use the variables extension as is, then we could do this:

if header :matches “*” “To” {
  set “Recipient” “${1}”
}
if header :matches “*” “From” {
  set “Sender” “${1}”
}
if header :matches “*” “Subject” {
  set “Subject” “${1}”
}
set “Message” “[To: {$Recipient} From: {$Sender}] {$Subject}”

(I note that my intuative use of * won't work cos * in matches according to variables is non-greedy, yet * with regex is greedy, but I thought I'd do that deliberately to make you think...)

This seems like a lot of work to do something pretty "standard".

I wonder if it would make sense for us to add associative arrays containing entries of specific interest to the sieve script author.  So for example a $HEADERS array which contained all the header values.  So suppose my headers were:

Received: from p01m168.mxlogic.net [bla bla]
Received: from unknown [208.184.76.39] [bla bla]
Received: from above.proper.com  [bla bla]
Received: (from majordom@localhost) 
        by above.proper.com (8.12.11/8.12.9/Submit) id j0RHuuq8038984;
        Thu, 27 Jan 2005 09:56:56 -0800 (PST)
Date: Thu, 27 Jan 2005 09:56:56 -0800 (PST)
To: [e-mail]
From: [e-mail]
Subject: Welcome to ietf-mta-filters

Then I would end up with an array like this:

This would produce an array with these entries:
$HEADERS[‘Received’][0] = “from p01m168.mxlogic.net [bla bla] ”
$HEADERS[‘Received’][1] = “from unknown [208.184.76.39] [bla bla] ”
$HEADERS[‘Received’][2] = “from above.proper.com  [bla bla] ”
$HEADERS[‘Received’][3] = “(from majordom@localhost) ”
        .”by above.proper.com (8.12.11/8.12.9/Submit) id j0RHuuq8038984;”
        .“Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
$HEADERS[‘Date’][0] = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
$HEADERS[‘To’][0] = “[e-mail]”
$HEADERS[‘From’][0] = “[e-mail]”
$HEADERS[‘Subject’][0] = “Welcome to ietf-mta-filters”

The entries in the array would have RFC2047 encoding removed, stored in UTF8, and header wrapping would be removed such that the headers would have no new lines in them.  The \r\n at the end would be removed also.  (Note the “.” String concatenation operator is not available in Sieve, but used above to demonstrate the removal of header wrapping).  The implementation would be able to evaluate the entries of the associative array in a lazy manner to avoid proceesing.

When doing string expansion, if an array is used the entries in an array would be appended together, which would of course not include the \r\n that was in the original headers, and not do the header wrapping, which means it would be entirely unsuitable for use as email headers. If in future if we need a way of turning an array into a set of headers, then we can offer a parameter to the action that would take the array and the implementation would turn these into a valid header set.

With the above strategy, we now have this:
set “Message” “[To: ${HEADERS[‘To’]} From: ${HEADERS[‘From’]}] ${HEADERS[‘Subject’]}”

I then wonder if we should have other arrays like $ENV or $MESSAGE or $ENVELOPE and could hold information like the name of the mail server, the name of the mailbox, the domain, the time zone, the spam score, or virus score.  It could be the way that extensions provide their variables to us rather than what is suggested in the variables draft:
  
4.  Interpretation of strings
   Namespaces are meant for future extensions which make internal state
   available through variables.  These variables SHOULD be put in a
   namespace with the same name as its capability string.  Notice that
   the user can not specify a namespace when setting variables with SET.

This does mean that we could do header tests by using the string test, and the $HEADERS array, and I guess that's not a bad thing, but I'm not sure if it's a good thing either...

Ah, it feels better to get all that down on paper :o)

Nigel



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 j1226gbM076513; Tue, 1 Feb 2005 18:06:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1226gpL076512; Tue, 1 Feb 2005 18:06:42 -0800 (PST)
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 j1226fgj076498 for <[e-mail]>; Tue, 1 Feb 2005 18:06:41 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 01 Feb 2005 18:06:36 -0800 (PST)
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Date: Tue, 01 Feb 2005 18:05:42 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Wed, 02 Feb 2005 01:31:17 +0000" <013801c508c6$e61bb710$6501a8c0@nigelhome>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <013801c508c6$e61bb710$6501a8c0@nigelhome>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
To: Nigel Swinson <[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>

> > Ned and myself have reviewed the document. Anybody else?
> > Can I ask people who have reviewed the document to email me directly and
> > state that they found no problems with the document. I would appreciate
> > any feedback by February 7th (next Monday). Thanks!

> Just noticed this:
>       # Imagine the header
>       # Subject: [acme-users] [fwd] version 1.0 is out
>       if header :regex "Subject" "^[(.*)] (.*)$" {
>           # ${1} will hold "acme-users] fwd"
>       }

> Shouldn't the comment be:
>           # ${1} will hold "acme-users] [fwd"

Sure looks like it to me. Nice catch.

				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 j121VNIc074420; Tue, 1 Feb 2005 17:31:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j121VNmg074419; Tue, 1 Feb 2005 17:31:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121VNOm074409 for <[e-mail]>; Tue, 1 Feb 2005 17:31:23 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.209]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Tue, 1 Feb 2005 17:31:18 -0800
Message-ID: <013801c508c6$e61bb710$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Date: Wed, 2 Feb 2005 01:31:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j121VNOm074414
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>

> Ned and myself have reviewed the document. Anybody else?
> Can I ask people who have reviewed the document to email me directly and 
> state that they found no problems with the document. I would appreciate 
> any feedback by February 7th (next Monday). Thanks!

Just noticed this: 
      # Imagine the header
      # Subject: [acme-users] [fwd] version 1.0 is out
      if header :regex "Subject" "^[(.*)] (.*)$" {
          # ${1} will hold "acme-users] fwd"
      }

Shouldn't the comment be:
          # ${1} will hold "acme-users] [fwd"

Cheers,

Nigel





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 j121UJjT074318; Tue, 1 Feb 2005 17:30:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j121UJ19074317; Tue, 1 Feb 2005 17:30:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121UILZ074301 for <[e-mail]>; Tue, 1 Feb 2005 17:30:19 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.209]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 1 Feb 2005 17:30:08 -0800
Message-ID: <013701c508c6$bcbe1d90$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Subject: Uncontroversial bits and pieces about a number of drafts.
Date: Wed, 2 Feb 2005 01:30:05 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j121UJLZ074312
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>

http://www.ietf.org/internet-drafts/draft-showalter-sieve-vacation-06.txt
4.3. In-Reply-To and References
-     be generated, and References need not bne changed.
+     be generated, and References need not be changed.

http://www.imc.org/ietf-mta-filters/mail-archive/msg01900.html
(draft-degener-sieve-body-03.txt)
I thought body was not included in the base spec more out of concerns on the execution cost of a body test, not on the "implementation" costs as such.

http://www.imc.org/ietf-mta-filters/mail-archive/msg01901.html
(draft-degener-sieve-editheader-03.txt)
While some do call me Niggle, my official name has only one 'g' :o)
 -   Randall Schwartz, Nigegl Swinson, Kjetil Torgrim Homme, and
+   Randall Schwartz, Nigel Swinson, Kjetil Torgrim Homme, and

Cheers

Nigel

(Sorry, mysteriously got dropped from this list, so have only just finished catching up with a few months of posts...)



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 j11I1Qvr043011; Tue, 1 Feb 2005 10:01:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11I1QZe043010; Tue, 1 Feb 2005 10:01:26 -0800 (PST)
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 j11I1PqM042991 for <[e-mail]>; Tue, 1 Feb 2005 10:01:25 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 01 Feb 2005 10:01:16 -0800 (PST)
Cc: [e-mail]
Date: Tue, 01 Feb 2005 09:59:30 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Tue, 01 Feb 2005 17:21:06 +0000" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
To: Alexey Melnikov <[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>

> Alexey Melnikov wrote:

> > I would like to solicit your attention to the following draft:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-00.txt
> >
> > I've sent few editorial suggestions to the author, but I don't think
> > they should delay the WGLC any further.
> > The WGLC starts today. Due to winter holiday season it would last for
> > 4 weeks, i.e. till January 18th.
> > And I hope that Tim can submit 3028bis before that, so that the WG has
> > time to check if there are any interactions between the two documents.
> >
> Hi group,
> The WGLC is over and I haven't seen any comments on the document. This
> means that it is either perfect, or that people didn't have time to
> review it.

> Ned and myself have reviewed the document. Anybody else?

FWIW, I looked it over again and I think it is ready to go. The only
glitch I found was that the [SPAMTEST] reference should be changed
to refer to RFC 3685.

				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 j11HL8iA040372; Tue, 1 Feb 2005 09:21:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11HL8Bk040371; Tue, 1 Feb 2005 09:21:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11HL7GQ040365 for <[e-mail]>; Tue, 1 Feb 2005 09:21:08 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.185] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 1 Feb 2005 17:21:07 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2005 17:21:06 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Alexey Melnikov wrote:

> I would like to solicit your attention to the following draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-00.txt
>
> I've sent few editorial suggestions to the author, but I don't think 
> they should delay the WGLC any further.
> The WGLC starts today. Due to winter holiday season it would last for 
> 4 weeks, i.e. till January 18th.
> And I hope that Tim can submit 3028bis before that, so that the WG has 
> time to check if there are any interactions between the two documents.
>
Hi group,
The WGLC is over and I haven't seen any comments on the document. This 
means that it is either perfect, or that people didn't have time to 
review it.

Ned and myself have reviewed the document. Anybody else?
Can I ask people who have reviewed the document to email me directly and 
state that they found no problems with the document. I would appreciate 
any feedback by February 7th (next Monday). Thanks!

Alexey