Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S08gn1027202; Mon, 27 Mar 2006 17:08:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S08gVC027201; Mon, 27 Mar 2006 17:08:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.10.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S08e69027185 for ; Mon, 27 Mar 2006 17:08:41 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1FO1lE-0005eY-N6; Tue, 28 Mar 2006 02:08:36 +0200 Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1FO1l8-0007gf-Tz; Tue, 28 Mar 2006 02:08:30 +0200 Subject: Re: Sieve mime loop issues list From: Kjetil Torgrim Homme To: Nigel Swinson Cc: IETF MTA Filters List In-Reply-To: <003401c64f44$657bf230$9b42c050@nigelhome> References: <44231A5F.6050605@att.com> <01M0EFER83N6000078@mauve.mrochek.com> <003401c64f44$657bf230$9b42c050@nigelhome> Content-Type: multipart/alternative; boundary="=-h7Ln7RcOAxUVddDOzd9t" Date: Tue, 28 Mar 2006 02:08:29 +0200 Message-Id: <1143504509.10517.47.camel@mattugur.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.214, required 12, autolearn=disabled, AWL -0.27, HTML_30_40 0.06, HTML_MESSAGE 0.00, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-h7Ln7RcOAxUVddDOzd9t Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2006-03-24 at 13:10 +0000, Nigel Swinson wrote: > > > #1: Need to deal with nested for_every_part loops. What will this do: > > > for_every_part { if (some test here) { for_every_part { ... } } } > > > > My inclination is to ban them, or at least allow an implementation-defined > > limit which can be set to 1. (Actually, such a limit is allowed implicitly for > > almost anything in sieve by the base spec.) > > > I would like the nested for_every_part to operate on the child nodes > of the current context body part, not always operate on all the body > parts of the root message. This to me is the obvious behaviour. If > Ned wants to (understandably) ban them from his implementation, that's > fine by me ;o) I don't see the point. for_every_part will recurse through all headers, so you'll do the test everywhere anyway. if you like, you can set a variable[1] and conditionally run "for_every_part" once more afterwards. if "for_every_part" allowed you to restrict recursion (ie. a modifier ":onelevel"), I can possibly see the utility of nested calls. [1] of course not guaranteed to be available, but assuming implementation support, if the admin turned off variables, he's not likely to support mime loops either. > Although it isn't very explicit, I think I'm right in saying the > default match type for mime is "is"? So that means if :type matches > against type/subtype, then I would be very confused if I wrote :type > "text" and it didn't match against text/plain. I'd think :type "text" was a syntax error or at best a leftover from RFC 1049. I'd expect the "text/*" syntax I see for MIME types everywhere else, but of course ":is" must (probably MUST, but I didn't check) be the default match type for consistency with the rest of Sieve. > I suggest: > - :type to match against type, > - :subtype to match against subtype > - :contenttype to match against type/subtype my suggestion: * :type to match against full "media type/subtype" * :mediatype to match against just "media type" * :subtype to match against just "subtype" although I _really_ think the latter two are redundant. -- Kjetil T. --=-h7Ln7RcOAxUVddDOzd9t Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2006-03-24 at 13:10 +0000, Nigel Swinson wrote: 
> > #1: Need to deal with nested for_every_part loops. What will this do:
> >     for_every_part { if (some test here) { for_every_part { ... } } }
> 
> My inclination is to ban them, or at least allow an implementation-defined
> limit which can be set to 1. (Actually, such a limit is allowed implicitly for
> almost anything in sieve by the base spec.)
I would like the nested for_every_part to operate on the child nodes of the current context body part, not always operate on all the body parts of the root message. This to me is the obvious behaviour. If Ned wants to (understandably) ban them from his implementation, that's fine by me ;o)

I don't see the point.  for_every_part will recurse through all headers, so you'll do the test everywhere anyway.  if you like, you can set a variable[1] and conditionally run "for_every_part" once more afterwards.  if "for_every_part" allowed you to restrict recursion (ie. a modifier ":onelevel"), I can possibly see the utility of nested calls.

[1] of course not guaranteed to be available, but assuming implementation support, if the admin turned off variables, he's not likely to support mime loops either.

Although it isn't very explicit, I think I'm right in saying the default match type for mime is "is"? So that means if :type matches against type/subtype, then I would be very confused if I wrote :type "text" and it didn't match against text/plain.
I'd think :type "text" was a syntax error or at best a leftover from RFC 1049.  I'd expect the "text/*" syntax I see for MIME types everywhere else, but of course ":is" must (probably MUST, but I didn't check) be the default match type for consistency with the rest of Sieve.

I suggest:
- :type to match against type, 
- :subtype to match against subtype
- :contenttype to match against type/subtype

my suggestion: <>
  • :type to match against full "media type/subtype"
  • :mediatype to match against just "media type"
  • :subtype to match against just "subtype"
    although I _really_ think the latter two are redundant.
    -- 
Kjetil T.
    --=-h7Ln7RcOAxUVddDOzd9t--