Skip to main content

Sieve Email Filtering: Include Extension
draft-ietf-sieve-include-15

Yes

(Pete Resnick)

No Objection

(Dan Romascanu)
(David Harrington)
(Jari Arkko)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 15 and is now closed.

Pete Resnick Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-01-02) Unknown
I think it would be helpful if you spent more time explaining what you
mean by recursion. Direct recursion is (of course) a lot easier to spot
than general (by menas of indeirections) recursion. But it is the 
general case you need to protect against and that is potentially 
considerably more complicated for an implementation to police. Since
the consequences are just as bad, and since it may be harder for the 
coder to realise that they have transgressed, I think you should call it
out explicitly.

Perhaps add a definition of recurssion to Section 2, and then note the
implication for tracking all nested script names in 3.1
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Harrington Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection (2012-01-04) Unknown
Section 3.1 states:

   An error MUST be generated when such a script is executed.

However, Section 3.2 states:

   Implementations MUST NOT generate an error if an "include :once"
   command names a script whose inclusion would be recursive; in this
   case, the script MUST be considered previously included and therefore
   "include :once" will not include it again.

These two are in conflict. I suggest changing the text in Section 3.1 as follows:

   An error MUST be generated when such a script is executed, except 
   as noted under Section 3.2.

In Section 3.2:

   The ":optional" parameter indicates that the script may be missing.

I'd change "may" to "MAY" or (to avoid confusion with "might be missing") say "is allowed to be absent" or somesuch.

Section 3.4.1 states:

   If a "global" command is given the name of a variable that has
   previously been defined in the immediate script with "set", an error
   MUST be generated either when the script is uploaded or at execution
   time.

Does that impose an ordering requirement on script uploads?

Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2012-01-01) Unknown
1) s3.2: Contains the following:

   The "include" command takes an optional "location" parameter, an
   optional ":once" parameter, an optional ":optional" parameter, and a
   single string argument representing the name of the script to include
   for processing at that point.

Shouldn't the "optional"s be "OPTIONAL" to ensure they match they ABNF?

2) s3.2: Contains the following:

   Note: It is RECOMMENDED that script authors / generators use the
   ":once" parameter only when including a script that performs general
   duties such as declaring global variables and making sanity checks of
   the environment.

Can you rephrase this so the requirement isn't in a "note"?
Stephen Farrell Former IESG member
No Objection
No Objection (2011-12-30) Unknown
Is SIEVE turning into a fully-fledged programming language? 
I guess I wonder if that's happening by design or by accident.
(Not that I know which would be better;-)
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown