On Sun, May 01, 2005 at 06:27:14PM -0700, Philip Guenther wrote:
Mark E. Mallett wrote:
4.2 Body Transform ":content"
> The search for MIME parts matching the :content specification is
> recursive and automatically descends into multipart and
> message/rfc822 MIME parts. Once a MIME part has been identified
> as suitable for searching, only its direct contents are searched
> for the key strings.
If a message contains more than one testable part, I assume that the
"body" result is the OR of the tests of all of them,
...
This may seem obvious but it probably needs to be made explicit, no?
Yeah. To clarify, I've replaced the second/last sentence of that
paragraph with:
All MIME parts with matching types are searched for the key
strings.
That doesn't actually do the clarification, though. The question was
whether the search result is the OR of all the tests, or the AND of all
the tests. That is, does a match in just one of the candidate parts
satisfy the test, or does the match have to appear in *all* of the
candidate parts. What I said was that the former seems obvious to me,
but what seems obvious to one person may not be obvious to another, may
not be what was intended, and in any case probably should be said
explicitly.
with a short-circuit exit.
i.e., first match causes the body test to end and
return a true result, whereas a non-match causes the body test to
contine on to the next candidate mime part.
I don't see why short-circuiting needs to be mentioned, as it's
simply an obvious optimization and has no effect on the visibile
behavior.
It follows from the question of whether the match is OR or AND. But
right, as long as that item is clarified, short-circuiting may not
have to be mentioned.
5. Interaction with Other Sieve Extensions
> Regular and wildcard expressions used with "body" are exempt
> from the side effects described in [VARIABLES]. That is, they
> do not set numbered variables ${1}, ${2}... to the input
> values corresponding to wild card sequences in the matched
> pattern.
I remember that this came up last fall, expressed this way:
> QUESTION: Is it okay to have body :matches and
> :regex scans not set variables?
and the (small) concensus was a "yes" answer to that question. I took
that to mean that people thought it was OK for an implementation not to
set the numbered variables-- not that an implementation would be
prohibited from doing so. This prohibition is unfriendly to
general-purpose match logic.
An implementation that wanted to support it could enable capturing
from 'body' matches into variables using another extension...
Yikes. My vote is still to allow the match results to be set from a
body test; requiring another extension just to do that seems like
planning for a patch to correct the lack of it. As always, that's just
MHO; I don't really understand why setting the match result is not
wanted. What's the reason for forbidding it? As I say, it's unfriendly
to a general match implementation. If it's a matter of protecting
against huge match strings, I'd rather see some pragmatic limits (as I
said in the thread previously, along with other bits about pragmatic
limits on body testing).
mm