Subject: Sieve mime loop issues list

From: Tony Hansen <[email-masked]>
Date: Thu, 23 Mar 2006 16:59:59 -0500

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 { ... } } }

#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") ?

#3: We need to add some way to look at parameter lists:
    Content-Type: text/plain; charset="foo"

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

	Tony Hansen
	[email-masked]

---

From: Ned Freed <[email-masked]>
Date: Thu, 23 Mar 2006 15:30:29 -0800 (PST)

>     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.)

>     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/*" ...

>     Content-Type: text/plain; charset="foo"

Agreed, but mostly because of RFC 2231.

>     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

---

From: Philip Guenther <[email-masked]>
Date: Thu, 23 Mar 2006 16:56:46 -0800

>Agreed, but mostly because of RFC 2231.

It also avoids problems with comments and quoting (dang structured fields!).

...
>headers. This is actually quite a bit more important than a parameter

Do you mean "the MIME header of inner parts" or do you mean "the
headers of nested message/rfc822 parts"?   If both, how should they
be differentiated?

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Thu, 23 Mar 2006 17:26:01 -0800 (PST)

> headers of nested message/rfc822 parts"?   If both, how should they

AFAIK we have not defined a field that involves an address for a MIME
part. So unless you want to avoid false matches on bogons in MIME parts,
I don't think this makes a difference.

In any case, you probably could rig up something to only test message/rfc822
parts using variables, assuming the traversal is top-down.

Chris Newman also suggests renaming this as foreach, in order to make it
clearer we're still not Turing-complete.

				Ned

---

From: "Nigel Swinson" <[email-masked]>
Date: Fri, 24 Mar 2006 13:10:58 -0000

> 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) 

> anyway. 

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 suggest:
- :type to match against type, 
- :subtype to match against subtype
- :contenttype to match against type/subtype

> >     Content-Type: text/plain; charset="foo"

I currently have:

 MimeClause ::= "x_mime" [COMPARATOR] [MATCH-TYPE]
 <header-list: string-list> [<parameter-list: string-list>] <key-list: string-list>
 MimeClause ::= "x_mime" :filename <key-list: string-list>
 MimeClause ::= "x_mime" :type <key-list: string-list>
 MimeClause ::= "x_mime" :subtype <key-list: string-list>

So if you don't have a :type/:subtype/:filename, then you must specify a list of header names, a list of parameter names, and the search strings.  "type" and "subtype" are supported as psuedo parameter names of the bit before the first ";".  If there are no parameter names, then it matches against the text before the first ";".  :type/:subtype/:filename then become short hands:

mime :type "text"
mime "Content-Type" "type" "text

mime :subtype "plain"
mime "Content-Type" "subtype" "plain"

mime :filename "junk.txt"
anyof (
    mime "Content-Disposition" "filemane""junk.txt"'
    mime "Content-Type" "name" "junk.txt"
)
 
> >     add tests mimeheader, mimeparameter

I prefer

>     address :mime

Over 

> headers. This is actually quite a bit more important than a parameter

I agree

Nigel

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 24 Mar 2006 12:01:16 -0500

Hi Nigel,

>>    mimeaddress

I prefer your preference too - since I will be updating the doc I will go 
ahead with this approach unless there are any objections.

-- 
Cyrus Daboo

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 24 Mar 2006 15:35:30 -0500

On Fri, Mar 24, 2006 at 01:10:58PM -0000, Nigel Swinson wrote:
> 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 agree.  Whether script writers will actually make use of such a
construct may be in question, but I am in favor of at least not
prohibiting it.  Per above, the draft could say that an implementation
must only support only 1 level of nesting but may support more.

> 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.

This because the word ":type" makes one think of "type" part of the
content type description?  (i.e., with a different :tag you wouldn't be
as confused?)  Personally I don't see it as all that confusing, but I
see the point, and a different :name would be reasonable.

> - :contenttype to match against type/subtype

Having just one that selects the entire type/subtype string, allowing
the application of different match-types to the test, would make :type
and :subtype options somewhat redundant.  However, having :type and
:subtype don't really hurt, and are easy to implement.  But I think the
most important point is to have an option to test the entire string,
since as I mentioned

    allof (mime :anychild :type "multipart",
           mime :anychild :subtype "alternative")
and
    mime :anychild :contenttype "multipart/alternative"

are not necessarily equivalent (if the sub-tests of the first one match
different children).  Granted, there aren't that many subtypes that are
duplicated across the mime types world, and the above is not the best
example (maybe something with "xml" would be better), but that doesn't
mean we shouldn't be able to have a reliable atomic test.

> >    mimeaddress

ditto

-mm-

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 28 Mar 2006 02:08:29 +0200

On Fri, 2006-03-24 at 13:10 +0000, Nigel Swinson wrote:

> 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.

> "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.

> - :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.