Subject: [Fwd: Re: Information and collaboration space for Sieve]

From: Aaron Stone <[email-masked]>
Date: Tue, 31 Jan 2006 13:01:00 -0800

Hi folks,

Would those on the various Sieve WG's be interested in a Sieve wiki site
hosted at imc.org? And if so, be willing to manage user accounts to
those who want to post to the wiki?

Aaron

-------- Forwarded Message --------
From: Paul Hoffman <[email-masked]>
To: Aaron Stone <[email-masked]>
Subject: Re: Information and collaboration space for Sieve
Date: Tue, 31 Jan 2006 08:56:47 -0800

>Would you consider an access controlled wiki? Something that authors of
>drafts and frequent contributors could post to, but not just anybody.

Only if I didn't have to administer the posting rights. If the WG 
chairs like the idea and are willing to administer it, I'm happy to 
run it.

--Paul Hoffman, Director
--Internet Mail Consortium

Subject: [Fwd: Re: Information and collaboration space for Sieve]
From: Aaron Stone <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Date: Tue, 31 Jan 2006 13:01:00 -0800
Sender: [email-masked]

Hi folks,

Would those on the various Sieve WG's be interested in a Sieve wiki site
hosted at imc.org? And if so, be willing to manage user accounts to
those who want to post to the wiki?

Aaron

-------- Forwarded Message --------
From: Paul Hoffman <[email-masked]>
To: Aaron Stone <[email-masked]>
Subject: Re: Information and collaboration space for Sieve
Date: Tue, 31 Jan 2006 08:56:47 -0800

>Would you consider an access controlled wiki? Something that authors of
>drafts and frequent contributors could post to, but not just anybody.

Only if I didn't have to administer the posting rights. If the WG 
chairs like the idea and are willing to administer it, I'm happy to 
run it.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 31 Jan 2006 13:45:52 -0500
To: Ken Murchison <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
Sender: [email-masked]

On Tue, Jan 31, 2006 at 01:16:34PM -0500, Ken Murchison wrote:
> Alexey Melnikov wrote:
> >
> >This is possbile, but I think for all other tests the default comparator 
> >doesn't depend on match type.
> 
> Well, i;ascii-numeric is a SHOULD for :count (per Relational), and I 
> don't see why this can't be a MUST for hasflag :count, or :count in 
> general).

Relational says:

  The COUNT match type SHOULD only be used with numeric comparators.

which is quite different from saying that a different comparator should
be defaulted when using :count .  I think that trying to induce
different default comparators depending on combination of options opens
up a can of worms; i.e. I would agree that the default comparator should
not depend on the match type.

mm

Date: Tue, 31 Jan 2006 13:16:34 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Alexey Melnikov <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
Sender: [email-masked]

Alexey Melnikov wrote:
> Ken Murchison wrote:
> 
>> Alexey Melnikov wrote:
>>
>>> Ken Murchison has asked me how "hasflag" test interacts with 
>>> relational extension.
>>>
>>> hasflag :count will count the number of different flags in a variable.
>>> So
>>> hasflag :count "ge" "MyVariable" "5"
>>>
>>> returns true if the number of different flags in MyVariable is >= 
>>> "5". However note that the default comparator is i;ascii-casemap and 
>>> not i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
>>> parameter. Does anybody see any value in adding the comparator 
>>> parameter to hasflag test?
>>
>>
>> No.  RELATIONAL already requires the presence of i;ascii-numeric, so 
>> you could just state that hasflag :count  uses i;ascii-numeric instead 
>> of i;ascii-casemap.
> 
> 
> This is possbile, but I think for all other tests the default comparator 
> doesn't depend on match type.

Well, i;ascii-numeric is a SHOULD for :count (per Relational), and I 
don't see why this can't be a MUST for hasflag :count, or :count in 
general).

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Tue, 31 Jan 2006 17:11:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
Sender: [email-masked]

Ken Murchison wrote:

> Alexey Melnikov wrote:
>
>> Ken Murchison has asked me how "hasflag" test interacts with 
>> relational extension.
>>
>> hasflag :count will count the number of different flags in a variable.
>> So
>> hasflag :count "ge" "MyVariable" "5"
>>
>> returns true if the number of different flags in MyVariable is >= 
>> "5". However note that the default comparator is i;ascii-casemap and 
>> not i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
>> parameter. Does anybody see any value in adding the comparator 
>> parameter to hasflag test?
>
> No.  RELATIONAL already requires the presence of i;ascii-numeric, so 
> you could just state that hasflag :count  uses i;ascii-numeric instead 
> of i;ascii-casemap.

This is possbile, but I think for all other tests the default comparator 
doesn't depend on match type.

Date: Tue, 31 Jan 2006 11:54:40 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Alexey Melnikov <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
Sender: [email-masked]

Alexey Melnikov wrote:
> 
> Ken Murchison has asked me how "hasflag" test interacts with relational 
> extension.
> 
> hasflag :count will count the number of different flags in a variable.
> So
> hasflag :count "ge" "MyVariable" "5"
> 
> returns true if the number of different flags in MyVariable is >= "5". 
> However note that the default comparator is i;ascii-casemap and not 
> i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
> parameter. Does anybody see any value in adding the comparator parameter 
> to hasflag test?

No.  RELATIONAL already requires the presence of i;ascii-numeric, so you 
could just state that hasflag :count  uses i;ascii-numeric instead of 
i;ascii-casemap.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Tue, 31 Jan 2006 15:21:03 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Imapflags "hasflag" test interaction with relational draft
Sender: [email-masked]

Ken Murchison has asked me how "hasflag" test interacts with relational 
extension.

hasflag :count will count the number of different flags in a variable.
So
hasflag :count "ge" "MyVariable" "5"

returns true if the number of different flags in MyVariable is >= "5". 
However note that the default comparator is i;ascii-casemap and not 
i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
parameter. Does anybody see any value in adding the comparator parameter 
to hasflag test?

Alexey

Subject: Re: Central Sieve homepage
From: Alexandros Vellis <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Sat, 28 Jan 2006 00:42:25 +0200
Sender: [email-masked]

On Fri, 2006-01-27 at 14:27 -0800, Aaron Stone wrote:
> Oh, what about imc.org? Like, imc.org/sieve?

No problem, if they can offer adequate ways to access and edit content
in their servers.

BTW using Sourceforge is not a bad idea, because it will be independent
of any entity and will allow many people to participate and contribute.

I will try to update the pages I have resurrected, so that we'll have a
starting point.

-- 
Alexandros Vellis
[email-masked]

Subject: Re: Central Sieve homepage
From: Aaron Stone <[email-masked]>
To: Alexandros Vellis <[email-masked]>
Cc: [email-masked]
Date: Fri, 27 Jan 2006 14:27:14 -0800
Sender: [email-masked]

Oh, what about imc.org? Like, imc.org/sieve?

We might also ask that a separate Sieve section be made on the page
http://www.imc.org/rfcs.html what with the Sieve extensions each
becoming its own RFC.

Aaron

On Fri, 2006-01-27 at 23:15 +0200, Alexandros Vellis wrote:
> Aaron Stone wrote:
> > Since the demise of Cyrusoft, is there a new central information webpage
> > with resourcs about Sieve? If not, I'd like to propose that sieve.sf.net
> > be registered as used as such. An open wiki, ala freedesktop.org, would
> > probably serve well as information store.
> 
> I started an attempt to make a site that has up-to-date information,
> starting with the existing document that Cyrus Daboo was maintaining. My
> effort is at http://email.uoa.gr/sieve/ . I wanted to update the document
> with extensive information about implementations and links to current
> drafts through the ietfreport.isoc.org site. Unfortunately I had other
> time-consuming things that kept me from it in the meantime.
> 
> If you agree with the effort, I can take the responsibility and make it
> up-to-date. I can also add a wiki or other tools according to popular
> demand.
> 
> There is also the wiki page at fastmail.fm that describes implementations
> of the various extensions and capabilities.
> 
> I know the domain name I have is not the greatest, perhaps we can change
> it. (sieve.info is very good and available ;) )
> 
> Alexandros
> 

Date: Fri, 27 Jan 2006 23:15:04 +0200 (EET)
Subject: Re: Central Sieve homepage
From: "Alexandros Vellis" <[email-masked]>
To: "Aaron Stone" <[email-masked]>
Cc: [email-masked]
Importance: Normal
Sender: [email-masked]

Aaron Stone wrote:
> Since the demise of Cyrusoft, is there a new central information webpage
> with resourcs about Sieve? If not, I'd like to propose that sieve.sf.net
> be registered as used as such. An open wiki, ala freedesktop.org, would
> probably serve well as information store.

I started an attempt to make a site that has up-to-date information,
starting with the existing document that Cyrus Daboo was maintaining. My
effort is at http://email.uoa.gr/sieve/ . I wanted to update the document
with extensive information about implementations and links to current
drafts through the ietfreport.isoc.org site. Unfortunately I had other
time-consuming things that kept me from it in the meantime.

If you agree with the effort, I can take the responsibility and make it
up-to-date. I can also add a wiki or other tools according to popular
demand.

There is also the wiki page at fastmail.fm that describes implementations
of the various extensions and capabilities.

I know the domain name I have is not the greatest, perhaps we can change
it. (sieve.info is very good and available ;) )

Alexandros

Subject: Central Sieve homepage
From: Aaron Stone <[email-masked]>
To: [email-masked]
Date: Thu, 26 Jan 2006 20:34:36 -0800
Sender: [email-masked]

Since the demise of Cyrusoft, is there a new central information webpage
with resourcs about Sieve? If not, I'd like to propose that sieve.sf.net
be registered as used as such. An open wiki, ala freedesktop.org, would
probably serve well as information store.

Aaron

From: "Scott Hollenbeck" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: IESG Review of draft-ietf-sieve-vacation
Date: Tue, 24 Jan 2006 20:40:13 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Cyrus Daboo [mailto:[email-masked]] 
> Sent: Tuesday, January 24, 2006 7:47 PM
> To: Scott Hollenbeck; 'Ned Freed'
> Cc: [email-masked]
> Subject: RE: IESG Review of draft-ietf-sieve-vacation
> 
> Hi Scott,
> 
> --On January 19, 2006 1:46:00 PM -0500 Scott Hollenbeck 
> <[email-masked]> wrote:
> 
> > Thanks for the note, Ned.  It leads me to two more specific 
> questions:
> >
> > Does the document need to describe the issues noted below in an 
> > Internationalization Considerations section?  It might make sense.
> 
> My feeling is that what Ned described would be better off 
> being put in the base spec revision rather than vacation, 
> since its is applicable to base spec actions and other 
> extensions too. i.e. we don't need to add this directly to 
> vacation itself.
> 
> What do others on the list think?

That seems like a reasonable approach.  If others agree, can it be captured
as an issue to be addressed?

-Scott-

Date: Tue, 24 Jan 2006 19:46:39 -0500
From: Cyrus Daboo <[email-masked]>
To: Scott Hollenbeck <[email-masked]>, "'Ned Freed'" <[email-masked]>
cc: [email-masked]
Subject: RE: IESG Review of draft-ietf-sieve-vacation
Sender: [email-masked]

Hi Scott,

--On January 19, 2006 1:46:00 PM -0500 Scott Hollenbeck 
<[email-masked]> wrote:

> Thanks for the note, Ned.  It leads me to two more specific questions:
>
> Does the document need to describe the issues noted below in an
> Internationalization Considerations section?  It might make sense.

My feeling is that what Ned described would be better off being put in the 
base spec revision rather than vacation, since its is applicable to base 
spec actions and other extensions too. i.e. we don't need to add this 
directly to vacation itself.

What do others on the list think?

-- 
Cyrus Daboo

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sieve mailing list <[email-masked]>, sieve chair <[email-masked]>, sieve chair <[email-masked]>
Subject: Protocol Action: 'Sieve Extension: Variables' to Proposed  Standard 
Date: Tue, 24 Jan 2006 17:19:18 -0500
Sender: [email-masked]

The IESG has approved the following document:

- 'Sieve Extension: Variables '
   <draft-ietf-sieve-variables-08.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working 
Group. 

The IESG contact persons are Scott Hollenbeck and Ted Hardie.

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

Technical Summary

In advanced mail filtering rule sets, it is useful to keep state or
configuration details across rules.  This extension to the filtering
language Sieve 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.  This document updates RFC 3028.

Working Group Summary
 
The discussion about adding variables to the SIEVE mail filtering
language started 4-5 years ago during development of the IMAP flags
extension to SIEVE. The latter has been using a single implicit global
variable and several mailing list participants have expressed their wish
to have a more generic method of keeping state or configuration details
across rules. The ability to extract matching material from header fields
and perform further tests on it has also proven to be very useful. This
became even more apparent when the SIEVE regular expression draft was
written.

The document is minimalistic in its approach: several less used features
like automatically set current date/time variables got dropped from the 
document.

There was a discussion about having read-only variables automatically
set from different RFC 2822 message headers. There was no consensus to
add this to the document.

There was a discussion about having locally scoped variables. The
general feeling was that this feature complicates implementations quite
a bit for a feature very few Sieve scripts will find use for. So there
was no consensus to add this to the document, however, should the need
arise, it would be possible to add locally scoped variables as an 
extension.

Several WG members have proposed adding associative arrays. Some people
felt that this might be useful, but it will introduce extra implementation
complexity and could lead to implementation bugs. The WG has decided that
this can be postponed till later; the current "variables" document
doesn't prohibit this.
 
Protocol Quality

The WG asked the Security Area to perform a review of the document.
Two changes to the document has been done as the result of the review:
additional text in Security Considerations about silent truncation of
big values and an additional :quotewildcard modifier which gives a
convenient way to escape special matching characters in strings. Both
changes were discussed in details on the mailing list and have WG
consensus behind them.

There are already several implementations of the variables extension in
servers and more people have indicated that they are planning to 
implement it.
 
Scott Hollenbeck has reviewed this specification for the IESG.  Love
Hornquist Astrand and Jeffrey Hutzelman performed a security review
of the document.

Note to the RFC Editor

Please remove Section 0 from the document.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-spamtestbis-02.txt 
Date: Fri, 20 Jan 2006 15:50:02 -0500
Sender: [email-masked]

--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-02.txt
	Pages		: 12
	Date		: 2006-1-20
	
The SIEVE email filtering language "spamtest", "spamtestplus" 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-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-02.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-spamtestbis-02.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-imapflags-03.txt 
Date: Fri, 20 Jan 2006 15:50:02 -0500
Sender: [email-masked]

--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: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-03.txt
	Pages		: 0
	Date		: 2006-1-20
	
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-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-03.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-imapflags-03.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Scott Hollenbeck" <[email-masked]>
To: "'Ned Freed'" <[email-masked]>
Cc: [email-masked]
Subject: RE: IESG Review of draft-ietf-sieve-vacation
Date: Thu, 19 Jan 2006 13:46:00 -0500
Sender: [email-masked]

Thanks for the note, Ned.  It leads me to two more specific questions:

Does the document need to describe the issues noted below in an
Internationalization Considerations section?  It might make sense.

Are there any normative dependencies to existing i18n RFCs or I-Ds?  I'm not
so sure.

-Scott-

> -----Original Message-----
> From: Ned Freed [mailto:[email-masked]] 
> Sent: Thursday, January 19, 2006 12:36 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: Re: IESG Review of draft-ietf-sieve-vacation
> 
> 
> > The discuss that has been shared with the document shepherd 
> is still in
> > place.  I need text from Cyrus (the document shepherd, 
> coordinated as
> > appropriate) to resolve that minor issue.  Details in the 
> I-D tracker:
> 
> > 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=1300
> > 5
> 
> > Perhaps more importantly, an AD asked about internationalization
> > considerations.  What are the i18n implications of 
> displaying the fields
> > specified in the protocol?
> 
> As posed the question is next to impossible to answer. The 
> vacation extension
> provides a means of constructing a fairly arbitary email 
> message, one which can
> include, among other things, multipart/alternative objects 
> containing material
> in different languages. "Displaying the fields" therefore 
> equates to how email
> messages in general are displayed, and you could write a 
> thousand pages on that
> particular topic and not even scratch the surface.
> 
> Now, as it happens our implementation of vacation sees heavy 
> use with various
> ISPs and enterprises that have serious multilingual support 
> requirements. So
> internationalized use of vacation is something I happen to 
> have a large amount
> of experience with. The main internationalization issue that 
> actually arises
> in practice is given the availability of vacation responses 
> in multiple
> languages, what's the best way to select one to use?
> 
> One way to do it is to use out-of-band information, such as a 
> preferredlanguage
> attribute in an LDAP entry associated with the message 
> originator, to generate
> a one-time sieve script containing appropriately selected 
> text. This only works
> when such out-of-band information is available, of course, 
> and it fails to deal
> with the fact that selecting appropriate text also needs to 
> be able to cope
> with things like sending different text to a fellow employee 
> versus to a total
> stranger.
> 
> This then argues strongly for handling internationalized text 
> selection in the
> sieve script itself. It is a trivial matter to have a script test the
> preferred-language or content-language header field and take action
> accordingly. These tests can then be coupled with additional 
> decision-making
> logic as needed to generate an appropriate vacation resonse 
> (or not, as the
> case may be).
> 
> GUI interfaces that generate sieve scripts can be used to 
> hide the complexity
> of much of this from end users. Figuring out the right set of 
> options to
> present in a GUI is a nontrivial proposition, but more 
> because of the need to
> send different sorts of responses to different classes of 
> people than because
> of the issues involved in selecting a response in an 
> appropriate language.
> 
> Of course one approach is to simply use 
> multipart/alternative, as I mentioned
> previously. For whatever reason this approach isn't terribly 
> popular with our
> customers. I could speculate at length as to why this is so, 
> but I don't see
> such speculation as relevant to the matter at hand. The key 
> point here is that
> in practice we successully use sieve vacation in very demanding
> internationalized environments all the time.
> 
> 				Ned
> 
> P.S. A legitimate question to ask is whether or not end users 
> are actually
> prepared to write their messages in multiple languages. AFAIK 
> we don't see much
> of that with US customers - no surprise there - but you'd be 
> surprised how many
> end users take advantage of the capability in countries like Japan.
> 

Cc: [email-masked]
To: Scott Hollenbeck <[email-masked]>
Date: Thu, 19 Jan 2006 09:36:24 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: IESG Review of draft-ietf-sieve-vacation
Sender: [email-masked]

> The discuss that has been shared with the document shepherd is still in
> place.  I need text from Cyrus (the document shepherd, coordinated as
> appropriate) to resolve that minor issue.  Details in the I-D tracker:

> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1300
> 5

> Perhaps more importantly, an AD asked about internationalization
> considerations.  What are the i18n implications of displaying the fields
> specified in the protocol?

As posed the question is next to impossible to answer. The vacation extension
provides a means of constructing a fairly arbitary email message, one which can
include, among other things, multipart/alternative objects containing material
in different languages. "Displaying the fields" therefore equates to how email
messages in general are displayed, and you could write a thousand pages on that
particular topic and not even scratch the surface.

Now, as it happens our implementation of vacation sees heavy use with various
ISPs and enterprises that have serious multilingual support requirements. So
internationalized use of vacation is something I happen to have a large amount
of experience with. The main internationalization issue that actually arises
in practice is given the availability of vacation responses in multiple
languages, what's the best way to select one to use?

One way to do it is to use out-of-band information, such as a preferredlanguage
attribute in an LDAP entry associated with the message originator, to generate
a one-time sieve script containing appropriately selected text. This only works
when such out-of-band information is available, of course, and it fails to deal
with the fact that selecting appropriate text also needs to be able to cope
with things like sending different text to a fellow employee versus to a total
stranger.

This then argues strongly for handling internationalized text selection in the
sieve script itself. It is a trivial matter to have a script test the
preferred-language or content-language header field and take action
accordingly. These tests can then be coupled with additional decision-making
logic as needed to generate an appropriate vacation resonse (or not, as the
case may be).

GUI interfaces that generate sieve scripts can be used to hide the complexity
of much of this from end users. Figuring out the right set of options to
present in a GUI is a nontrivial proposition, but more because of the need to
send different sorts of responses to different classes of people than because
of the issues involved in selecting a response in an appropriate language.

Of course one approach is to simply use multipart/alternative, as I mentioned
previously. For whatever reason this approach isn't terribly popular with our
customers. I could speculate at length as to why this is so, but I don't see
such speculation as relevant to the matter at hand. The key point here is that
in practice we successully use sieve vacation in very demanding
internationalized environments all the time.

				Ned

P.S. A legitimate question to ask is whether or not end users are actually
prepared to write their messages in multiple languages. AFAIK we don't see much
of that with US customers - no surprise there - but you'd be surprised how many
end users take advantage of the capability in countries like Japan.

From: "Scott Hollenbeck" <[email-masked]>
To: [email-masked]
Subject: IESG Review of draft-ietf-sieve-vacation
Date: Thu, 19 Jan 2006 12:00:23 -0500
Sender: [email-masked]

The discuss that has been shared with the document shepherd is still in
place.  I need text from Cyrus (the document shepherd, coordinated as
appropriate) to resolve that minor issue.  Details in the I-D tracker:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1300
5

Perhaps more importantly, an AD asked about internationalization
considerations.  What are the i18n implications of displaying the fields
specified in the protocol?

-Scott-

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-notify-xmpp-00.txt 
Date: Wed, 18 Jan 2006 15:50:02 -0500
Sender: [email-masked]

--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 Notification Mechanism: xmpp
	Author(s)	: P. Saint-Andre, A. Melnikov
	Filename	: draft-ietf-sieve-notify-xmpp-00.txt
	Pages		: 7
	Date		: 2006-1-18
	
   This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over the Extensible
   Messaging and Presence Protocol (XMPP), also known as Jabber.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-notify-xmpp-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Subject: Re: "Any header" test - possible?
From: Alexandros Vellis <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Mon, 16 Jan 2006 15:57:12 +0200
Sender: [email-masked]

On Mon, 2006-01-16 at 13:47 +0000, Alexey Melnikov wrote:

> I don't think so.
> Can you describe a use-case for this feature in more details?

I don't have a specific scenario.

I am only doing a simple mapping of IMAP SEARCH commands to Sieve
filtering rules, for the purpose of some GUI convenience: In your MUA,
do a search in your folders, and with just two clicks add the same
criteria in your Sieve script.

Among other things, IMAP SEARCH has the argument:

   TEXT <string>
        Messages that contain the specified string in the header or
        body of the message.

So it seems that this cannot really be specified as Sieve?

I was thinking along the line

    anyof( :body :contains 'foo' , :header _:all?_ :contains 'foo')

-- 
Alexandros Vellis
[email-masked]

Date: Mon, 16 Jan 2006 13:47:00 +0000
From: Alexey Melnikov <[email-masked]>
To: Alexandros Vellis <[email-masked]>
CC: [email-masked]
Subject: Re: "Any header" test - possible?
Sender: [email-masked]

Alexandros Vellis wrote:

>I am wondering how I could check for e.g. the existence of some text in
>*any* header.  [With the text not being an email address so
>that :address test is not what I really want].
>
>RFC3028 (+bis) would imply that this is not possible. string-list that
>is used in header-list has to have at least one string:
>
>string-list = "[" string *("," string) "]" / string
>                   ; if there is only a single string, the brackets
>                   ; are optional
>
>So saying
>
>  header :contains [] "some text"
>
>or 
>
>  header :contains "some text"
>
>,implying to match any header, is not valid.
>
>So, is it possible to do what I want in Sieve?
>  
>
I don't think so.
Can you describe a use-case for this feature in more details?

Subject: "Any header" test - possible?
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Mon, 16 Jan 2006 13:24:28 +0200
Sender: [email-masked]

I am wondering how I could check for e.g. the existence of some text in
*any* header.  [With the text not being an email address so
that :address test is not what I really want].

RFC3028 (+bis) would imply that this is not possible. string-list that
is used in header-list has to have at least one string:

string-list = "[" string *("," string) "]" / string
                   ; if there is only a single string, the brackets
                   ; are optional

So saying

  header :contains [] "some text"

or 

  header :contains "some text"

,implying to match any header, is not valid.

So, is it possible to do what I want in Sieve?

-- 
Alexandros Vellis
[email-masked]

Date: Fri, 13 Jan 2006 10:18:48 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: testing for extensions during run-time
Sender: [email-masked]

On Thu, Jan 12, 2006 at 03:22:59PM -0500, Barry Leiba wrote:
> If I should move that script to a system that doesn't support
> notify, I might still want it to "work", in that I'd want it to do
> everything except the pager bit.

Ok, so the focus of this new test, whatever we call it, is to enhance
script portability.  I use Sieve in a number of places, but all scripts
are so different that portability is the least I would think of.
Your applications are obviously very different.

> then I get what I want, and I don't have to change the script.  And if,
> some say, my system adds support for notify, I'll start getting paged
> without having to find out that it's been upgraded, and without having
> to put the notify code back into the script.

Not something I would like.  Out of a sudden previously dead code
gets active.  My phone number might have changed and now someone else
gets my notifications (my fault).  There may be a semantic mistake in
the previously dead code, something managesieve could not check before,
and now that it is active, it causes an error and my script terminates,
leaving a mess to be discovered when coming back from vacation.

To me, we are talking about two different issues, and "environment"
as we talk about it, combines them in an unfortunate way.  I prefer to
put different things in different extensions:

o  Getting to know which extensions are supported.  For your applications,
   a Sieve extension is useful.  For mine, something like managesieve,
   although I would never implement it, is more suitable.  Ok, I see no
   problem there.  "environment" may be good solution for Sieve and
   any sieve implementation certainly had no problem to support that.

o  Having a way of not letting unknown extensions cause script failure.
   But why restrict that to unknown extensions? How about exception
   handling, something like "try & catch"? That does not only catch
   semantic errors at the action level, but also at the argument/option
   level.  Your "if" test above only catches the first.

I don't think I need either, but a new extension that looks like a
test and requires the fundamental change from strict to somewhat lazy
error checking sounds very wrong to me.  Exceptions may not be the best
solution, but at least you expect them to change error handling, and
they do so universally.

Unfortunately, the case spec forbids:

  try { require "notify"; } catch { }

The "require" statement is only allowed at the beginning of scripts.
Too bad.

Michael

Cc: Ned Freed <[email-masked]>, [email-masked]
To: Aaron Stone <[email-masked]>
Date: Thu, 12 Jan 2006 18:09:17 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: testing for extensions during run-time
Sender: [email-masked]

> On Thu, 2006-01-12 at 14:24 -0800, Ned Freed wrote:

> > Well, there has been talk about having some way in managesieve to get the list
> > of supported extensions, but AFAIK it has never made it into an actual
> > specification. Of course this may be more a result of no work having been done
> > on managesieve recently than anything else.

> I thought there was a CAPABILITY command... there certainly is in my
> implementation ;-)  Capabilities are presented in the greeting, too!

Forgot about that, sorry.

				Ned

Subject: Re: testing for extensions during run-time
From: Aaron Stone <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Date: Thu, 12 Jan 2006 17:26:37 -0800
Sender: [email-masked]

On Thu, 2006-01-12 at 14:24 -0800, Ned Freed wrote:

> Well, there has been talk about having some way in managesieve to get the list
> of supported extensions, but AFAIK it has never made it into an actual
> specification. Of course this may be more a result of no work having been done
> on managesieve recently than anything else.

I thought there was a CAPABILITY command... there certainly is in my
implementation ;-)  Capabilities are presented in the greeting, too!

Aaron

Cc: [email-masked]
To: Barry Leiba <[email-masked]>
Date: Thu, 12 Jan 2006 14:24:27 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: testing for extensions during run-time
Sender: [email-masked]

> Michael Haardt wrote:
> >>   if environment "extensions" "notify" {
> >>      ....
> >>   }
> >
> > I must be missing something, but why would you want to write scripts
> > that way? Which application would profit from this extension?
> >
> > I can imagine that a way to find out which extensions are available
> > is very useful for GUIs generating Sieve code, or even humans, but
> > for scripts?

> Well, the point of Sieve is for the scripts to be portable.  Ideally,
> I should be able to move a script from one environment to another,
> and it would still work.

> But now we have to consider the meaning of "work" [or "is" (it's a US
> politics joke; never mind)].  Suppose that a script was designed to
> to a whole bunch of stuff, using fileinto and redirect and whatnot,
> and then at the end it just wants to say, "OK, if, after all this,
> the message is going into a mailbox called "important", and the
> notify extension is available, then notify the recipient by pager.

> If I should move that script to a system that doesn't support
> notify, I might still want it to "work", in that I'd want it to do
> everything except the pager bit.  But if the script be coded thus:

>    require "environment", "fileinto", "notify"
>    ...
>    [do all the useful work]
>    ...
>    notify [...]

> then it will fail completely when it's run somewhere that doesn't
> support notify.  If I have the option of coding it this way:

>    require "environment", "fileinto"
>    ...
>    [do all the useful work]
>    ...
>    if environment "extensions" "notify" {
>      notify [...]
>    }

> then I get what I want, and I don't have to change the script.

I like this way of doing it. The "want" business used in an earlier example
didn't feel right, but this does.

There is precedent for this sort of thing, BTW. PostScript has the ability to
check for support for various extensions and only use them if they're
supported. (Or alternately, provide a different way to do something.) This
functionality used to be used a fair amount, although I haven't seen much of it
recently.

> And if,
> some say, my system adds support for notify, I'll start getting paged
> without having to find out that it's been upgraded, and without having
> to put the notify code back into the script.

Yes, although this does have a negative aspect - an upgrade changes behavior
and actives old code someone forgot was even there. This issue would certainly
need to be discussed in any specification we write.

> > If I used a GUI and it offers notifications, then I expect they are
> > available.

> (1) You're ignoring the script portability issue.
> (2) I would not make that assumption anyway.  There's no way for a GUI
> to query the Sieve system, and in a mix-and-match world there's no
> reason to assume we'll have bought the Sieve engine from the same
> source as we got the script builder from.

Well, there has been talk about having some way in managesieve to get the list
of supported extensions, but AFAIK it has never made it into an actual
specification. Of course this may be more a result of no work having been done
on managesieve recently than anything else.

> > I don't think the base specification unconditionally allows dead
> > code blocks that contain unknown extensions, like:
> >
> >   if false {
> >      unknown_extension;
> >   }
> >
> > Does the environment extension focus on the above usage and is it OK if
> > it enforces implementations to allow unknown extensions in dead code?

> I'm not sure I understand what you mean by any of that.
> I *think* you're asking whether the error is generated by the parser or
> by the execution, and I believe the answer is "execution".

Er, no. The base specification leaves this open. Implementations are free to
perform as much checking as they want before executing a script. It is
perfectly permissible to check and make sure that the script doesn't reference
any tests or actions that aren't listed in the require clause. Our
implementation does this, as a matter of fact.

The way we'd probably change this is to see if environment is listed  in the
require clause, and if it is disable this sort of checking. There's already a
way to disable this sort of strict checking, so this won't be hard for us to
implement.

I note in passing that only new tests, actions and comparators are amenable.
to this sort of thing. Something like

   if environment "extensions" "variables" ...

makes my head hurt.

				Ned

Subject: Re: testing for extensions during run-time
From: Kjetil Torgrim Homme <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: [email-masked]
Date: Thu, 12 Jan 2006 21:44:59 +0100
Sender: [email-masked]

On Thu, 2006-01-12 at 15:22 -0500, Barry Leiba wrote:
> Michael Haardt wrote:
> > I don't think the base specification unconditionally allows dead
> > code blocks that contain unknown extensions, like:
> > 
> >   if false {
> >      unknown_extension;
> >   }
> > 
> > Does the environment extension focus on the above usage and is it OK if
> > it enforces implementations to allow unknown extensions in dead code?

this is not the focus of the "environment" extension.  it very well
might better be in a separate extension.

> I'm not sure I understand what you mean by any of that.
> I *think* you're asking whether the error is generated by the parser or
> by the execution, and I believe the answer is "execution".  So if
> "unknown_extension" is never executed, there should be no error.

either is allowed.

   Compile-time errors are ones in syntax that are detectable if a
   syntax check is done.
   [...]
   Implementations MAY choose to do a full parse, then evaluate the
   script, then do all actions.  Implementations might even go so far as
   to ensure that execution is atomic (either all actions are executed
   or none are executed).

-- 
Kjetil T.

Date: Thu, 12 Jan 2006 15:22:59 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: testing for extensions during run-time
Sender: [email-masked]

Michael Haardt wrote:
>>   if environment "extensions" "notify" {
>>      ....
>>   }
> 
> I must be missing something, but why would you want to write scripts
> that way? Which application would profit from this extension?
> 
> I can imagine that a way to find out which extensions are available
> is very useful for GUIs generating Sieve code, or even humans, but
> for scripts?

Well, the point of Sieve is for the scripts to be portable.  Ideally,
I should be able to move a script from one environment to another,
and it would still work.

But now we have to consider the meaning of "work" [or "is" (it's a US
politics joke; never mind)].  Suppose that a script was designed to
to a whole bunch of stuff, using fileinto and redirect and whatnot,
and then at the end it just wants to say, "OK, if, after all this,
the message is going into a mailbox called "important", and the
notify extension is available, then notify the recipient by pager.

If I should move that script to a system that doesn't support
notify, I might still want it to "work", in that I'd want it to do
everything except the pager bit.  But if the script be coded thus:

   require "environment", "fileinto", "notify"
   ...
   [do all the useful work]
   ...
   notify [...]

then it will fail completely when it's run somewhere that doesn't
support notify.  If I have the option of coding it this way:

   require "environment", "fileinto"
   ...
   [do all the useful work]
   ...
   if environment "extensions" "notify" {
     notify [...]
   }

then I get what I want, and I don't have to change the script.  And if,
some say, my system adds support for notify, I'll start getting paged
without having to find out that it's been upgraded, and without having
to put the notify code back into the script.

> If I used a GUI and it offers notifications, then I expect they are
> available.  

(1) You're ignoring the script portability issue.
(2) I would not make that assumption anyway.  There's no way for a GUI
to query the Sieve system, and in a mix-and-match world there's no
reason to assume we'll have bought the Sieve engine from the same
source as we got the script builder from.

> I don't think the base specification unconditionally allows dead
> code blocks that contain unknown extensions, like:
> 
>   if false {
>      unknown_extension;
>   }
> 
> Does the environment extension focus on the above usage and is it OK if
> it enforces implementations to allow unknown extensions in dead code?

I'm not sure I understand what you mean by any of that.
I *think* you're asking whether the error is generated by the parser or
by the execution, and I believe the answer is "execution".  So if
"unknown_extension" is never executed, there should be no error.

Barry

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

Date: Thu, 12 Jan 2006 17:25:45 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: testing for extensions during run-time
Sender: [email-masked]

On Wed, Jan 11, 2006 at 02:14:59AM +0100, Kjetil Torgrim Homme wrote:
> 
> On Tue, 2006-01-10 at 19:06 -0500, Barry Leiba wrote:
> > I still wonder whether there ought to be a way to test for the presence
> > of an extension, rather than only to have the choice of *requiring* it
> > or not using it at all.  I can see a script wanting, for example, to
> > send a notification IF the Notify extension is available, but not
> > wanting the script to FAIL if it's not.
> 
> it certainly seems useful to me.  we could introduce an action, like:
> 
>   require "environment";
>   # or perhaps a separate extension.
>   want "notify";
>   if environment "extensions" "notify" {
>      ....
>   }

I must be missing something, but why would you want to write scripts
that way? Which application would profit from this extension?

I can imagine that a way to find out which extensions are available
is very useful for GUIs generating Sieve code, or even humans, but
for scripts?

If I used a GUI and it offers notifications, then I expect they are
available.  

I don't think the base specification unconditionally allows dead
code blocks that contain unknown extensions, like:

  if false {
     unknown_extension;
  }

Does the environment extension focus on the above usage and is it OK if
it enforces implementations to allow unknown extensions in dead code?

Michael

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Sieve Extension: Relational Tests' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Thu, 12 Jan 2006 10:34:25 -0500
Sender: [email-masked]

The IESG has received a request from the Sieve Mail Filtering Language WG to 
consider the following document:

- 'Sieve Extension: Relational Tests '
   <draft-ietf-sieve-3431bis-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-01-26.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-04.txt

Date: Wed, 11 Jan 2006 21:22:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sieve-variables-07
Sender: [email-masked]

Barry Leiba wrote:

>Anyway, as the discussion's gone since the note I'm responding to,
>there seems to be agreement that this and other identifying stuff would
>be useful in an "Environment" extension, or some such.
>
I agree.

>  Really, I
>didn't think it needed to be in Variables -- just that Variables seemed
>a logical place to put it.  I'm happy to put it in its own extension
>that defines some new test, like this (using one of the examples from
>the imap-sieve draft):
>
>     require ["copy", "environment"];
>
>     if anyof (environment :is "cause" "APPEND",
>               environment :is "cause" "COPY")  {
>         if environment :is "mailbox" "ActionItems" {
>             redirect :copy "[email-masked]";
>         }
>     }
>
>Note, here, that I've used two "environment" items, called "cause" and
>"mailbox".
>
>I agree that I like this better than doing it with variables, and it
>means that if the "environment" extension is available, it can specify
>the "DELIVERY" cause that I'm asking for.  That satisfies everything.
>I'll write up an "Environment" extension draft, if y'all think I
>should.  Ned?  Alexey/Cyrus?
>  
>
Sure. Submit it as an individual draft first. The WG is sufficiently 
behind on existing milestones, so I think it is premature to start 
discussing adding this work to the charter.

Cc: [email-masked]
To: Barry Leiba <[email-masked]>
Date: Wed, 11 Jan 2006 08:19:10 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-ietf-sieve-variables-07
Sender: [email-masked]

> >> The problem is that when a script is written to ask "Why did I get
> >> called?", it will have to assume that if it doesn't know, it's
> >> because it got called by "mail delivery".
> >
> > I'm dubious about the notion that there will be lots of scripts
> > intended to be run in a variety of different contexts that need to
> > test this sort of thing.

> We don't (or at least I don't) know what the actual use cases are
> likely to be, so I don't know whether I agree with you or not.

It is precisely because the use cases are unknown that I'm dubious
about the extent to which the feature will be useful. Designing software
in the absence of compelling use cases often results in features of
limited utility.

OTOH, environment tests serve other purposes, and the cost of another keyword
in such a test is incredibly low.

> If we
> provide a good way to manage multiple scripts, perhaps with an
> extension to ManageSieve, it might turn out that people always want to
> do different things at the different processing points, and they'll
> always use separate scripts for each.  In that case, no, this isn't
> necessary.

> Or it might be that there are common things that people will want done,
> and they'll just occasionally want to test this to do something
> different now and then.  In that case, we need this.

My problem isn't that the various different scripts won't have tests in
common. They will. The problem is rather that the actions you'll want to
take will be quite different (this is almost axiomatic) and the ways the
actions will be coupled to the tests will probably vary considerably.

> Anyway, as the discussion's gone since the note I'm responding to,
> there seems to be agreement that this and other identifying stuff would
> be useful in an "Environment" extension, or some such.  Really, I
> didn't think it needed to be in Variables -- just that Variables seemed
> a logical place to put it.  I'm happy to put it in its own extension
> that defines some new test, like this (using one of the examples from
> the imap-sieve draft):

>      require ["copy", "environment"];

>      if anyof (environment :is "cause" "APPEND",
>                environment :is "cause" "COPY")  {
>          if environment :is "mailbox" "ActionItems" {
>              redirect :copy "[email-masked]";
>          }
>      }

> Note, here, that I've used two "environment" items, called "cause" and
> "mailbox".

Mailbox is a good one I hadn't thought of before. it clearly needs to be made
available. The notion of being able to distinguish between different sorts of
insertion operations is also interesting.

> I agree that I like this better than doing it with variables, and it
> means that if the "environment" extension is available, it can specify
> the "DELIVERY" cause that I'm asking for.  That satisfies everything.
> I'll write up an "Environment" extension draft, if y'all think I
> should.  Ned?  Alexey/Cyrus?

Absolutely! Why isn't it already an I-D? ;-)
 
> I still wonder whether there ought to be a way to test for the presence
> of an extension, rather than only to have the choice of *requiring* it
> or not using it at all.  I can see a script wanting, for example, to
> send a notification IF the Notify extension is available, but not
> wanting the script to FAIL if it's not.

I'm worried about this as well, but I'm not happy about the implications
of making such a change either. As Harald would say, "mumble".

				Ned

Subject: testing for extensions during run-time
From: Kjetil Torgrim Homme <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: [email-masked]
Date: Wed, 11 Jan 2006 02:14:59 +0100
Sender: [email-masked]

On Tue, 2006-01-10 at 19:06 -0500, Barry Leiba wrote:
> I still wonder whether there ought to be a way to test for the presence
> of an extension, rather than only to have the choice of *requiring* it
> or not using it at all.  I can see a script wanting, for example, to
> send a notification IF the Notify extension is available, but not
> wanting the script to FAIL if it's not.

it certainly seems useful to me.  we could introduce an action, like:

  require "environment";
  # or perhaps a separate extension.
  want "notify";
  if environment "extensions" "notify" {
     ....
  }

since the grammar of Sieve is regular, an unknown extension can't
introduce elements which changes syntax parsing.  furthermore, the
validity of the elements in the script can easily be verified during
upload: if you find an unknown keyword or element, you look upwards in
the blocks leading down to the statement.  if a block is conditional on
the existence of an extension, and the extension is unknown, ignore the
statement, otherwise flag the error and refuse the upload.  a
bytecompiler can omit the complete block in its representation.

an implementation which does no verification during upload is no worse
off with this mechanism than without.  random syntax or semantic errors
can appear anywhere and must be handled anyway.

an anyof test does throw a spanner in the works, though.  I think it is
appropriate to disallow this explictly (although a _bit_ ugly), and have
the validation during upload assume that an anyof which includes an
extension test is _always_ true, even when the extension is unsupported.
(this is still the code for the script verifier I'm talking about.)

actually, the "want" action may be superfluous, but I think it should be
used to keep dependencies explicit up front.

just some random thoughts,
-- 
Kjetil T.

Date: Tue, 10 Jan 2006 19:06:53 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-sieve-variables-07
Sender: [email-masked]

>> The problem is that when a script is written to ask "Why did I get
>> called?", it will have to assume that if it doesn't know, it's
>> because it got called by "mail delivery".
> 
> I'm dubious about the notion that there will be lots of scripts
> intended to be run in a variety of different contexts that need to
> test this sort of thing.

We don't (or at least I don't) know what the actual use cases are
likely to be, so I don't know whether I agree with you or not.  If we
provide a good way to manage multiple scripts, perhaps with an
extension to ManageSieve, it might turn out that people always want to
do different things at the different processing points, and they'll
always use separate scripts for each.  In that case, no, this isn't
necessary.

Or it might be that there are common things that people will want done,
and they'll just occasionally want to test this to do something
different now and then.  In that case, we need this.

Anyway, as the discussion's gone since the note I'm responding to,
there seems to be agreement that this and other identifying stuff would
be useful in an "Environment" extension, or some such.  Really, I
didn't think it needed to be in Variables -- just that Variables seemed
a logical place to put it.  I'm happy to put it in its own extension
that defines some new test, like this (using one of the examples from
the imap-sieve draft):

     require ["copy", "environment"];

     if anyof (environment :is "cause" "APPEND",
               environment :is "cause" "COPY")  {
         if environment :is "mailbox" "ActionItems" {
             redirect :copy "[email-masked]";
         }
     }

Note, here, that I've used two "environment" items, called "cause" and
"mailbox".

I agree that I like this better than doing it with variables, and it
means that if the "environment" extension is available, it can specify
the "DELIVERY" cause that I'm asking for.  That satisfies everything.
I'll write up an "Environment" extension draft, if y'all think I
should.  Ned?  Alexey/Cyrus?

I still wonder whether there ought to be a way to test for the presence
of an extension, rather than only to have the choice of *requiring* it
or not using it at all.  I can see a script wanting, for example, to
send a notification IF the Notify extension is available, but not
wanting the script to FAIL if it's not.

Barry

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

Subject: Re: draft-ietf-sieve-variables-07
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Date: Wed, 11 Jan 2006 00:43:16 +0100
Sender: [email-masked]

On Tue, 2006-01-10 at 09:07 -0800, Ned Freed wrote:
> > > I would therefore suggest an extension specifying an "environment" test as a
> > > better approach. I suspect we can come up with half a dozen things such a test
> > > could operate on.
> [...]
> I'm curious as to what sorts of things you have in this class. The things I
> immediately see as useful are the server name, the place in the process where
> the script is executing, and information relating to whether or not this script
> is executing standalone or has been called in some way from another script.

I'm also in favour of an "environment" extension rather than adding this
to variables.

in addition to server name, some identification for the site would be
useful, at least if the provider chooses to expose internal architecture
to end users (which we do).  other operational limits might be useful,
too, e.g. max size for messages, remaining quota (dynamic, so maybe not
appropriate), stuff like that.
-- 
Kjetil T.

From: "Nigel Swinson" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-sieve-variables-07
Date: Tue, 10 Jan 2006 18:35:57 -0000
Sender: [email-masked]

> > I like this a lot.  I was struggling to articulate why I didn't like what was
> > being proposed, but this sounds very extensible.  I already have a
> > CSieveRunTimeEnvironment class in my solution and was already wanting to make
> > more information available to the script.
> 
> I'm curious as to what sorts of things you have in this class. The things I
> immediately see as useful are the server name, the place in the process where
> the script is executing, and information relating to whether or not this script
> is executing standalone or has been called in some way from another script.

It holds state/manages things like:
- Mail message
- Owner info
- Server info
- Variables
- Method to obtain spam score/virus scoret
- A cache of the spam score, virus score
- Methods for reporting errors

But my reason for the comment was the relating to "Information about the owner".  ie I'm thinking it might be useful to access mailowner/domain/mailserver configuration from within a sieve script.  Perhaps things like the server name, but also possibly mailbox properties like return addresses.

In the case of scripts that are executed against lots of mailboxes then I was also thinking of stuff like:

 Do initial basic sieve filtering
 if (User has paid me for feature X) {
   Do expensive sieve filtering
 }
 if (User has paid me for feature Y) {
   Do slightly less expensive sieve filtering
 }
 Do basic sieve filtering

Nigel

Cc: Ned Freed <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>, [email-masked]
To: Nigel Swinson <[email-masked]>
Date: Tue, 10 Jan 2006 09:07:25 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-ietf-sieve-variables-07
Sender: [email-masked]

> > I would therefore suggest an extension specifying an "environment" test as a
> > better approach. I suspect we can come up with half a dozen things such a test
> > could operate on.

> I like this a lot.  I was struggling to articulate why I didn't like what was
> being proposed, but this sounds very extensible.  I already have a
> CSieveRunTimeEnvironment class in my solution and was already wanting to make
> more information available to the script.

I'm curious as to what sorts of things you have in this class. The things I
immediately see as useful are the server name, the place in the process where
the script is executing, and information relating to whether or not this script
is executing standalone or has been called in some way from another script.

> I also agree that this should be an additional extension, primarily so it
> doesn't hold up variables, and secondarily cos I don't think it "needs" to be
> part of the base variables spec.

Complete agreement here.

				Ned

From: "Nigel Swinson" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: "Kjetil Torgrim Homme" <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-sieve-variables-07
Date: Mon, 9 Jan 2006 13:37:42 -0000
Sender: [email-masked]

> I would therefore suggest an extension specifying an "environment" test as a
> better approach. I suspect we can come up with half a dozen things such a test
> could operate on.

I like this a lot.  I was struggling to articulate why I didn't like what was being proposed, but this sounds very extensible.  I already have a CSieveRunTimeEnvironment class in my solution and was already wanting to make more information available to the script.

I also agree that this should be an additional extension, primarily so it doesn't hold up variables, and secondarily cos I don't think it "needs" to be part of the base variables spec.

Nigel

Cc: Ned Freed <[email-masked]>, [email-masked]
To: Aaron Stone <[email-masked]>
Date: Sun, 08 Jan 2006 18:01:24 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-ietf-sieve-variables-07
Sender: [email-masked]

> On Sun, 2006-01-08 at 08:37 -0800, Ned Freed wrote:
> [snip]
> > > So I'm suggesting that the variables spec define a base namespace
> > > (I'm suggesting "Sieve.").  And I'm suggesting that the variables
> > > spec define a variable that MUST be set ...

> >From a language implementation point of view, if you're going to reserve
> a keyword or a namespace, do it sooner rather than later.

Since namespaces are bound to future extensions by the current variables
draft, all namespaces are effectively reserved already.

> [snip]
> > I also think additional environmental information might be useful to  provide
> > to script. Indeed, I suspect that knowing, say, the name of the system you're
> > running on might be even more useful to scripts than being able to distinguish
> > between delivery and other places sieves are used.
> >
> > I would therefore suggest an extension specifying an "environment" test as a
> > better approach. I suspect we can come up with half a dozen things such a test
> > could operate on.

> Maybe? Sieve is a "little language" and I like to think of Sieve scripts
> as being these little gnomes that push my mail around. Gnomes don't
> think too hard about where they are or where they're going; gnomes just
> focus on what they're doing right now.

I'm sorry, but I have to disagree. Lots of people have more than one email
account and one of the goals of sieve is for a user to be able to define
something that works in multiple places. Wanting to have somewhat different
behavior depending on the environment is a fairly obvious thing to want to do,
even when all the different environments correspond to the same place in email
processing. As a specific example, i might want to have a very different
spamtest threshhold for the filter I use on my ISP account than the one I use
on my corporate account.

This isn't to say that there aren't significant barriers to script portability.
The most obvious one is the very real possibility that the set of supported
extensions is quite different in different environments. Since requires cannot
be conditionalized this forces scripts intended for multiple environments to be
written us9ing the least common denominator set of extensions, which is often
pretty unappealing.

This all gets especially nasty when you change places. The set of available
actions at delivery time is unavoidably different from the set of actions
available within an IMAP server. This is reflected in the sieve-in-IMAP draft
in various ways, including the omission of reject. So what should

	require "reject";

do in such a script?

				Ned

Subject: Re: draft-ietf-sieve-variables-07
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: [email-masked]
Date: Mon, 09 Jan 2006 02:14:42 +0100
Sender: [email-masked]

On Sun, 2006-01-08 at 15:04 -0800, Aaron Stone wrote:
> Maybe? Sieve is a "little language" and I like to think of Sieve scripts
> as being these little gnomes that push my mail around. Gnomes don't
> think too hard about where they are or where they're going; gnomes just
> focus on what they're doing right now.

sorry, but I don't understand what this means.
-- 
Kjetil T.

Subject: Re: draft-ietf-sieve-variables-07
From: Aaron Stone <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Date: Sun, 08 Jan 2006 15:04:48 -0800
Sender: [email-masked]

On Sun, 2006-01-08 at 08:37 -0800, Ned Freed wrote:
[snip]
> > So I'm suggesting that the variables spec define a base namespace
> > (I'm suggesting "Sieve.").  And I'm suggesting that the variables
> > spec define a variable that MUST be set ...

>From a language implementation point of view, if you're going to reserve
a keyword or a namespace, do it sooner rather than later.

[snip]
> I also think additional environmental information might be useful to  provide
> to script. Indeed, I suspect that knowing, say, the name of the system you're
> running on might be even more useful to scripts than being able to distinguish
> between delivery and other places sieves are used.
> 
> I would therefore suggest an extension specifying an "environment" test as a
> better approach. I suspect we can come up with half a dozen things such a test
> could operate on.

Maybe? Sieve is a "little language" and I like to think of Sieve scripts
as being these little gnomes that push my mail around. Gnomes don't
think too hard about where they are or where they're going; gnomes just
focus on what they're doing right now.

Aaron

Cc: Kjetil Torgrim Homme <[email-masked]>, [email-masked]
To: Barry Leiba <[email-masked]>
Date: Sun, 08 Jan 2006 08:37:11 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-ietf-sieve-variables-07
Sender: [email-masked]

> >> For the former: the lemonade extension adds a reserved variable which
> >> I'm currently calling "IMAPSieve.cause".  Its value is the action
> >> that caused the script to be run ("APPEND", "COPY", and so on).  It
> >> occurs to me that it'll be awkward for scripts to have to wonder
> >> what the absence of that variable means.  Wouldn't it be a good idea
> >> to have a reserved namespace called "Sieve.", and to have a variable
> >> called "Sieve.cause" that's ALWAYS available if variables are
> >> supported?  In the normal case, its value would be "DELIVERY", and
> >> extensions like mine can specify other values.  (This might also add
> >> an IANA item....)
> >
> > okay, so you think this namespace should be defined in the variables
> > draft?  I'm not too wild with the idea, since I really wanted -08
> > which I submitted yesterday to finally reach RFC status.

> Oh, well.  So it can be the -09 version that does; is that such a big
> deal?

Frankly, yes. We need to finish up this spec and get it out the door. The list
of potential additions of this general sort is for all intents and purposes
infinite.

> > I would expect the
> > extension to be required by anyone wanting to inspect that variable,
> > and so I don't see much benefit to making it a globally available
> > variable.

> The problem is that when a script is written to ask "Why did I get
> called?", it will have to assume that if it doesn't know, it's because
> it got called by "mail delivery".  Since we're at a point where we
> could get that modified in the variables draft now, I think we should.

I'm dubious about the notion that there will be lots of scripts intended to be
run in a variety of different contexts that need to test this sort of thing.
However, I have no objection to making such a test available, although I think
the right way to do it is as a separate extension and test, not as  a magic
variable. For one thing, this means that in order for such a test to work you
have to have the variables extension, and I worry that variables may not be
implemented or enabled in some performance-sensitive environments.

> So I'm suggesting that the variables spec define a base namespace (I'm
> suggesting "Sieve.").  And I'm suggesting that the variables spec
> define a variable that MUST be set (I'm suggesting "Sieve.cause",

"place" seems to me to be a more natural name for this, but I'm not wedded
to any particular term either.

> but
> I'm not particular about the name) that gives the reason the script was
> called.  I'm suggesting that the value for mail delivery be "DELIVERY".
> And I'm suggesting that the variables spec say that other extensions
> may add other values, if they create other causes for having Sieve
> scripts called.  It seems a simple change, and a useful one in the long
> run.

I don't necessarily see running sieves in different environments as
necessitating additional extensions. It seems to me a simple "places" registry
would be sufficient. And it probably should allow for vendor-supplied places
since I suspect there will be non-standard uses of sieve. (In fact I know there
will be because we already have two in our product and another two are
planned.)

I also think additional environmental information might be useful to  provide
to script. Indeed, I suspect that knowing, say, the name of the system you're
running on might be even more useful to scripts than being able to distinguish
between delivery and other places sieves are used.

I would therefore suggest an extension specifying an "environment" test as a
better approach. I suspect we can come up with half a dozen things such a test
could operate on.

				Ned

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-vacation-05.txt 
Date: Tue, 03 Jan 2006 15:50:01 -0500
Sender: [email-masked]

--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:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-05.txt
	Pages		: 16
	Date		: 2006-1-3
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-vacation-05.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-vacation-05.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-05.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--