< draft-ietf-qresync-rfc4551bis-01.txt   draft-ietf-qresync-rfc4551bis-02.txt >
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd. Internet-Draft Isode Ltd.
Obsoletes: 4551 (if approved) June 06, 2013 Obsoletes: 4551 (if approved) July 01, 2013
Updates: 3501, 2683 (if approved) Updates: 3501, 2683 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 08, 2013 Expires: January 02, 2014
IMAP Extension for Conditional STORE Operation or Quick Flag Changes IMAP Extension for Conditional STORE Operation or Quick Flag Changes
Resynchronization Resynchronization
draft-ietf-qresync-rfc4551bis-01.txt draft-ietf-qresync-rfc4551bis-02.txt
Abstract Abstract
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on a common IMAP mailbox. Examples include different clients working on
behalf of the same user, and multiple users accessing shared behalf of the same user, and multiple users accessing shared
mailboxes. These clients need a mechanism to synchronize state mailboxes. These clients need a mechanism to synchronize state
changes for messages within the mailbox. They must be able to changes for messages within the mailbox. They must be able to
guarantee that only one client can change message state (e.g., guarantee that only one client can change message state (e.g.,
message flags) at any time. An example of such an application is use message flags) at any time. An example of such an application is use
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 08, 2013. This Internet-Draft will expire on January 02, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6
3.1. New OK Untagged Responses for SELECT and EXAMINE . . . . 5 3.1. New OK Untagged Responses for SELECT and EXAMINE . . . . 6
3.1.1. HIGHESTMODSEQ Response Code . . . . . . . . . . . . . 6 3.1.1. HIGHESTMODSEQ Response Code . . . . . . . . . . . . . 6
3.1.2. NOMODSEQ Response Code . . . . . . . . . . . . . . . 7 3.1.2. NOMODSEQ Response Code . . . . . . . . . . . . . . . 7
3.2. STORE and UID STORE Commands . . . . . . . . . . . . . . 7 3.2. STORE and UID STORE Commands . . . . . . . . . . . . . . 8
3.3. FETCH and UID FETCH Commands . . . . . . . . . . . . . . 13 3.3. FETCH and UID FETCH Commands . . . . . . . . . . . . . . 14
3.3.1. CHANGEDSINCE FETCH Modifier . . . . . . . . . . . . . 13 3.3.1. CHANGEDSINCE FETCH Modifier . . . . . . . . . . . . . 14
3.3.2. MODSEQ Message Data Item in FETCH Command . . . . . . 13 3.3.2. MODSEQ Message Data Item in FETCH Command . . . . . . 14
3.4. MODSEQ Search Criterion in SEARCH . . . . . . . . . . . . 16 3.4. MODSEQ Search Criterion in SEARCH . . . . . . . . . . . . 16
3.5. Modified SEARCH Untagged Response . . . . . . . . . . . . 17 3.5. Modified SEARCH Untagged Response . . . . . . . . . . . . 17
3.6. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . . . 17 3.6. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . . . 18
3.7. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . . . 17 3.7. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . . . 18
3.8. Additional Quality-of-Implementation Issues . . . . . . . 18 3.8. Additional Quality-of-Implementation Issues . . . . . . . 19
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Server Implementation Considerations . . . . . . . . . . . . 21 5. Server Implementation Considerations . . . . . . . . . . . . 22
6. Long Command Lines . . . . . . . . . . . . . . . . . . . . . 22 6. Long Command Lines . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 24 Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction and Overview 1. Introduction and Overview
The Conditional STORE extension is present in any IMAP4 The Conditional STORE extension is present in any IMAP4
implementation that returns "CONDSTORE" as one of the supported implementation that returns "CONDSTORE" as one of the supported
capabilities in the CAPABILITY command response. capabilities in the CAPABILITY command response.
An IMAP server that supports this extension MUST associate a positive An IMAP server that supports this extension MUST associate a positive
unsigned 64-bit value called a modification sequence (mod-sequence) unsigned 64-bit value called a modification sequence (mod-sequence)
with every IMAP message. This is an opaque value updated by the with every IMAP message. This is an opaque value updated by the
server whenever a metadata item is modified. The server MUST server whenever a metadata item is modified. The server MUST
skipping to change at page 4, line 41 skipping to change at page 4, line 41
o a STATUS (HIGHESTMODSEQ) command, o a STATUS (HIGHESTMODSEQ) command,
o a FETCH or SEARCH command that includes the MODSEQ message data o a FETCH or SEARCH command that includes the MODSEQ message data
item, item,
o a FETCH command with the CHANGEDSINCE modifier, or o a FETCH command with the CHANGEDSINCE modifier, or
o a STORE command with the UNCHANGEDSINCE modifier. o a STORE command with the UNCHANGEDSINCE modifier.
o a ENABLE command containing "CONDSTORE" as one of the parameters.
(This requirement only applies to servers that also implement the
ENABLE extension [RFC5161].)
The server MUST include mod-sequence data in all subsequent untagged The server MUST include mod-sequence data in all subsequent untagged
FETCH responses (until the connection is closed), whether they were FETCH responses (until the connection is closed), whether they were
caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or
an external agent. an external agent.
This document uses the term "CONDSTORE-aware client" to refer to a This document uses the term "CONDSTORE-aware client" to refer to a
client that announces its willingness to receive mod-sequence updates client that announces its willingness to receive mod-sequence updates
as described above. The term "CONDSTORE enabling command" will refer as described above. The term "CONDSTORE enabling command" will refer
any of the commands listed above. A future extension to this any of the commands listed above. A future extension to this
document may extend the list of CONDSTORE enabling commands. A first document may extend the list of CONDSTORE enabling commands. A first
CONDSTORE enabling command executed in the session MUST cause the CONDSTORE enabling command executed in the session with a mailbox
server to return HIGHESTMODSEQ (Section 3.1.1) unless the server has selected MUST cause the server to return HIGHESTMODSEQ
sent NOMODSEQ (Section 3.1.2) response code when the currently (Section 3.1.1) for the mailbox, unless the server has sent NOMODSEQ
selected mailbox was selected. (Section 3.1.2) response code when the currently selected mailbox was
selected.
The rest of this document describes the protocol changes more The rest of this document describes the protocol changes more
rigorously. rigorously.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 6, line 25 skipping to change at page 6, line 36
MUST send the OK untagged response including HIGHESTMODSEQ response MUST send the OK untagged response including HIGHESTMODSEQ response
code with every successful SELECT or EXAMINE command: code with every successful SELECT or EXAMINE command:
OK [HIGHESTMODSEQ <mod-sequence-value>] OK [HIGHESTMODSEQ <mod-sequence-value>]
where <mod-sequence-value> is the highest mod-sequence value of where <mod-sequence-value> is the highest mod-sequence value of
all messages in the mailbox. When the server changes UIDVALIDITY all messages in the mailbox. When the server changes UIDVALIDITY
for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for
the mailbox. the mailbox.
Note that this requirement applies whether or not a CONDSTORE
enabling command was issued in the session.
A disconnected client can use the value of HIGHESTMODSEQ to check if A disconnected client can use the value of HIGHESTMODSEQ to check if
it has to refetch metadata from the server. If the UIDVALIDITY value it has to refetch metadata from the server. If the UIDVALIDITY value
has changed for the selected mailbox, the client MUST delete the has changed for the selected mailbox, the client MUST delete the
cached value of HIGHESTMODSEQ. If UIDVALIDITY for the mailbox is the cached value of HIGHESTMODSEQ. If UIDVALIDITY for the mailbox is the
same, and if the HIGHESTMODSEQ value stored in the client's cache is same, and if the HIGHESTMODSEQ value stored in the client's cache is
less than the value returned by the server, then some metadata items less than the value returned by the server, then some metadata items
on the server have changed since the last synchronization, and the on the server have changed since the last synchronization, and the
client needs to update its cache. The client MAY use SEARCH MODSEQ client needs to update its cache. The client MAY use SEARCH MODSEQ
(Section 3.4) to find out exactly which metadata items have changed. (Section 3.4) to find out exactly which metadata items have changed.
Alternatively, the client MAY issue FETCH with the CHANGEDSINCE Alternatively, the client MAY issue FETCH with the CHANGEDSINCE
skipping to change at page 7, line 9 skipping to change at page 7, line 22
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [HIGHESTMODSEQ 715194045007] S: * OK [HIGHESTMODSEQ 715194045007]
S: A142 OK [READ-WRITE] SELECT completed S: A142 OK [READ-WRITE] SELECT completed
Example 1 Example 1
3.1.2. NOMODSEQ Response Code 3.1.2. NOMODSEQ Response Code
A server that doesn't support the persistent storage of mod-sequences A server that doesn't support the persistent storage of mod-sequences
for the mailbox MUST send the OK untagged response including NOMODSEQ for the mailbox MUST send the OK untagged response including NOMODSEQ
response code with every successful SELECT or EXAMINE command. A response code with every successful SELECT or EXAMINE command. Note
server that returned NOMODSEQ response code for a mailbox, which that this requirement applies whether or not a CONDSTORE enabling
command was issued in the session.
A server that returned NOMODSEQ response code for a mailbox, which
subsequently receives one of the following commands while the mailbox subsequently receives one of the following commands while the mailbox
is selected: is selected:
o a FETCH command with the CHANGEDSINCE modifier, o a FETCH command with the CHANGEDSINCE modifier,
o a FETCH or SEARCH command that includes the MODSEQ message data o a FETCH or SEARCH command that includes the MODSEQ message data
item, or item, or
o a STORE command with the UNCHANGEDSINCE modifier o a STORE command with the UNCHANGEDSINCE modifier
skipping to change at page 17, line 9 skipping to change at page 18, line 4
Example 15 Example 15
C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000 C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
S: * SEARCH S: * SEARCH
S: t OK Search complete, nothing found S: t OK Search complete, nothing found
Example 16 Example 16
3.5. Modified SEARCH Untagged Response 3.5. Modified SEARCH Untagged Response
Data: zero or more numbers Data: zero or more numbers
mod-sequence value (omitted if no match) mod-sequence value (omitted if no match)
This document extends syntax of the untagged SEARCH response to This document extends syntax of the untagged SEARCH response to
include the highest mod-sequence for all messages being returned. include the highest mod-sequence for all messages being returned.
If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH)
command and the server returns a non-empty SEARCH result, the server command and the server returns a non-empty SEARCH result, the server
MUST also append (to the end of the untagged SEARCH response) the MUST also append (to the end of the untagged SEARCH response) the
highest mod-sequence for all messages being returned. See highest mod-sequence for all messages being returned. See
Section 3.5 for examples. Section 3.4 for examples.
3.6. HIGHESTMODSEQ Status Data Items 3.6. HIGHESTMODSEQ Status Data Items
This document defines a new status data item: This document defines a new status data item:
HIGHESTMODSEQ The highest mod-sequence value of all messages in the HIGHESTMODSEQ The highest mod-sequence value of all messages in the
mailbox. This is the same value that is returned by the server in mailbox. This is the same value that is returned by the server in
the HIGHESTMODSEQ response code in an OK untagged response (see the HIGHESTMODSEQ response code in an OK untagged response (see
Section 3.1.1). If the server doesn't support the persistent Section 3.1.1). If the server doesn't support the persistent
storage of mod-sequences for the mailbox (see Section 3.1.2), the storage of mod-sequences for the mailbox (see Section 3.1.2), the
skipping to change at page 23, line 38 skipping to change at page 24, line 38
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006. ABNF", RFC 4466, April 2006.
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
Extension", RFC 5161, March 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References 10.2. Informative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC [RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
2180, July 1997. 2180, July 1997.
skipping to change at page 24, line 20 skipping to change at page 25, line 23
[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access
Protocol - ANNOTATE Extension", RFC 5257, June 2008. Protocol - ANNOTATE Extension", RFC 5257, June 2008.
Appendix A. Changes since RFC 4551 Appendix A. Changes since RFC 4551
Fixed errata 3401, 3506 and 3509. Fixed errata 3401, 3506 and 3509.
Updated references. Updated references.
Incorporated some text from RFC 5161 (no semantic change.)
Editorial corrections.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Ltd. Isode Ltd.
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 15 change blocks. 
32 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/