Here is the list of issues with the MIME LOOP draft that need to be
worked on, as discussed at the Sieve meeting this week.
#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.)
#2: Need to decide if there would be a "mime" shorthand for testing the
type/subtype, without requiring
if allof (mime :type "multipart", mime :subtype "alternative") ?
How about getting rid of :subtype and making :type check the whole thing? A
subtype is only meaningful in the context of a particular type; the only
exception to this are suffix tags, and checking those would require :matches
anyway. That is, there's no practical difference between
if mime :subtype :matches "*+xml" ...
and
if mime :type : matches "*+xml" ...
And :matches can easily be used to check the primary type by itself. I see no
strong reason to prefer
if mime :type "text" ...
over
if mime :type :matches "text/*" ...
#3: We need to add some way to look at parameter lists:
Content-Type: text/plain; charset="foo"
Agreed, but mostly because of RFC 2231.
The following issues/comments were raised at the meeting:
interactions with variables
notifications
notifications to calendar service
address tests, exists tests
add tests mimeheader, mimeparameter
I'll repeat that I have no real preference between
header :mime
exists :mime
address :mime
and
mimeheader
mimeexists
mimeaddress
but I do want to see some way to do address and exists tests on inner
headers. This is actually quite a bit more important than a parameter
test IMO.
Ned