Since we seem to be in the mood for comments on variables I have
a few of my own to make:
(0) The term "sieve" is used in RFCs to mean several different things;
the title of the document should therefore make it clear what "sieve"
we're dealing with. I suggest a title change to "Sieve Mail Filtering
Language - Variables Extension". I would also suggest a change in the
abstract: "filtering rule sets" -> "sieve mail filtering rule sets".
(1) This draft still uses the old copyright/IPR boilerplate; it needs to be
updated to use the RFC 3667 stuff. (xml2rfc is your friend here; its
a one line change to make it do all the right stuff.)
(2) There are lots of hypenated words in this draft. I don't think the RFC
Editor likes them much. You might consider turning off hyphenation in
whatever tool you are using.
(3) Abstract. "interpolation" -> "intepretation".
(4) Section 3.2 talks about :regex, which probably means we need a reference
to the regex specification. However, I think this can be an informative
reference, since you certainly don't need to understand regex in to
implement variables. (A normative reference would be bad since it would
hold up publication of variables until regex can also be published.)
(6) Section 3.2: "The wild- cards expand greedily." -> "All :matches wildcards
MUST expand greedily."
(7) Isn't the precedence ordering in section 4.1 backwards? That is, don't
you want to do :lower before you do :upperfirst? That's certainly the
effect I'd want, and it appears to be the order the examples call for.
Additionally, while it makes no difference in ASCII, it strikes me that
if case conversion changed the length of a string you'd want the length
of the case-converted result when you specify :length, not the length of
what you started with.
(8) Do we want to make it an error to specify both :lower and :upper, or
both :lowerfirst and :upperfirst? Or at least make it legal to return
an error in this case?
(9) Is 9 numbered variables enough? (It probably is, I just wanted to check
and make sure we'll all OK with it.)
(10) Pointing out that sieves always terminate in the security considerations
is good. However, we probably should state that this doesn't preclude
the construction of scripts that take a long time to evaluate.
(11) Might want to have an informative reference to spamtest/virustest in the
security considerations section when you talk about how sieve isn't
a spam/virus filter facility in and of itself. (Although heaven knows I
have lots of customers who use it this way.)
(12) When it comes to :count, we probably need to specify what it does to
list arguments to string. (This one sure is silly, isn't it?)
Ned