Subject: [sieve] I-D Action: draft-ietf-sieve-convert-06.txt

From: [email-masked]
Date: Thu, 01 Dec 2011 09:43:41 -0800

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 Extension for Converting Messages Before Delivery
	Author(s)       : Alexey Melnikov
                          Qian Sun
                          Barry Leiba
                          Kepeng Li
	Filename        : draft-ietf-sieve-convert-06.txt
	Pages           : 9
	Date            : 2011-12-01

   This document describes how the "CONVERT" IMAP extension can be used
   within the Sieve mail filtering language to transform messages before
   final delivery.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sieve-convert-06.txt

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 22 Dec 2011 22:08:55 +0100

> 	Filename        : draft-ietf-sieve-convert-06.txt

I was just reading this specification again for some example text, and I 
noticed a small issue. This nit is about the following requirement from 
Section 6 of RFC 5228 (Sieve):

    Extensions MUST state how they interact with constraints defined in
    section 2.10, e.g., whether they cancel the implicit keep, and which
    actions they are compatible and incompatible with.

The latter part of this requirement is obviously explicitly met in 
Section 2.1. However, I miss an explicit statement about whether or not 
the new "convert" action cancels the implicit keep. Although it should 
be quite obvious and the examples provide various hints in the correct 
direction, I think an explicit sentence is in order. For example, I did 
find this for both new actions defined in the editheader specification 
(RFC5293), e.g. `The addheader action does not affect Sieve's implicit 
keep.' I think the situation is very similar in this case.

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 Dec 2011 10:53:44 -0500

> The latter part of this requirement is obviously explicitly met in Section
> 2.1. However, I miss an explicit statement about whether or not the new
> "convert" action cancels the implicit keep. Although it should be quite
> obvious and the examples provide various hints in the correct direction, I
> think an explicit sentence is in order.

A fair suggestion.  I will extend the last paragraph of section 2.1
when we go into AUTH48 (or Pete can put in an RFC Editor note now):

OLD
   Because the implicit keep (see Section 2.10.2 of [RFC5228]), if it is
   in effect, acts on the final state of the message, all conversions
   are performed before any implicit keep.

NEW
   Because the implicit keep (see Section 2.10.2 of [RFC5228]), if it is
   in effect, acts on the final state of the message, all conversions
   are performed before any implicit keep.  The "convert" actions
   themselves have no effect on the implicit keep status.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Dec 2011 20:00:44 +0000

>     themselves have no effect on the implicit keep status.
+1.