Re: Sieve mime loop issues list

[Ned Freed <[e-mail]>]

> 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