In section 1, I suggest changing
Sieve interpreters that don't support integration with IMAP SHOULD
ignore this extension.
to
This extension is only appropriate for sieve interpreters that
support integration with IMAP.
(What does it mean for an interpreter to 'ignore' an extension?)
Why is the [Variables] reference mixed cased instead of being
[VARIABLES]?
I'm not sure it's clear that the "variables" extension is 'present' if
and only if it has actually been used with "require". (You can't use
the explicit variable name parameters if the "variables" extension is
supported by the implementation but has not been enabled with
"require".) Perhaps the wording of the last paragraph of section 1
could be tweaked to avoid that ambiguity?
The ignoring of extra spaces in flag lists should include leading and
trailing spaces. Should tabs and CRLF pairs also be ignored? That
would let applications use multiline literals:
addflag "flagvar" text:
\deleted \answered
.
I think the third sentence of section 3.2 should be flipped around, if
just to avoid "MAY NOT" (while "MAY" is an RFC 2119 keyword, "MAY NOT"
isn't!). Indeed, I would give the implementation even more leeways,
ala:
The addflag action MAY alter the flag list in any way that leaves the
its semantics as a set of case-insensitive words unaltered. For
example, it may reorder the flags, alter the case of the letters in
them, or add or remove duplicates or extraneous spaces. Scripts
SHOULD NOT make assumptions about the ordering of flags in lists or
the preservation of their case.
Hmm, written like that, that chunk probably belongs in section 3 and not
3.2, especially when generallized to cover "setflag" and "removeflag" as
well.
The above also obsoletes the second paragraph of section 6 ("A script
interpreter..."), which seemed oddly placed to me anyway.
The third paragraph of section 4 regarding "hasflag" and reordering
makes no sense to me. "hasflag" must split the supplied list of flag
and then iterate across it, but since it returns true if *any* of the
flags are present, the relative order of the flags doesn't matter, no?
There's no way to test whether a variable contains _only_ certain flags,
but I don't think that's needed either.
The two sample implementations of "addflag" should be next to each
other.
The sample "removeflag" implementation in section 6 is incorrect, as it
will only remove a single occurence of the given flag. (Even if
"addflag" performs duplicate elimination, "removeflag" must still handle
multiple occurences as the user may have altered the variable directly
with "set".)
Philip Guenther