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

Hi Barry,

Barry Leiba wrote:

>First, as I said on the mic in Québec, thanks, Stephan, for great
>reviews of convert and imap-sieve.
>
+1.

>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).
>
"I've asked you and you ignored me" behavior doesn't seem right in 
Sieve. I don't think any other extension does that.
If we really want to have both (strict conversion and "best effort" 
conversion), then maybe we should have a tagged argument to signal that.

>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?
>  
>
I think I prefer a tagged argument (see above) to control this.

>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?).
>
I think "no conversion is needed" is a success case.

>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.
>
I don't mind that. But I don't think that that should imply any general 
correlation between actions and tests for all future extensions we might 
design.

_______________________________________________
sieve mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sieve