Re: [sieve] I-D Action: draft-ietf-sieve-convert-02.txt
Alexey Melnikov <alexey.melnikov@isode.com> Fri, 19 August 2011 11:42 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C743421F86C0 for <sieve@ietfa.amsl.com>; Fri, 19 Aug 2011 04:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.176
X-Spam-Level:
X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eviMEU4phycQ for <sieve@ietfa.amsl.com>; Fri, 19 Aug 2011 04:42:15 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAE21F86AB for <sieve@ietf.org>; Fri, 19 Aug 2011 04:42:14 -0700 (PDT)
Received: from [188.29.207.116] (188.29.207.116.threembb.co.uk [188.29.207.116]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <Tk5MSgALhESJ@rufus.isode.com>; Fri, 19 Aug 2011 12:43:09 +0100
Message-ID: <4E4E4C40.2060306@isode.com>
Date: Fri, 19 Aug 2011 12:42:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <barryleiba@computer.org>
References: <20110725181813.15532.90958.idtracker@ietfa.amsl.com> <4E30197D.4060803@rename-it.nl> <4E3AB627.1060005@isode.com> <4E408AA5.2060106@rename-it.nl> <CAC4RtVANdzs-i8OHhfzH=QCXyh2m-bmNqy_zK+pzQ0VnO8ovkQ@mail.gmail.com>
In-Reply-To: <CAC4RtVANdzs-i8OHhfzH=QCXyh2m-bmNqy_zK+pzQ0VnO8ovkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: quoted-printable
Cc: sieve@ietf.org
Subject: Re: [sieve] I-D Action: draft-ietf-sieve-convert-02.txt
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2011 11:42:15 -0000
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] I-D Action: draft-ietf-sieve-convert-02.t… internet-drafts
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Stephan Bosch
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Alexey Melnikov
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Stephan Bosch
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Barry Leiba
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Alexey Melnikov
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Barry Leiba
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Alexey Melnikov
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Barry Leiba
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Cyrus Daboo
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Alexey Melnikov
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… NED+mta-filters
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Stephan Bosch
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Cyrus Daboo
- Re: [sieve] I-D Action: draft-ietf-sieve-convert-… Barry Leiba