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

[Ballot discuss]
The Gen-ART Review by Reviewer: Ben Campbell on 13-Dec-2011 raises
  some points, the authors have responded to them, but the discussion
  has not completed yet.  I believe the document needs to be updated to
  at least address Ben's first point:

  >>> -- section 3.1, paragraph 4: "Implementations MUST NOT generate
  >>> errors for recursive inclusions at upload time, as this would
  >>> force an upload ordering requirement upon script authors /
  >>> generators.  However, if an active script is replaced with a
  >>> faulty script and would remain the active script, an error MUST
  >>> be generated and the upload MUST fail."
  >>>
  >>> These two statements seem contradictory on a quick reading.  In
  >>> particular, how can the latter assertion avoid an upload ordering
  >>> requirement? Or do you mean faulty in some way other than being
  >>> recursive?
  >>
  >> If you're replacing an active script, it has to be correct all the
  >> time, and uploads are atomic only on a per-script basis. There's a
  >> risk that if you're uploading a set of scripts that include one
  >> another, at some intermediate stage while some scripts are uploaded
  >> but not others, they are in an invalid state. The managesieve spec
  >> says that scripts must be validated at upload time. The language
  >> above is trying to say that you can upload all of the scripts that
  >> may include one another in any order without generating errors
  >> immediately, however, if you're replacing an active script or a
  >> script included by the active script, then you DO have to upload a
  >> correct script right from the get-go.
  >
  > Is this just a question of whether the script(s) are replacing
  > active scripts? That is, the license to create a transient invalid
  > state is suspended if if you are replacing an active script? If so,
  > how would one go about updating a set of linked scripts when one or
  > more of them replace active scripts? Should one somehow deactivate
  > the old ones, load all the scripts, then activate them?

[Ballot comment]
Developing a programming language is difficult, particularly when you add tiny features one at a time (like subroutines). It might have been better to think about an upgrade of the sieve model in a more architectural manner. Or maybe the WG already did and I am just not aware of it. In any case, this is just a comment and not a part of my Discuss.

I think your minimum requirement of three levels is a bit too small. If people actually start using this they are likely to engineer script structures that need more, and if not all implementations support that number of levels there will be breakage. I'd say five or ten would be a more reasonable minimum level. But I'm not asking you to put any specific number but rather I'm asking you think about this and make a rational decision based on some basis. (And again, maybe you already have and you just need to tell me what the basis of that decision was.)

[Ballot discuss]
I spent some time thinking about whether I want to say something or not.

But I'll join others in worrying about the issue of recursion, but raise some of the comments to a level of a Discuss.

I should also say that developing a programming language is difficult, particularly when you add tiny features one at a time (like subroutines).  For instance, the recursion discussion is difficult because you've conflated the concepts of module references and actual invocations of those modules during execution time.

It might have been better to think about an upgrade of the sieve model in a more architectural manner. Or maybe the WG already did and I am just not aware of it. In any case, this is just a comment and not a part of my Discuss.

The Discuss is the following. First, as Adrian noted you must define what you mean by recursion, because otherwise implementations are likely to miss that they need to track indirect inclusions as well: A includes B, B includes A. I wonder if it would have been easier just to have the concept of nesting levels and maxing out on them. That's how I would implement this if I was implementing it. No need to track recursion in specific ways.

Second, I think your minimum requirement of three levels is a bit too small. If people actually start using this they are likely to engineer script structures that need more, and if not all implementations support that number of levels there will be breakage. I'd say five or ten would be a more reasonable minimum level. But I'm not asking you to put any specific number but rather I'm asking you think about this and make a rational decision based on some basis. (And again, maybe you already have and you just need to tell me what the basis of that decision was.)

I also think that the active/other script definition for checking recursion is broken, but that was already raised by Russ' Discuss.

[Ballot discuss]
I spent some time thinking about whether I want to say something or not.

But I'll join others in worrying about the issue of recursion, but raise some of the comments to a level of a Discuss.

I should also say that developing a programming language is difficult, particularly when you add tiny features one at a time (like subroutines).  For instance, the recursion discussion is difficult because you've conflated the concepts of module references and actual invocations of those modules during execution time.

It might have been better to think about an upgrade of the sieve model in a more architectural manner. Or maybe the WG already did and I am just not aware of it. In any case, this is just a comment and not a part of my Discuss.

The Discuss is the following. First, as Adrian noted you must define what you mean by recursion, because otherwise implementations are likely to miss that they need to track indirect inclusions as well: A includes B, B includes A. I wonder if it would have been easier just to have the concept of nesting levels and maxing out on them. That's how I would implement this if I was implementing it. No need to track recursion in specific ways.

Second, I think your minimum requirement of three levels is a bit too small. If people actually start using this they are likely to engineer script structures that need more, and if they cannot rely on all implementations u

[Ballot comment]
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?

[Ballot comment]
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

[Ballot comment]
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"?

[Ballot discuss]
The Gen-ART Review by Reviewer: Ben Campbell on 13-Dec-2011 raises
  some points, the authors have responded to them, but the discussion
  has not completed yet.  I believe the document needs to be updated to
  at least address Ben's first point:

  >>> -- section 3.1, paragraph 4: "Implementations MUST NOT generate
  >>> errors for recursive inclusions at upload time, as this would
  >>> force an upload ordering requirement upon script authors /
  >>> generators.  However, if an active script is replaced with a
  >>> faulty script and would remain the active script, an error MUST
  >>> be generated and the upload MUST fail."
  >>>
  >>> These two statements seem contradictory on a quick reading.  In
  >>> particular, how can the latter assertion avoid an upload ordering
  >>> requirement? Or do you mean faulty in some way other than being
  >>> recursive?
  >>
  >> If you're replacing an active script, it has to be correct all the
  >> time, and uploads are atomic only on a per-script basis. There's a
  >> risk that if you're uploading a set of scripts that include one
  >> another, at some intermediate stage while some scripts are uploaded
  >> but not others, they are in an invalid state. The managesieve spec
  >> says that scripts must be validated at upload time. The language
  >> above is trying to say that you can upload all of the scripts that
  >> may include one another in any order without generating errors
  >> immediately, however, if you're replacing an active script or a
  >> script included by the active script, then you DO have to upload a
  >> correct script right from the get-go.
  >
  > Is this just a question of whether the script(s) are replacing
  > active scripts? That is, the license to create a transient invalid
  > state is suspended if if you are replacing an active script? If so,
  > how would one go about updating a set of linked scripts when one or
  > more of them replace active scripts? Should one somehow deactivate
  > the old ones, load all the scripts, then activate them?

[Ballot comment]
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;-)

Upon approval of this document, IANA will register the following Sieve
Extension at http://www.iana.org/assignments/sieve-extensions

Capability name: include
Description: adds the "include" command to execute other Sieve
scripts, the "return" action from an included
script, and the "global" command and "global"
variables namespace to access variables shared
among included scripts.
RFC number: this RFC
Contact address: the Sieve discussion list

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Sieve Email Filtering: Include Extension) to Proposed Standard


The IESG has received a request from the Sieve Mail Filtering Language WG
(sieve) to consider the following document:
- 'Sieve Email Filtering: Include Extension'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Sieve Email Filtering "include" extension permits users to
  include one Sieve script inside another.  This can make managing
  large scripts or multiple sets of scripts much easier, and allows a
  site and its users to build up libraries of scripts.  Users are able
  to include their own personal scripts or site-wide scripts.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sieve-include/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sieve-include/


No IPR declarations have been submitted directly on this I-D.

1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Barry Leiba is the document shepherd. I have reviewed this version, and am satisfied that it's ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has adequate review, and I have no concerns. There were no significant controversies to point out. Early prototype implementations uncovered some issues that were resolved in later versions of the document, and work on the document was prolonged to get experience with these implementations.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I have no concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no concerns. There is no IPR involved.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is consensus of the working group, as a whole, behind it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes; the document is clean.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All references are properly separated and labelled. There are no downward references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section is correct and adequate; there is one IANA action.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The formal grammar, at the beginning of section 3.2, is correct and is consistent with the grammar in the other Sieve documents.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This was a popular extension within the working group. It was under active development for about a year and a half, during which time a number of suggestions were discussed, and issues were ironed out. It then went dormant for a year because the editors (also the two chairs) were very busy, and the working group as a whole was very quiet. Once revived, it was finished up with final editing. There are no controversies at this point, and there were no major controversies during the document's development.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

The issues that were worked out during document development were mostly dealing with how to specify the included scripts, how multiple included scripts interact, and how to resolve conflicts among the different scripts. The working group expects that this isn't the final version, and that it will be updated after more experience in practical use -- that is, what's here is appropriate for Proposed Standard. There are at least two implementations of draft versions, and at least two other implementors plan to implement the final version.