0.2.2 says "only one forward should be allowed per message". Why? I
might want to forward a message to multiple accounts, perhaps I have an
account for my pager and one for my PDA.
Two issues here: Ease of implementation (some environments may find it
difficult to provide for multiple forwards) and potential risks (could be
misused as a mailing list mechanism of sorts).
On the other hand, I agree that multiple forwards can be useful.
0.3 discusses what happens if an error occurs. I think this is a
quality-of-implementation issue. I have a parser and an interpreter
built to -03, and it parses first, so that if can abort the
interpretation if there are any errors. But I don't want to impose
that on other implementers.
I've done the same thing and agree with your reasoning.
1. says "if the MTA ... lacks the power to sort into separate
mailboxes, as is the case under POP3, the MUA must do filtering into
local disk folders." I'm not sure what this is trying to say (can't
use Sieve with POP3, or when using POP3, sorting into folders can only
be done by MUA), but I feel it is important that Sieve be usable with
POP3. The fileinto action should be optional.
Agreed.
2.7: I think we should tighten up the syntax for tagged arguments. At
a minimum, they should only appear after the keyword. I think we can
go further, and for each tagged argument, specify where it must appear.
I realize you are trying to make the language open-ended enough to
support all sorts of extensions, but I also think it needs to be easy
to parse.
I agree. I'm also not comfortable with turning contains into :contains,
is into :is, and matches (I guess) into :matches.
2.11: I think the short-circuit evaluations do not need to be a MUST.
This isn't a language with pointers and variables, so there is no
danger of something like "if ( p != NULL && *p == 'c' )".
Agreed.
4.1: I think reject also needs to be optional to implement. In some
environments it may not be possible to generate a DSN, or it may be
possible to cause one to be generated but not to change the text.
Unfortunately I have to agree.
7.2: I think we should have two namespaces: vendor and standard. The
vendor tree starts with "vnd." (as elsewhere) and is registered
first-come, first-served. Everything else is for standards, and must
be published in a standards-track or IESG-approved experimental RFC.
I think this would be fine.
Ned