Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 01 Feb 2005 17:21:06 +0000

Alexey Melnikov wrote:

> I would like to solicit your attention to the following draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-00.txt
>
> I've sent few editorial suggestions to the author, but I don't think 
> they should delay the WGLC any further.
> The WGLC starts today. Due to winter holiday season it would last for 
> 4 weeks, i.e. till January 18th.
> And I hope that Tim can submit 3028bis before that, so that the WG has 
> time to check if there are any interactions between the two documents.
>
Hi group,
The WGLC is over and I haven't seen any comments on the document. This 
means that it is either perfect, or that people didn't have time to 
review it.

Ned and myself have reviewed the document. Anybody else?
Can I ask people who have reviewed the document to email me directly and 
state that they found no problems with the document. I would appreciate 
any feedback by February 7th (next Monday). Thanks!

Alexey

---

From: [email-masked]
Date: Tue, 01 Feb 2005 09:59:30 -0800 (PST)

> Ned and myself have reviewed the document. Anybody else?

FWIW, I looked it over again and I think it is ready to go. The only
glitch I found was that the [SPAMTEST] reference should be changed
to refer to RFC 3685.

				Ned

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 2 Feb 2005 01:31:17 -0000

> any feedback by February 7th (next Monday). Thanks!

Just noticed this: 
      # Imagine the header
      # Subject: [acme-users] [fwd] version 1.0 is out
      if header :regex "Subject" "^[(.*)] (.*)$" {
          # ${1} will hold "acme-users] fwd"
      }

Shouldn't the comment be:
          # ${1} will hold "acme-users] [fwd"

Cheers,

Nigel

---

From: [email-masked]
Date: Tue, 01 Feb 2005 18:05:42 -0800 (PST)

>           # ${1} will hold "acme-users] [fwd"

Sure looks like it to me. Nice catch.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 04 Feb 2005 12:42:45 +0100

> any feedback by February 7th (next Monday). Thanks!

I've updated the document and made quite a few changes, although they
are all editorial.

0.2.6.  Changes since -00 (WG series)

a)   added example for string test

b)   moved introductory text for MODIFIER from 5.1 into 5.0

c)   added Syntax line for MODIFIER.

d)   added comment to an example showing that the non-greedy "*" still
     matches everything due to implicit anchors.

e)   added example of expansion of string with unbalanced braces.

I haven't submitted this, because I'm not sure if it should be done by
me or the chair?
-- 
Kjetil T.

---

From: "Nigel Swinson" <[email-masked]>
Date: Fri, 4 Feb 2005 15:50:45 -0000

> a)   added example for string test

In the rest of your examples, the # comment inside the {} is only indented 
once, but here it's indented several times?  Looks a little odd....

> c)   added Syntax line for MODIFIER.

Aren't you missing an indent on syntax line for Modifiers?

>     matches everything due to implicit anchors.

I think this is an important enough concept to make more explicit.  Without 
this concept, I don't believe it's possible to get the entirity of a mail 
header into a Sieve Variable without using the regex extension, and I think 
this is something people will want to do.  Perhaps amend this paragraph:

   For ":matches", the list will contain one string for each wildcard
   ("?" and "*") in the match pattern.  Each string holds what the
   corresponding wildcard expands to, possibly the empty string.  The
   wildcards match as little as possible (non-greedy matching).

Not sure how it should be modified, I'd probably change it to say it does 
greedy matching ;o)

Nigel

---

From: [email-masked]
Date: Fri, 04 Feb 2005 14:14:57 -0800 (PST)

> ...

> I haven't submitted this, because I'm not sure if it should be done by

The chair only has to deal with -00 submissions of WG drafts. After
the -00 version you should be able to do it yourself.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 5 Feb 2005 17:01:51 -0500

On Fri, Feb 04, 2005 at 12:42:45PM +0100, Kjetil Torgrim Homme wrote:
> Document: draft-ietf-sieve-variables-01.txt           University of Oslo

Hi-

I would like to include by reference, without going on about it further
here, my earlier remarks about choices of keywords that might be likely
to collide with future language enhancements.  Those issues are still
important, if only to me.

Also I have a few new niggling comments, as follows.

3.

   > "When a string is evaluated ..."

I'm not sure that the concept of evaluating a string has been
introduced, so the "when a string is evaluated" is not strictly clear
(even if everybody probably knows what it means).  So perhaps lay the
groundwork of saying that this extension enables interpretation of
strings at the moment they are used during runtime , and then say "when
a string is interpreted..."   or just change the word to "interpreted" :-)

3.2.  Numbered variables

   > For ":matches"...
   > The wildcards match as little as possible (non-greedy matching).

Even though I am in favor of this: this is a refinement of RFC3028
(which is silent on the greediness issue).  Does this need to be
explicitly stated?  I would think this should be an item for 3028bis or
whatever the next SIEVE base draft is, as well.  (Being able to specify
the :matches greediness would be a plus.)

   > The first string in the list has index 1.  If the index is out of
   > range, the empty string will be substituted.  Index 0 returns the
   > number of strings in the list as a decimal number.

Hmm, I glossed over this before.  There are other environments
(including typical regex implementations) where it's common to have
submatch 0 represent the entire matched string.  Access to the number of
strings is useful, but so is access to the entire match (probably more
so than the number of matches, since that's predictable from the pattern
used).  Since it's nice to be consistent with what people might already
be used to, I'd recommend having index 0 be the entire match, and something
else be the count of the matches.  Maybe a special ${#} for the number
of matches.

Or keep ${0} as the count, and add something else (e.g. ${*}) as the
complete match string.

4.  Action set

   > An illegal name MUST cause a syntax error.

"MUST be detected as a syntax error" ?  (at compile time?  runtime?)

4.1.  Modifiers

   > More than one modifier can be specified, in which case
   > they are applied according to this precedence list, highest value
   > first:

I think this has been addressed before, but "highest value" is still
ambiguous because "highness" isn't really an attribute of a number, and
the word "precedence" implies doing things in numeric order, 1, 2, 3.
So some people, if not most people, will think of the "highest
precedence value" as having the smallest numeric value.  Maybe:

   More than one modifier can be specified, in which case they are
   applied in reverse order of precedence value, i.e. from largest to
   smallest, according to this table:

I would personally make it smallest value first, but either way as long
as it's clear.

5.  Test string

I agree with another commenter's earlier remark that :count is silly.
Unless the intent is to count the number of matches, rather than the
number of strings?  It doesn't say that, though-- and I don't really
know why that would be useful, either.

Yours,
-mm-

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Mon, 07 Feb 2005 00:41:26 +0100

> important, if only to me.

please put forward suitable wording for use in the document?

> a string is interpreted..."   or just change the word to "interpreted" :-)

I agree, "interpreted" is better.

> the :matches greediness would be a plus.)

I think it is essential that greediness behaviour is defined.  it cannot
be observed by the mechanisms in 3028 (or 3028bis) since it doesn't
change _what_ matches, only _how_ it matches, so it is natural that the
facility which makes observation possible also defines what should be
observed.

> else be the count of the matches.  Maybe a special ${#} for the number

I think too little is gained by this change to incorporate it at this
stage.

> Or keep ${0} as the count, and add something else (e.g. ${*}) as the

explicit is better than implicit -- users can just add an extra pair of
parentheses.  (this only applies to :regex.  for :matches, the match
string is always equal to the source string.)

> "MUST be detected as a syntax error" ?  (at compile time?  runtime?)

from RFC 3028, 2.10.6:

   In any programming language, there are compile-time and run-time
   errors.

   Compile-time errors are ones in syntax that are detectable if a
   syntax check is done.

so compile-time.

> I would personally make it smallest value first, but either way as long

I can do s/highest/largest/ if you think that's better.  introducing
some "order of precedence value" will surely only muddle the issue.

> know why that would be useful, either.

leaving it out will introduce an area of undefined behaviour, which IMO
would be bad and unnecessary.
-- 
Kjetil T.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 17 Feb 2005 18:44:21 -0500

[sorry, I'm slow]

> I think too little is gained by this change to incorporate it at this

My prediction is that something returning the entire match string will
be much more useful than something returning the count of matches.
I'd rather have both, though, and providing them is really a minor thing,
no matter how late it is.

> string is always equal to the source string.)

Indeed it is- it's still useful to be able to access it.

>    Compile-time errors are ones in syntax that are detectable if a

Just to be clear, my main comment was about the wording "must cause a
syntax error" being wrong.  The parenthesised "compile time or runtime"
was a side comment and yeah, it's probably obvious that it's compile
time.

-mm-

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 18 Feb 2005 01:10:16 +0100

> be much more useful than something returning the count of matches.

I agree, I can't really think of a use case for the count, so I probably
shouldn't have included it in the first place.

> no matter how late it is.

anyone else have an opinion?

>> > [${0} is the match, ${#} is the count]

${*} (shell) or ${&} (sed, Perl), I guess.  ${0} as match corresponds to
e.g. awk.  ${:} as in Python's [:] could work, too, but is strange
without the range.  so many options ...

> Indeed it is- it's still useful to be able to access it.

you're right, that's actually awkward to do with :matches without this
feature:

   if header :matches ["To", "Cc"] ["kj*", "za*"]

the above needs to be replaced by four individual statements.  whether
that is _compelling_, I'll leave for someone else to say :-)

> was a side comment and yeah, it's probably obvious that it's compile

what's wrong?  you mean s/cause/handled as/ ?

-- 
Kjetil T.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 17 Feb 2005 22:39:30 -0500

> what's wrong?  you mean s/cause/handled as/ ?

I guess I'm just being anal.  I think of an invalid name as being a
syntax error rather than causing a syntax error.  That was behind "must
be detected as a syntax error."

mm

---

From: "Nigel Swinson" <[email-masked]>
Date: Fri, 18 Feb 2005 11:56:53 -0000

> anyone else have an opinion?

My expectation would be that ${0} is the match.  I've never had a need for the number of parts that matched.  It was something I read in the draft though "oh that's different to what I expect" but then I didn't have a big problem with it so didn't mention it.  Indeed as already mentioned, adding another set of () is all you need if ${0} has a different meaning.

Nigel

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 18 Feb 2005 12:57:48 +0100

> be detected as a syntax error."

ah, it didn't register as suggested replacement text, I'm just blind.
fixed, thanks.
-- 
Kjetil T.