Sieve Extension for Converting Messages before Delivery
RFC 6558

Note: This ballot was opened for revision 06 and is now closed.

(Pete Resnick) Yes

(Jari Arkko) No Objection

Comment (2011-12-01 for -)
No email
send info
Ari Keränen's review:

For people not that familiar with IMAP extensions and Sieve the abstract 
of the document is not not immediately clear. Maybe clarify this with:

s/IMAP CONVERT/the "CONVERT" IMAP extension/
s/Sieve/Sieve mail filtering language/

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-12-01 for -)
No email
send info
Section 2

   If a "convert" action cannot be completed -- perhaps because the
   conversion failed, or because the requested conversion is not
   available -- the message MUST remain unchanged, and the script
   processing continues.   In particular, no error condition is raised,
   and no partial conversions are allowed.

To be clear, you mean '...MUST remain unchanged by that "convert"
action,...'
and
'...and no partial conversions due to a single "convert" action are
allowed.'

As written it implies no change is allowed (and changes already made 
must be unpicked).

And (for my own clarity) this means that if there are two conversions
that would be carried out by a single convert command, the first 
replacement is successful and the second fails, the result must not 
include either replacement.

Maybe it would help to really spell this out.

---

I think you might comment on infinite recursions. 

Suppose in your example 3.1 you had written 

       require ["convert"];
       convert "image/tiff" "image/tiff" ["pix-x=320","pix-y=240"];

(as I see in the middle of 3.4)

It is easy to see how this might be interpreted as an infinite loop,
but also easy to cover the case with a line of text that says the
output of any conversion must be considered as atomic so that the
conversion never applies to its own output.

It would probably be possible to come up with worse (explosive)
scenarios.

(Stephen Farrell) No Objection

Comment (2011-11-26 for -)
No email
send info
Does rfc5259 support doing things in loops? If not, then it
seems like this makes the potential DoS on the server worse
to the extent that the client can craft a CPU intensive loop.
If applicable, then that should be noted.

(David Harrington) No Objection

(Russ Housley) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-11-28 for -)
No email
send info
In Section 2.1, it might be helpful to cite RFC 5228 on the definition of "implicit keep".

(Robert Sparks) No Objection

(Sean Turner) No Objection