Sieve Email Filtering: Imap4flags Extension
RFC 5232

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

(Lisa Dusseault) Yes

(Jari Arkko) No Objection

Comment (2006-05-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
> The extension decribed in this document doesn't change the implicit
> keep (see section 2.10.2 of [SIEVE]).

s/decribed/described/

(Ross Callon) No Objection

(Brian Carpenter) (was Discuss) No Objection

Comment (2006-05-09)
No email
send info
Nits from gen-art review by Eric Gray:

Section 3, third paragraph, last sentence: "MUST cause a runtime
error" as opposed to "MUST cause runtime error"...

Section 6, first paragraph, last line: "side effect" as opposed to "side affect"...

(Lars Eggert) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

Comment (2006-05-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I did not find this specification very clear.  In particular, the
internal variable was quite mystifying.  I eventually figured out what
it is for, but there is not a description of the intuitive use of the
internal variable.  The internal variable seems to act as a default
for the flags that will be set on a message that is kept or filed.
Nothing actually seems to say this though.  Also calling it the
internal variable is confusing.  However this is non-blocking.

(Russ Housley) No Objection

Comment (2006-05-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The Abstract should not include the [IMAP] reference.  Minor rewrite
  is needed.

  Section 2 should contain the standard sentence from RFC 2119.

(Cullen Jennings) No Objection

Comment (2006-05-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
It would benefit from more use of normative language. For example, I have no idea if you actually have to implement "hasflag" or if it is optional. 

I find this document very hard to understand or follow. It lacks a coherent overview of the environment it fits into and it reads half way like an programmer guide instead of a specification of all the details an implementer needs to know.

The document does not pass idnits (but the important stuff is OK).

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund (was Discuss) No Objection