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 |