Skip to main content

IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
RFC 4551

Revision differences

Document history

Date Rev. By Action
2020-01-21
09 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
09 (System)
Received changes through RFC Editor sync (changed abstract to 'Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP …
Received changes through RFC Editor sync (changed abstract to 'Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.

The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.

This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]')
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2006-06-30
09 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-06-30
09 Amy Vezza [Note]: 'RFC 4551' added by Amy Vezza
2006-06-15
09 (System) RFC published
2006-06-15
09 Lisa Dusseault Assigning to me to finish tracking AUTH 48 status
2006-06-15
09 Lisa Dusseault Shepherding AD has been changed to Lisa Dusseault from Scott Hollenbeck
2006-03-13
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-03-13
09 Amy Vezza
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version …
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version 5 was approved; see Appendix A for a change log.' added by Amy Vezza
2006-03-06
09 Amy Vezza IESG state changed to Approved-announcement sent
2006-03-06
09 Amy Vezza IESG has approved the document
2006-03-06
09 Amy Vezza Closed "Approve" ballot
2006-03-03
09 (System) Removed from agenda for telechat - 2006-03-02
2006-03-02
09 Scott Hollenbeck State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Scott Hollenbeck
2006-03-02
09 Scott Hollenbeck
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version …
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version 5 was approved; see Appendix A for a change log.' added by Scott Hollenbeck
2006-03-02
09 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2006-03-02
09 Amy Vezza
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version …
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version 5 was approved; see Appendix A for a change log.' added by Amy Vezza
2006-03-02
09 Michelle Cotton
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version …
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version 5 was approved; see Appendix A for a change log.' added by Michelle Cotton
2006-03-02
09 Michelle Cotton IANA Comments:
Upon approval of this document the IANA will register the CONDSTORE IMAP capability in the following registry:
http://www.iana.org/assignments/imap4-capabilities
2006-03-02
09 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-03-01
09 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-02-27
09 Scott Hollenbeck
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version …
[Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>.  This document is coming back because the working group revised the document after IESG approval.  Version 5 was approved; see Appendix A for a change log.' added by Scott Hollenbeck
2006-02-27
09 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2006-02-17
09 Scott Hollenbeck [Ballot Position Update] New position, Yes, has been recorded for Scott Hollenbeck
2006-02-17
09 Scott Hollenbeck Ballot has been issued by Scott Hollenbeck
2006-02-17
09 Scott Hollenbeck Created "Approve" ballot
2006-02-14
09 Scott Hollenbeck State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Scott Hollenbeck
2006-02-14
09 Scott Hollenbeck Placed on agenda for telechat - 2006-03-02 by Scott Hollenbeck
2006-02-13
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-02-13
09 (System) New version available: draft-ietf-imapext-condstore-09.txt
2006-02-10
09 Scott Hollenbeck State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Scott Hollenbeck
2006-02-10
09 Scott Hollenbeck New version needed to address last call comments.
2006-02-09
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-01-26
09 Amy Vezza Last call sent
2006-01-26
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-01-26
09 Scott Hollenbeck Last Call was requested by Scott Hollenbeck
2006-01-26
09 Scott Hollenbeck State Changes to Last Call Requested from AD Evaluation by Scott Hollenbeck
2006-01-26
09 Scott Hollenbeck
Change explanation from Lisa Dusseault :

Diff capturing the important changes:
http://tools.ietf.org/wg/imapext/draft-ietf-imapext-condstore/draft-ietf-imapext-condstore-08-from-07.diff.html

List of changes:
- Removed what was section 3.5 in draft -07, "MODSEQ …
Change explanation from Lisa Dusseault :

Diff capturing the important changes:
http://tools.ietf.org/wg/imapext/draft-ietf-imapext-condstore/draft-ietf-imapext-condstore-08-from-07.diff.html

List of changes:
- Removed what was section 3.5 in draft -07, "MODSEQ Sort Criterion"
- Removed mention of the SORT command throughout the document

Justification for changes: unstall document by removing dependency
- Dependency on IMAP SORT internet-draft removed <https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=4540>
- that ID itself is stalled waiting on yet another internet-draft that isn't finished
<https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=10286>

- Removed dependency can easily be addressed (if needed) in a separate draft so as not to hold up the main condstore work
- <http://www.ietf.org/internet-drafts/draft-melnikov-condstore-sort-00.txt>

Noting also that the changes from draft -05 to draft -06 removed a previous dependency (Annotations) and the changes from draft -06 to draft -07 simply fixed a bug in the draft.
2006-01-26
09 Scott Hollenbeck State Changes to AD Evaluation from RFC Ed Queue by Scott Hollenbeck
2006-01-26
09 Scott Hollenbeck
On 25 January 2006 the IMAPEXT working group chairs request sent a request
to ask the IESG to evaluate draft-ietf-imapext-condstore-08.txt as a replacement for draft-ietf-imapext-condstore-05.txt.  …
On 25 January 2006 the IMAPEXT working group chairs request sent a request
to ask the IESG to evaluate draft-ietf-imapext-condstore-08.txt as a replacement for draft-ietf-imapext-condstore-05.txt.  A new last call and IESG evaluation will be needed as a result of normative changes.  The rationale will be described in the updated ballot write-up.
2006-01-26
09 Scott Hollenbeck [Note]: 'Document shepherd is Lisa Dusseault <lisa@osafoundation.org>' added by Scott Hollenbeck
2006-01-03
08 (System) New version available: draft-ietf-imapext-condstore-08.txt
2005-11-30
07 (System) New version available: draft-ietf-imapext-condstore-07.txt
2005-10-18
06 (System) New version available: draft-ietf-imapext-condstore-06.txt
2004-03-10
09 Scott Hollenbeck Shepherding AD has been changed to Scott Hollenbeck from Ned Freed
2003-12-09
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2003-12-08
09 Amy Vezza IESG state changed to Approved-announcement sent
2003-12-08
09 Amy Vezza IESG has approved the document
2003-12-08
09 Amy Vezza Closed "Approve" ballot
2003-12-04
09 Amy Vezza Removed from agenda for telechat - 2003-12-04 by Amy Vezza
2003-12-04
09 Ned Freed State Changes to Approved-announcement to be sent from IESG Evaluation by Ned Freed
2003-12-04
09 Ned Freed [Note]: 'Revised version posted - back on agenda to see if<br>discuss issues addressed' has been cleared by Ned Freed
2003-12-02
09 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2003-12-02
09 Ned Freed State Changes to IESG Evaluation from IESG Evaluation::Revised ID Needed by Ned Freed
2003-12-02
09 Ned Freed Placed on agenda for telechat - 2003-12-04 by Ned Freed
2003-12-02
09 Ned Freed [Note]: 'Revised version posted - back on agenda to see if<br>discuss issues addressed' added by Ned Freed
2003-12-01
05 (System) New version available: draft-ietf-imapext-condstore-05.txt
2003-10-31
09 Amy Vezza Removed from agenda for telechat - 2003-10-30 by Amy Vezza
2003-10-30
09 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-10-30
09 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-10-30
09 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-10-30
09 Ned Freed State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Ned Freed
2003-10-30
09 Ned Freed [Note]: 'Returned to WG for revision' added by Ned Freed
2003-10-30
09 Ned Freed Discuss comments passed back to WG.
2003-10-30
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for  by Russ Housley
2003-10-30
09 Ted Hardie
[Ballot discuss]
After talking to the working group chair, I was tempted to defer this doc
and follow up with the author, but I've decided …
[Ballot discuss]
After talking to the working group chair, I was tempted to defer this doc
and follow up with the author, but I've decided it probably needs public
discussion. 

Section 3.2 says:

Note: A client trying to make an atomic change to the state of a particular
            metadata item (or a set of metadata items) should be prepared
            to deal with the case when the server returns MODIFIED response code
            if the state of the metadata item being watched hasn't changed (but
            the state of some other metadata item has). This is necessary, because
            some servers don't store separate mod-sequences for different metadata
            items. However, a server implementation SHOULD avoid generating
            spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
            even when the server stores a single mod-sequence per message.

            Upon the receipt of MODIFIED response code the client SHOULD try to
            figure out if the required metadata items have indeed changed. If they
            haven't the client SHOULD retry the command.

First, this is a classic case of IMAP being so server focused as to make a
client's life hell.  In order to avoid keeping per-metadatum state, the protocol
now forces client round trips to check that what it wants to change isn't the
bit that has already been changed.  While I won't challenge that
design choice based on my own preference, I'm not sure that I believe "SHOULD try
to figure out" is a realistic piece of protocol specification, and seeing it in
a document about conditional storage makes my head hurt.  Cleaning
up the language so it is clear exactly what the client has to do would be
useful.

I also think the sentence "a server implementation SHOULD avoid generating
spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
even when the server stores a single mod-sequence per message" doesn't
make any sense.  What is the server supposed to do here?  Not send
a modified response even though it knows something changed and doesn't
know what, based on some extra-protocol knowledge?  This doesn't seem
like a win for interoperability.  If it doesn't know what changed (because it is using a
single mod-sequence) it's not spurious, just lame.

I believe we normally have documents that update other RFCs mention that in
the abstract, and since this does, it probably ought to.
2003-10-30
09 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for  by Thomas Narten
2003-10-30
09 Bert Wijnen
[Ballot comment]
Nit:
$ /bin/checkpage.awk < drafts/draft-ietf-imapext-condstore-04.txt
-: 268 lines longer than 72 characters, max 90
-: 1 pages longer than 58 lines, max 1203 …
[Ballot comment]
Nit:
$ /bin/checkpage.awk < drafts/draft-ietf-imapext-condstore-04.txt
-: 268 lines longer than 72 characters, max 90
-: 1 pages longer than 58 lines, max 1203 lines
2003-10-30
09 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for  by Bert Wijnen
2003-10-30
09 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for  by Jon Peterson
2003-10-29
09 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for  by Bill Fenner
2003-10-29
09 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for  by Harald Alvestrand
2003-10-29
09 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for  by Steve Bellovin
2003-10-29
09 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-10-28
09 Ted Hardie
[Ballot discuss]
After talking to the working group chair, I was tempted to defer this doc
and follow up with the author, but I've decided …
[Ballot discuss]
After talking to the working group chair, I was tempted to defer this doc
and follow up with the author, but I've decided it probably needs public
discussion. 

Section 3.2 says:

Note: A client trying to make an atomic change to the state of a particular
            metadata item (or a set of metadata items) should be prepared
            to deal with the case when the server returns MODIFIED response code
            if the state of the metadata item being watched hasn't changed (but
            the state of some other metadata item has). This is necessary, because
            some servers don't store separate mod-sequences for different metadata
            items. However, a server implementation SHOULD avoid generating
            spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
            even when the server stores a single mod-sequence per message.

            Upon the receipt of MODIFIED response code the client SHOULD try to
            figure out if the required metadata items have indeed changed. If they
            haven't the client SHOULD retry the command.

First, this is a classic case of IMAP being so server focused as to make a
client's life hell.  In order to avoid keeping per-metadatum state, the protocol
now forces client round trips to check that what it wants to change isn't the
bit that has already been changed.  I'm not sure that I believe "SHOULD try
to figure out" is a realistic piece of protocol specification, and seeing it in
a document about conditional storage makes my head hurt. 

I also think the sentence "a server implementation SHOULD avoid generating
spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations,
even when the server stores a single mod-sequence per message" doesn't
make any sense.  What is the server supposed to do here?  Not send
a modified response even though it knows something changed and doesn't
know what, based on some extra-protocol knowledge?  This doesn't seem
like a win for interoperability.  If it doesn't know what changed (because it is using a
single mod-sequence) it's not spurious, just lame.

I believe we normally have documents that update other RFCs mention that in
the abstract, and since this does, it probably ought to.
2003-10-28
09 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Undefined by Ted Hardie
2003-10-28
09 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for  by Ted Hardie
2003-10-18
09 Ned Freed State Changes to IESG Evaluation from Waiting for Writeup by Ned Freed
2003-10-18
09 Ned Freed Placed on agenda for telechat - 2003-10-30 by Ned Freed
2003-10-18
09 Ned Freed [Note]: 'On IESG agenda 30-Oct-2003' added by Ned Freed
2003-10-18
09 Ned Freed [Ballot Position Update] New position, Yes, has been recorded for Ned Freed
2003-10-18
09 Ned Freed Ballot has been issued by Ned Freed
2003-10-18
09 Ned Freed Created "Approve" ballot
2003-10-18
09 (System) Ballot writeup text was added
2003-10-18
09 (System) Last call text was added
2003-10-18
09 (System) Ballot approval text was added
2003-10-17
09 (System) State has been changed to Waiting for Writeup from In Last Call by system
2003-10-03
09 Michael Lee State Changes to In Last Call from Last Call Requested by Michael Lee
2003-10-02
09 Ned Freed State Changes to Last Call Requested from Expert Review by Ned Freed
2003-10-02
09 Ned Freed -04 version addresses AD review comments
2003-10-02
09 Ned Freed State Changes to Expert Review from AD Evaluation::Revised ID Needed by Ned Freed
2003-10-02
09 Ned Freed State Changes to AD Evaluation::Revised ID Needed from Publication Requested::Revised ID Needed by Ned Freed
2003-10-02
09 Ned Freed
AD review comments:

Section 2, fifth paragraph: A reference to [ANNOTATE] should be added.

Section 2, seventh paragraph: extention -> extension

Section 4, second paragraph: …
AD review comments:

Section 2, fifth paragraph: A reference to [ANNOTATE] should be added.

Section 2, seventh paragraph: extention -> extension

Section 4, second paragraph: "[IMAP4]" -> "[IMAP4] or [ANNOTATE]"

There are lots of ABNF errors. The production:

entry-name          = entry-name-flag / entry-annotate-name
   
should be:

entry-name          = entry-flag-name / entry-annotate-name
   
(There is no entry-name-flag production.) The production:

    entry-flag-name    = '"' "/flags/" attr-flag '"'

isn't syntactically valid and needs to be changed to:

    entry-flag-name    = DQUOTE "/flags/" attr-flag DQUOTE

(The DQUOTE production is used in RFC 3501, whose ABNF is available to
this document.) The production:

    entry-type-resp    = "priv" | "shared"

should be:

    entry-type-resp    = "priv" / "shared"

The production:

    entry-type-req      = entry-type-resp | "all"

should be:

    entry-type-req      = entry-type-resp / "all"

The production:

    store              = "STORE" SP set store-modifiers SP store-att-flags

should read:

    store              = "STORE" SP sequence-set store-modifiers
                          SP store-att-flags

The production:

    fetch              = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
                          "FAST" / fetch-att /
                          "(" fetch-att *(SP fetch-att) ")") [SPfetch-modifiers]

should read:

    fetch              = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
                          "FAST" / fetch-att /
                          "(" fetch-att *(SP fetch-att) ")") [SP fetch-modifiers]

The production:

mod-sequence-valzer = "0" | mod-sequence-value

should be:

mod-sequence-valzer = "0" / mod-sequence-value

The production name "search_sort_mod_seq" needs to be changed to
"search-sort-mod-seq" everywhere. (Underscors aren't allowed in production
names.)

Security considerations:

The statement "It is believed that the Conditional STORE extension
doesn't raise any new security concerns that are not already discussed
in [IMAP4]" is correct as far as it goes. However, this extension
provides a means by which an IMAP store can be used for potentially
criticial applications involving multiple clients that could not be
supported before. This may have the effect of making correct IMAP
server behavior more important. Accordingly, I suggest amending the
section to read:

It is believed that the Conditional STORE extension doesn't raise
any new security concerns that are not already discussed in [IMAP4].
However, the availability of this extension may make it possible
for IMAP4 to be used in critical applications it could not be used
for previously, making correct IMAP server implementation and
operation in even more important.

Section 7: The wording here is awkward. I suggest changing it to read:
"This document defines  the CONDSTORE and SORT=MODSEQ IMAP capabilities.
IANA should add them to the registry accordingly."

Acknowledgements, third paragraph:  "Authors" -> "The authors"
2003-10-02
09 Ned Freed Draft Added by Ned Freed
2003-10-02
04 (System) New version available: draft-ietf-imapext-condstore-04.txt
2003-08-05
03 (System) New version available: draft-ietf-imapext-condstore-03.txt
2003-06-17
02 (System) New version available: draft-ietf-imapext-condstore-02.txt
2003-04-21
01 (System) New version available: draft-ietf-imapext-condstore-01.txt
2003-03-28
00 (System) New version available: draft-ietf-imapext-condstore-00.txt