On fre, 2004-10-22 at 16:28 -0700, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
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".
currently, we have:
3028 Sieve: A Mail Filtering Language.
3431 Sieve Extension: Relational Tests.
3598 Sieve Email Filtering -- Subaddress Extension.
3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions.
3894 Sieve Extension: Copying Without Side Effects.
and then:
XXXX Sieve -- Variables Extension
I've changed it to "Sieve Extension: Variables" to keep it aligned with
2 out of 4.
(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.)
XML is not my friend during editing :-). I'm writing it in good old
roff. probably should have used m4 or something to include the
boilerplate, but I didn't think it'd change so much.
(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.
ok.
(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.)
done.
(6) Section 3.2: "The wild- cards expand greedily." -> "All :matches wildcards
MUST expand greedily."
I don't agree a clarification is needed here, the entire paragraph is
about :matches and nothing else.
(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.
"highest value first". it might be more readable to change this to
"lowest value" and put the table on its head.
(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?
I don't have a problem with making the behaviour undefined.
(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.
perhaps, but I don't really see what that is. what do you have in mind?
pathological match patterns?
(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.)
ok.
(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?)
it already says: "The count of a string list is the sum of the counts of
the member strings."
--
Kjetil T.