< draft-ietf-qresync-rfc4551bis-02.txt   draft-ietf-qresync-rfc4551bis-03.txt >
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd. Internet-Draft Isode Ltd.
Obsoletes: 4551 (if approved) July 01, 2013 Obsoletes: 4551 (if approved) August 21, 2013
Updates: 3501, 2683 (if approved) Updates: 3501, 2683 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 02, 2014 Expires: February 22, 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-02.txt draft-ietf-qresync-rfc4551bis-03.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 January 02, 2014. This Internet-Draft will expire on February 22, 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 . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6
3.1. New OK Untagged Responses for SELECT and EXAMINE . . . . 6 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 . . . . . . . . . . . . . . 8 3.2. STORE and UID STORE Commands . . . . . . . . . . . . . . 8
3.3. FETCH and UID FETCH Commands . . . . . . . . . . . . . . 14 3.3. FETCH and UID FETCH Commands . . . . . . . . . . . . . . 14
3.3.1. CHANGEDSINCE FETCH Modifier . . . . . . . . . . . . . 14 3.3.1. CHANGEDSINCE FETCH Modifier . . . . . . . . . . . . . 14
3.3.2. MODSEQ Message Data Item in FETCH Command . . . . . . 14 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 . . . . . . . . . . . . 18
3.6. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . . . 18 3.6. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . . . 18
3.7. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . . . 18 3.7. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . . . 18
3.8. Additional Quality-of-Implementation Issues . . . . . . . 19 3.8. Interaction with IMAP SORT and THREAD extensions . . . . 19
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 3.9. Interaction with IMAP ESORT and ESEARCH extensions . . . 19
5. Server Implementation Considerations . . . . . . . . . . . . 22 3.10. Additional Quality-of-Implementation Issues . . . . . . . 20
6. Long Command Lines . . . . . . . . . . . . . . . . . . . . . 23 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. Server Implementation Considerations . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. Long Command Lines . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
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
guarantee that each STORE command performed on the same mailbox guarantee that each STORE command performed on the same mailbox
(including simultaneous stores to different metadata items from (including simultaneous stores to different metadata items from
skipping to change at page 14, line 11 skipping to change at page 14, line 11
This document also changes the behaviour of the server when it has This document also changes the behaviour of the server when it has
performed a STORE or UID STORE command and the UNCHANGEDSINCE performed a STORE or UID STORE command and the UNCHANGEDSINCE
modifier is not specified. If the operation is successful for a modifier is not specified. If the operation is successful for a
message, the server MUST update the mod-sequence attribute of the message, the server MUST update the mod-sequence attribute of the
message. The server is REQUIRED to include the mod-sequence value message. The server is REQUIRED to include the mod-sequence value
whenever it decides to send the unsolicited FETCH response to all whenever it decides to send the unsolicited FETCH response to all
CONDSTORE-aware clients that have opened the mailbox containing the CONDSTORE-aware clients that have opened the mailbox containing the
message. message.
Server implementers should also see Section 3.8 for additional Server implementers should also see Section 3.10 for additional
quality of implementation issues related to the STORE command. quality of implementation issues related to the STORE command.
3.3. FETCH and UID FETCH Commands 3.3. FETCH and UID FETCH Commands
3.3.1. CHANGEDSINCE FETCH Modifier 3.3.1. CHANGEDSINCE FETCH Modifier
This document defines the following FETCH modifier (see Section 2.4 This document defines the following FETCH modifier (see Section 2.4
of [RFC4466]): of [RFC4466]):
CHANGEDSINCE <mod-sequence> CHANGEDSINCE FETCH modifier allows to CHANGEDSINCE <mod-sequence> CHANGEDSINCE FETCH modifier allows to
skipping to change at page 16, line 45 skipping to change at page 16, line 45
S: C360 OK Noop completed S: C360 OK Noop completed
...and only changes to shared flags are reported in session 3. ...and only changes to shared flags are reported in session 3.
C: D390 NOOP C: D390 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: D390 OK Noop completed S: D390 OK Noop completed
Example 14 Example 14
Server implementers should also see Section 3.8 for additional Server implementers should also see Section 3.10 for additional
quality of implementation issues related to the FETCH command. quality of implementation issues related to the FETCH command.
3.4. MODSEQ Search Criterion in SEARCH 3.4. MODSEQ Search Criterion in SEARCH
The MODSEQ criterion for the SEARCH (or UID SEARCH) command allows a
The MODSEQ criterion for the SEARCH command allows a client to search client to search for the metadata items that were modified since a
for the metadata items that were modified since a specified moment. specified moment.
Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer> Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
Messages that have modification values that are equal to or Messages that have modification values that are equal to or
greater than <mod-sequence-valzer>. This allows a client, for greater than <mod-sequence-valzer>. This allows a client, for
example, to find out which messages contain metadata items that example, to find out which messages contain metadata items that
have changed since the last time it updated its disconnected have changed since the last time it updated its disconnected
cache. The client may also specify <entry-name> (name of metadata cache. The client may also specify <entry-name> (name of metadata
item) and <entry-type-req> (type of metadata item) before <mod- item) and <entry-type-req> (type of metadata item) before <mod-
sequence-valzer>. <entry-type-req> can be one of "shared", "priv" sequence-valzer>. <entry-type-req> can be one of "shared", "priv"
skipping to change at page 17, line 27 skipping to change at page 17, line 30
mod-sequences for different metadata items, it MUST ignore <entry- mod-sequences for different metadata items, it MUST ignore <entry-
name> and <entry-type-req>. Otherwise, the server should use them name> and <entry-type-req>. Otherwise, the server should use them
to narrow down the search. to narrow down the search.
For a flag <flagname>, the corresponding <entry-name> has a form " For a flag <flagname>, the corresponding <entry-name> has a form "
/flags/<flagname>" as defined in [RFC4466]. Note that the leading /flags/<flagname>" as defined in [RFC4466]. Note that the leading
"\" character that denotes a system flag has to be escaped as per "\" character that denotes a system flag has to be escaped as per
Section 4.3 of [RFC3501], as the <entry-name> uses syntax for Section 4.3 of [RFC3501], as the <entry-name> uses syntax for
quoted strings. quoted strings.
If client specifies a MODSEQ criterion in a SEARCH command and the If client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH)
server returns a non-empty SEARCH result, the server MUST also append command and the server returns a non-empty SEARCH result, the server
(to the end of the untagged SEARCH response) the highest mod-sequence MUST also append (to the end of the untagged SEARCH response) the
for all messages being returned. See also Section 3.5. highest mod-sequence for all messages being returned. See also
Section 3.5. Note that other IMAP extensions such as ESEARCH
[RFC4731] can override this requirement (see Section 3.9 for more
details.)
C: a SEARCH MODSEQ "/flags/\\draft" all 620162338 C: a SEARCH MODSEQ "/flags/\\draft" all 620162338
S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500) S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
S: a OK Search complete S: a OK Search complete
In the above example, the message numbers of any messages containing In the above example, the message numbers of any messages containing
the string "IMAP4" in the "value" attribute of the "/comment" entry the string "IMAP4" in the "value" attribute of the "/comment" entry
and having a mod-sequence equal to or greater than 620162338 for the and having a mod-sequence equal to or greater than 620162338 for the
"\Draft" flag are returned in the search results. "\Draft" flag are returned in the search results.
skipping to change at page 19, line 14 skipping to change at page 19, line 18
S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
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, CONDSTORE is now enabled S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
Example 18 Example 18
3.8. Additional Quality-of-Implementation Issues 3.8. Interaction with IMAP SORT and THREAD extensions
MODSEQ Search Criterion (see Section 3.4) causes modifications to
SORT [RFC5256] responses similar to modifications to SEARCH responses
defined in Section 3.5:
SORT response Data: zero or more numbers
mod-sequence value (omitted if no match)
This document extends syntax of the untagged SORT response to include
the highest mod-sequence for all messages being returned.
If a client specifies a MODSEQ criterion in a SORT (or UID SORT)
command and the server returns a non-empty SORT result, the server
MUST also append (to the end of the untagged SORT response) the
highest mod-sequence for all messages being returned. Note that
other IMAP extensions such as ESORT [RFC5267] can override this
requirement (see Section 3.9 for more details.)
THREAD commands which include a MODSEQ Search Criterion return THREAD
responses as specified in [RFC5256].
3.9. Interaction with IMAP ESORT and ESEARCH extensions
If a client specifies a MODSEQ criterion in an extended SEARCH (or
extended UID SEARCH) [RFC4731] command and the server returns a non-
empty SEARCH result, the server MUST return the ESEARCH response
containing the MODSEQ result option as defined in Section 3.2 of
[RFC4731].
C: a SEARCH RETURN (ALL) MODSEQ 1234
S: * ESEARCH (TAG "a") ALL 1:3,5 MODSEQ 1236
S: a OK Extended SEARCH completed
Example 19
If a client specifies a MODSEQ criterion in an extended SORT (or
extended UID SORT) [RFC5267] command and the server returns a non-
empty SORT result, the server MUST return the ESEARCH response
containing the MODSEQ result option defined in Section 3.2 of
[RFC4731].
C: a SORT RETURN (ALL) (DATE) UTF-8 MODSEQ 1234
S: * ESEARCH (TAG "a") ALL 5,3,2,1 MODSEQ 1236
S: a OK Extended SORT completed
Example 20
3.10. Additional Quality-of-Implementation Issues
Server implementations should follow the following rule, which Server implementations should follow the following rule, which
applies to any successfully completed STORE/UID STORE (with and applies to any successfully completed STORE/UID STORE (with and
without UNCHANGEDSINCE modifier), as well as to a FETCH command that without UNCHANGEDSINCE modifier), as well as to a FETCH command that
implicitly sets \Seen flag: implicitly sets \Seen flag:
Adding the flag when it is already present or removing when it is Adding the flag when it is already present or removing when it is
not present SHOULD NOT change the mod-sequence. not present SHOULD NOT change the mod-sequence.
This will prevent spurious client synchronization requests. This will prevent spurious client synchronization requests.
skipping to change at page 20, line 32 skipping to change at page 21, line 39
fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
msg-att-dynamic =/ fetch-mod-resp msg-att-dynamic =/ fetch-mod-resp
search-key =/ search-modsequence search-key =/ search-modsequence
;; modifies original IMAP4 search-key ;; modifies original IMAP4 search-key
;; ;;
;; This change applies to all commands ;; This change applies to all commands
;; referencing this non-terminal, in ;; referencing this non-terminal, in
;; particular SEARCH. ;; particular SEARCH, SORT and THREAD.
search-modsequence = "MODSEQ" [search-modseq-ext] SP search-modsequence = "MODSEQ" [search-modseq-ext] SP
mod-sequence-valzer mod-sequence-valzer
search-modseq-ext = SP entry-name SP entry-type-req search-modseq-ext = SP entry-name SP entry-type-req
resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value /
"NOMODSEQ" / "NOMODSEQ" /
"MODIFIED" SP sequence-set "MODIFIED" SP sequence-set
skipping to change at page 21, line 37 skipping to change at page 22, line 44
select-param =/ condstore-param select-param =/ condstore-param
;; conforms to the generic "select-param" ;; conforms to the generic "select-param"
;; non-terminal syntax defined in [RFC4466]. ;; non-terminal syntax defined in [RFC4466].
condstore-param = "CONDSTORE" condstore-param = "CONDSTORE"
mailbox-data =/ "SEARCH" [1*(SP nz-number) SP mailbox-data =/ "SEARCH" [1*(SP nz-number) SP
search-sort-mod-seq] search-sort-mod-seq]
sort-data = "SORT" [1*(SP nz-number) SP
search-sort-mod-seq]
; Updates SORT response from RFC 5256
attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" /
"\\Seen" / "\\Draft" / attr-flag-keyword / "\\Seen" / "\\Draft" / attr-flag-keyword /
attr-flag-extension attr-flag-extension
;; Does not include "\\Recent" ;; Does not include "\\Recent"
attr-flag-extension = "\\" atom attr-flag-extension = "\\" atom
;; Future expansion. Client implementations ;; Future expansion. Client implementations
;; MUST accept flag-extension flags. Server ;; MUST accept flag-extension flags. Server
;; implementations MUST NOT generate ;; implementations MUST NOT generate
;; flag-extension flags except as defined by ;; flag-extension flags except as defined by
skipping to change at page 23, line 13 skipping to change at page 24, line 20
the flag in the database). the flag in the database).
Therefore, the server doesn't have to report MODIFIED to the client. Therefore, the server doesn't have to report MODIFIED to the client.
Instead, the server may set $Processed flag, update the mod-sequence Instead, the server may set $Processed flag, update the mod-sequence
for the message 101 once again and send an untagged FETCH response for the message 101 once again and send an untagged FETCH response
with new mod-sequence and flags: with new mod-sequence and flags:
S: * 101 FETCH (MODSEQ (303011130956) S: * 101 FETCH (MODSEQ (303011130956)
FLAGS ($Processed \Deleted \Answered)) FLAGS ($Processed \Deleted \Answered))
See also Section 3.8 for additional quality-of-implementation issues. See also Section 3.10 for additional quality-of-implementation
issues.
6. Long Command Lines 6. Long Command Lines
This document updates recommended line length limits specified in This document updates recommended line length limits specified in
Section 3.2.1.5 of [RFC2683]. While the advice in the first Section 3.2.1.5 of [RFC2683]. While the advice in the first
paragraph of that section still applies ("use compact message/UID set paragraph of that section still applies ("use compact message/UID set
representations"), the 1000 octet limit suggested in the second representations"), the 1000 octet limit suggested in the second
paragraph turned out to be quite problematic when the CONDSTORE paragraph turned out to be quite problematic when the CONDSTORE
extension is used. The updated recommendation is as follows: a extension is used. The updated recommendation is as follows: a
client should limit the length of the command lines it generates to client should limit the length of the command lines it generates to
skipping to change at page 24, line 44 skipping to change at page 25, line 47
[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 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
Extension", RFC 5161, March 2008. 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.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, June
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.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC [RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC
2683, September 1999. 2683, September 1999.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005. RFC 4314, December 2005.
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", RFC 4731, November 2006.
[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.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
July 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.) Incorporated some text from RFC 5161 (no semantic change.)
Editorial corrections. Editorial corrections.
 End of changes. 19 change blocks. 
30 lines changed or deleted 100 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/