Sieve Extension for Converting Messages before Delivery
RFC 6558
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Pete Resnick; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
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/
(Peter Saint-Andre; former steering group member) No Objection
In Section 2.1, it might be helpful to cite RFC 5228 on the definition of "implicit keep".
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection