Sieve Email Filtering: Body Extension
RFC 5173

[Ballot comment]
Review by Christian Vogt:

Draft-ietf-sieve-body-07 extends the Sieve email processing language by
a command for searching a text string in the body of an email.

The document is concise and (with few exceptions mentioned below) clear,
and should therefore considered ready for publication once the comments
below have been addressed.


Conceptual:

Section 3 specifies that a search for an empty string should return
"false" for emails that do not have a body, and "true" for emails that
have an empty body.  I believe that such different handling of similar
inputs (no body vs. empty body) may be confusing for users who are not
Sieve experts, and hard to debug for Sieve expert.  Unless the search
result cannot be the same for both cases for substantial reasons, the
search results should be redefined to be the same.  If there is
substantial reasons for the search results to be different, then the
draft should provide rationale for such distinction.


Editorial:

(1)  Section 2, 3rd paragraph:  What is a "capability string"?  If this
is an expression already defined in [SIEVE], then [SIEVE] should be
cited near the occurrence of "capability string".  Otherwise,
"capability string" should be defined in this document.

(2)  Section 4.3, 2nd paragraph:  Unstated what the difference between a
body transform of ':text' and a body transform of ':content "text"' is.
The difference can be derived by the reader, of course, but the
document is incomplete by leaving it unstated.

(3)  Section 5, 2nd paragraph:  s/wild card/wildcard/ and s/set
match/set-match/

[Ballot comment]
From Gen-ART Review by Elwyn Davies; however, I think this is even
  more important than indicated by Elwyn.  Elwyn said:

  A pointer is given to the SIEVE base document, but I wonder if this
  document should note that ABNF is used to specify syntax and provide
  the appropriate reference.

[Ballot discuss]
The grammar for test body specified in section 3 is unclear. 
Specifically, the grammar implies that the parameter ordering is
comparator; match-type; body transform; and .
However, the body-transform appears before the comparator in all
the examples, and the match-type is generally omitted.  Is order
important for the body parameters?

The reference to [SIEVE] the COMPARATOR and MATCH-TYPE key words
is helpful, but leaves some unanswered questions:

(1) What is the COMPARATOR if it is omitted?  Based on [SIEVE], I
am guessing "i;ascii-casemap" but a clearer statement would be
helpful.

(2) What values for COMPARATOR need to be supported for compliance
with this specification?  Again, I assume that "i;octet" and
"i;ascii-casemap" are required but clarity is needed.

(3) Can an implementation restrict the MATCH-TYPE features to a
subset of the features in [SIEVE]?  Specifically, is a compliant
implementation required to support "is:" and "matches:", or the
indefinite length wildcards ("*") in "matches:".  These features
seem ill-suited to the test body.

IANA Last Call Comments:

*** IANA Has Questions:  ******

This request is missing two parts of the application
template, the "keyword" and the "arguments". Please
complete those entries prior to approval. Based on
the text of the document the keyword is "body" and
the arguments should be a summary of sections 3 and 4.

************

Upon approval of this document, the IANA will make
the following assignments in the "Sieve Extensions"
registry located at

http://www.iana.org/assignments/sieve-extensions

Capability name: body
Capability keyword: ???
Capability arguments: ???
Description: adds the 'body' test for matching
against the the body of the message being processed
RFC number: [RFC-sieve-body-06]
Contact Address: Jutta Degener

We understand the above to be the only IANA Action
for this document.

[rest of PROTO writeup]

Technical Summary

The SIEVE body extension adds tests for the occurrence of one or more
strings in the body of an email message.

The draft has a detailed description of how interactions with other
SIEVE extensions/actions are handled.

The security considerations section covers several identified security
concerns.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.

Document Quality

A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this specification published as an RFC.

Personal

Document Shepherd: Cyrus Daboo
AD: Lisa Dusseault

SIEVE body extension WG Chairs Write-up for IESG.

draft-ietf-sieve-body-05.txt - Proposed Standard

  (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?
         
          Shepherd: Cyrus Daboo  I have
          personally reviewed this document and believe it ready for
          submission to the IESG.

  (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?
         
          It has had adequate review from WG members. Not from non-WG
          members. No concerns with the nature of those reviews.

  (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?
         
          No.

  (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.
         
          No concerns with this document.

  (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 strong WG consensus behind this.

  (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
          http://www.ietf.org/ID-Checklist.html 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?
         
          ID nits were checked. Whilst some warnings appear, the draft
          in fact was correct.

  (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].
         
          References are split into two sections. There is one normative
          reference to the SIEVE base spec revision draft which has
          already been submitted to the IESG. There is one informative
          reference to the SIEVE variables extension draft that is in
          the RFC Editor queue waiting on the revised base spec.

  (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 [RFC2434].  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?
         
          Yes.

  (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?
         
          Yes.

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

          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?

          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?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director? Is an IANA expert needed?