Subject: More comments on draft-homme-sieve-variables-04

From: [email-masked]
Date: Fri, 22 Oct 2004 16:28:14 -0700 (PDT)

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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sun, 24 Oct 2004 05:09:13 +0200

>     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.

>     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.

>     whatever tool you are using.

ok.

>     hold up publication of variables until regex can also be published.)

done.

> (6) Section 3.2: "The wild- cards expand greedily." -> "All :matches wildcards

I don't agree a clarification is needed here, the entire paragraph is
about :matches and nothing else.

>     of the case-converted result when you specify :length, not the length of

"highest value first".  it might be more readable to change this to
"lowest value" and put the table on its head.

>     both :lowerfirst and :upperfirst? Or at least make it legal to return

I don't have a problem with making the behaviour undefined.

>      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?
  
>      have lots of customers who use it this way.)

ok.

>      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.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sun, 24 Oct 2004 05:09:13 +0200

currently, we have:

and then:

ok.

done.

  

ok.

-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sun, 24 Oct 2004 05:09:13 +0200

currently, we have:

and then:

ok.

done.

  

ok.

-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 24 Oct 2004 10:59:56 -0400

Hi Kjetil,

> I've changed it to "Sieve Extension: Variables" to keep it aligned with

Actually I was going to suggest to all authors that we use 'SIEVE Email 
Filtering' in all titles and abstracts (we can argue about capitalization 
of SIEVE if you want...). I think that addresses Ned's point about 
clarifying 'sieve' a little better. When we get around to revising the 
existing rfc extensions we should change those as well.

-- 
Cyrus Daboo

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sun, 24 Oct 2004 19:04:07 +0200

> existing rfc extensions we should change those as well.

well, it would have to be "e-mail filtering", since this has very little
to do with enamel :-)

pedantically yours,
-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sun, 24 Oct 2004 19:29:55 +0200

> well, it would have to be "e-mail filtering", since this has very little

putting a leash on my hobby horse, the obvious solution is of course to
use the form which 3028 and most other e-mail related standards are
using: "mail".  (131 "mail", 3 "email" and 7 "e-mail".)

still a pedant,
-- 
Kjetil T.