Subject: I-D ACTION:draft-ietf-sieve-3028bis-10.txt

From: [email-masked]
Date: Fri, 02 Feb 2007 15:50:02 -0500

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: An Email Filtering Language
	Author(s)	: T. Showalter, P. Guenther
	Filename	: draft-ietf-sieve-3028bis-10.txt
	Pages		: 44
	Date		: 2007-2-2
	
This document describes a language for filtering email messages at
   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 Message Access Protocol (IMAP) servers, as the base language
   has no variables, loops, or ability to shell out to external
   programs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-3028bis-10.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-3028bis-10.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-3028bis-10.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.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Feb 2007 16:02:35 +0000

Alexey Melnikov wrote:

> Folks,
> This is your last chance to review that the document is correct and 
> complete. No new issues can be raised at this stage unless they are 
> very serious.

I actually do have one issue with a recent change in -10 which I 
consider to be serious, because it broke my Sieve implementation (as 
well as CMU's)

 > 8.1.     Lexical Tokens
 >
 >    Sieve scripts are encoded in UTF-8.  The following assumes a valid
 >    UTF-8 encoding; special characters in Sieve scripts are all US-ASCII.
 >
 >    The following are tokens in Sieve:
 >
 >            - identifiers
 >            - tags
 >            - numbers
 >            - quoted strings
 >            - multi-line strings
 >            - other separators
 >
 >    Identifiers, tags, and numbers are case-insensitive, while quoted
 >    strings and multi-line strings are case-sensitive.

I actually have a problem with *numbers* being case-insensitive. Cyrus
Sieve doesn't accept "k", "m" and "g" prefixes in numbers.

So I would like to poll the WG regarding this issue. Do people want to 
make to make number case-insensitive, or should this change be undone?
(In the latter case there is one example in 3028bis-10 which uses 
lowercase 'k' now, which has to change)

Thanks,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Feb 2007 15:57:03 +0000

Folks,
This is your last chance to review that the document is correct and 
complete. No new issues can be raised at this stage unless they are very 
serious.

Please review the document by the end of February 11th. Cyrus and I are 
planning to send it to IESG soon after February 11th.

Regards,
Alexey and Cyrus.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 05 Feb 2007 13:00:56 -0500

> lowercase 'k' now, which has to change)

Obviously, digits are case-insensitive, but by stating "number" this 
also includes QUANTIFIER, which only allows uppercase per the ABNF.

I think we should move "numbers" from the case-insensitive list to the 
case-sensitive list in order to maintain backwards compatibility.

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

---

From: Philip Guenther <[email-masked]>
Date: Mon, 5 Feb 2007 13:33:43 -0700

> Alexey Melnikov wrote:
...
>> So I would like to poll the WG regarding this issue. Do people want to make 
>> to make number case-insensitive, or should this change be undone?
>> (In the latter case there is one example in 3028bis-10 which uses lowercase 
>> 'k' now, which has to change)
>
> Obviously, digits are case-insensitive, but by stating "number" this also 
> includes QUANTIFIER, which only allows uppercase per the ABNF.

Nope.  RFC 3028 said:

    QUANTIFIER = "K" / "M" / "G"

Literal strings in ABNF are always case-insensitive.

So the question is: was this a bug in the grammar or a bug in those 
implementations?  I know that the Sendmail implementation has treated them 
as case-insensitive from its beginning.

Philip Guenther

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 6 Feb 2007 19:03:41 +0100

> consider to be serious, because it broke my Sieve implementation (as 

Why did this break your implementation? It did not cause any previously 
valid scripts to become invalid. All it did was clarify an existing 
rule.

> make to make number case-insensitive, or should this change be 

Making numbers case-sensitive could invalidate extant valid scripts. 
That needs strong justification IMO.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Feb 2007 18:18:41 +0000

Arnt Gulbrandsen wrote:

> Why did this break your implementation? It did not cause any 
> previously valid scripts to become invalid. All it did was clarify an 
> existing rule.

If somebody puts "100k" in a Sieve script, Sieve lexer is going to 
reject such script.

>> I actually have a problem with *numbers* being case-insensitive. 
>> Cyrus Sieve doesn't accept "k", "m" and "g" prefixes in numbers.
>>
>> So I would like to poll the WG regarding this issue. Do people want 
>> to make to make number case-insensitive, or should this change be 
>> undone?
>

Let's assess the damage first. If it turns out that the majority of 
implementations implement case-insensitive suffixes, then I will have to 
fix my implementation ;-).

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Feb 2007 18:17:37 +0000

> Literal strings in ABNF are always case-insensitive.

Ok, you are right. But many people got beaten by this ABNF "feature".

> implementations?

Indeed.

> I know that the Sendmail implementation has treated them as 
> case-insensitive from its beginning.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 06 Feb 2007 13:41:50 -0500

> Ok, you are right. But many people got beaten by this ABNF "feature".

Including CMU (before my time).  Its about a 10 sec fix for me, so I'll 
do whatever the consensus dictates.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 6 Feb 2007 19:40:07 +0100

Alexey Melnikov writes:
>>> consider to be serious, because it broke my Sieve implementation 
>>> (as well as CMU's)
>>
>> previously valid scripts to become invalid. All it did was clarify 
>> an existing rule.
>

Yes. But that's not lasting damage - the user has to change kmg to KMG 
and upload the script again.

Compare that with the alternative: Scripts which have passed 
managesieve's putscript checking become syntactically invalid when the 
server is upgraded.

> implementations implement case-insensitive suffixes, then I will have 
> to fix my implementation ;-).

I wrote my code case-insensitively, but it's unreleased as yet.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 06 Feb 2007 10:58:54 -0800 (PST)

> I wrote my code case-insensitively, but it's unreleased as yet.

FWIW, our implementation also handles either case. The only "problem" we've ever
had with this feature is users who enter values like 100000G and then get upset
when it says "integer too large" or something similar. (Yes, we frequently get
absurd complaints like this.)

I believe our script generator puts these out in upper case and I know I've
seen hand-constructed scripts have them in lower case. So scripts are probably
gonna break if we make this case-sensitive.

				Ned

---

From: "Aaron Stone" <[email-masked]>
Date: Tue, 6 Feb 2007 19:10:08 -0000

> do whatever the consensus dictates.

I've inherited that same line in my lexer (with the same effort required
to change it ;-). I don't feel strongly either way as to whether we should
relax the spec to be case insensitive.

Aaron

---

From: "Aaron Stone" <[email-masked]>
Date: Tue, 6 Feb 2007 19:39:50 -0000

>> >> Alexey Melnikov writes:
[snip]
>> I wrote my code case-insensitively, but it's unreleased as yet.
[snip]
> I believe our script generator puts these out in upper case and I know
> I've seen hand-constructed scripts have them in lower case. So scripts
> are probably gonna break if we make this case-sensitive.

Sounds like one of those cases where the spec should be strict but the
implementations should be relaxed.

Aaron

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 06 Feb 2007 15:33:02 -0500

Hi Philip,

> So the question is: was this a bug in the grammar or a bug in those

Based on responses from others, I think we have to leave this as-is. 
Implementations treating those quantifiers as case-sensitive will need to 
be fixed.

-- 
Cyrus Daboo

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 6 Feb 2007 17:53:45 -0500

> Ok, you are right. But many people got beaten by this ABNF "feature".

My implementation treats them as case insensitive, mainly because I
wanted it that way and didn't think it would hurt anything to be
friendlier to humans typing numbers.  

So I'm happy with the change :)

mm

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Feb 2007 11:04:22 +0000

> complete. No new issues can be raised at this stage unless they are 

Clarification: no editorial changes will be accepted at this stage 
without any concrete text. Thanks.

> Please review the document by the end of February 11th. Cyrus and I 
> are planning to send it to IESG soon after February 11th.