Hi,
nitpicking:
3. Sieve Loops
5th(ish) paragraph contains:
> If that
> MIME part is a terminal MIME part (i.e. does not contain other MIME
> parts) then the nested "for_every_loop" is simply ignored.
I believe this intends to say
... the nested "for_every_part" loop is imply ignored.
==========
4.1. Test "header"
9th paragraph:
> When used inside the context of a "for_every_part" iterator, and with
> an ":anychild" tagged argument, the "header" test will examine the
> current MIME part context and all it's nested MIME body parts,
> returning true if any of them satisfies the test.
"it's" should be "its" -- picky, picky.
==========
9.2. Example 2
In the example, the "enclose" action:
> enclose :subject "Warning" :text
> WARNING! The enclosed message contains executable attachments.
> These attachments types may contain a computer virus program
> that can infect your computer and potentially damage your data.
>
> Before clicking on these message attachments, you should verify
> with the sender that this message was sent by them and not a
> computer virus.
> .
needs to end with a semicolon.
==========
less nitty:
I was about to go into some stuff about how I thought it would be better
to lay a fundamental foundation of MIME awareness on which this
extension could be layered; about how :mime not only seems superflous
but conflicts with :mime syntax and meaning in other extensions; about
how I'd rather see a generalized parameter extraction for headers that
had a parameter-list syntax (as opposed to :type and so forth). But
then I realized I said a bunch of that last summer, but apparently
without any sympathy :) That's the way it goes, but just for reference,
I still am of many of these opinions (and perhaps others ...):
http://www.imc.org/ietf-mta-filters/mail-archive/msg03658.html
even though I see I fumble-fingered some bit(s) of it.
Yours,
mm