Do you intend :bodyparts to select the mime parts in the message body,
or in the entire message (i.e., does it include or exclude the message
header?) My preference would be the body only, so that one can have
the most flexibility.
I had intended it to be the entire message, but not out of strong
desire. I guess if I was writing a test, I would care less about
where in the email message the entity of interest was and more about
it's prescense. With our header test we aren't told about where in
the headers the header is, and if you have a multipart/alternative
structure or multipart/mixed then I'm not sure there is a logical
distinction in the order. So I think to neatly be able to say "is
there any text/html body part in this email" is more useful than
saying "is there a text/html body part in one of the child body parts?"
I tend to coss the toin in the direction of more options. As you say,
it's hard to predict why one would want to exclude the message header,
however one can't always predict these sorts of things. There's a
tradeoff: on one hand having :bodypart exclude the message header gives
more options, but on the other, one would have to use more SIEVE code
in the overwhelmingly common case.
Originally I thought we should have a concept of "selection" of a
body part and then be able to perform tests on it. Couldn't get
anywhere with the idea though, as I just thought it would end up in a
hell of indexes into arrays of body parts, and also how would you
"select" a body part?
I would like to see a mechanism for creating views (by whatever term)
that would have applicability for a number of sieve functions; were
this available, it could be used in conjunction with the mime
extension. That's yet another conundrum tho: practically speaking, I
wouldn't want to hold up the mime extension for that, yet if the mime
extension includes its own selection facility, it could collide with a
future views capability. (Not that I expect 'views' to have wide
support.)
Perhaps even say that the ":parameter" value is tested using a wildcard
match (a la :matches).
We haven't seen the facility for using wildcards on header names, so
I'm not sure we need it for parameter names either as I think the two
concepts are very similair...
I've actually had people ask for that- and have had occasion to
wish for it myself.
mm