Re: [sieve] I-D Action: draft-ietf-sieve-convert-02.txt

[Barry Leiba <[e-mail]>]

First, as I said on the mic in Québec, thanks, Stephan, for great
reviews of convert and imap-sieve.  I'll be getting to the latter
soon.

Stephan has brought up two main issues (the third is easy, and I've
clarified that for the upcoming version):

1. Do we need a test for what conversions are supported?

2. How do we handle error conditions?

I've tentatively made the following change to section 2 for the second item:

OLD
   Implementations ought to defer any actual conversion until the final
   resolution of other actions, to avoid doing conversions unnecessarily
   in cases where the message is not retained (such as where the
   resolution is "discard").

NEW
   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.

   Implementations might defer any actual conversion until the the
   results of the conversion are needed for script processing, to avoid
   doing conversions unnecessarily.  Consider the case wherein a
   "convert" action is processed, but a "discard" action results without
   the need to actually perform the conversion.


Now, this doesn't take into account Alexey's comment that he'd like to
see a runtime error when conversion fails, so I want to push on this:
What is the use case?  Is it more valuable to the use case for a
failed conversion to crash the script, or for it to just continue?
The sense I have is that it should continue (which is why I wrote the
text above).

If we go with my version, there's an issue of what happens when we're
converting the whole message ("convert" outside a MIME loop) and, say,
three body parts convert OK and one doesn't.  Do we consider that a
"partial conversion", and roll back the conversion on the three
successful ones?  Or do we only worry about making sure the part that
failed is back to its previous state?

Finally, I had an idea for how we could do the testing, which might
satisfy both issues:
Why not have the "convert" action *also* be a test.  Like this:

*** convert with no test ***
       require ["mime", "fileinto", "convert"];
       if header :mime :anychild :contenttype
                 "Content-Type" "image/tiff"
       {
         convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240";
         fileinto "INBOX.pics";
       }


*** convert with test ***
       require ["mime", "fileinto", "convert"];
       if header :mime :anychild :contenttype
                 "Content-Type" "image/tiff"
       {
         if convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"
         {
           fileinto "INBOX.pics";
         }
       }


So it could work either way.  In the case where it's used in a test,
it would evaluate TRUE if it ran with no errors -- that is, the
conversion is supported, the parameters are correct, and no
conversions failed (Q: is it also TRUE if no conversions needed to be
done, or is it only TRUE if at least one conversion was done?).  If
it's used only as an action, with no test, then any failure generates
a runtime error.

What do people think about that?  This would be the first action that
could also be used as a test, so think about whether that's good for
the language.  I like it, and I think it makes things very simple.

Barry