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.