draft-ietf-imapext-condstore-07.txt   draft-ietf-imapext-condstore-08.txt 
Internet Draft: IMAP Extension for Conditional STORE A. Melnikov Internet Draft: IMAP Extension for Conditional STORE A. Melnikov
Document: draft-ietf-imapext-condstore-07.txt Isode Ltd. Document: draft-ietf-imapext-condstore-08.txt Isode Ltd.
Expires: May 2006 S. Hole Expires: June 2006 S. Hole
ACI WorldWide/MessagingDirect ACI WorldWide/MessagingDirect
November 2005 December 2005
IMAP Extension for Conditional STORE operation IMAP Extension for Conditional STORE operation
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at line 66 skipping to change at line 66
2 Introduction and Overview ................................. X 2 Introduction and Overview ................................. X
3 IMAP Protocol Changes ..................................... X 3 IMAP Protocol Changes ..................................... X
3.1 New OK untagged responses for SELECT and EXAMINE ......... X 3.1 New OK untagged responses for SELECT and EXAMINE ......... X
3.1.1 HIGHESTMODSEQ response code ............................ X 3.1.1 HIGHESTMODSEQ response code ............................ X
3.1.2 NOMODSEQ response code ................................. X 3.1.2 NOMODSEQ response code ................................. X
3.2 STORE and UID STORE Commands ............................. X 3.2 STORE and UID STORE Commands ............................. X
3.3 FETCH and UID FETCH Commands ............................. X 3.3 FETCH and UID FETCH Commands ............................. X
3.3.1 FETCH modifiers ........................................ X 3.3.1 FETCH modifiers ........................................ X
3.3.2 MODSEQ message data item in FETCH Command .............. X 3.3.2 MODSEQ message data item in FETCH Command .............. X
3.4 MODSEQ search criterion in SEARCH ........................ X 3.4 MODSEQ search criterion in SEARCH ........................ X
3.5 MODSEQ Sort Criterion .................................... X 3.5 Modified SEARCH untagged response ........................ X
3.6 Modified SEARCH and SORT untagged responses .............. X 3.6 HIGHESTMODSEQ status data items .......................... X
3.7 HIGHESTMODSEQ status data items .......................... X 3.7 CONDSTORE parameter to SELECT and EXAMINE ................ X
3.8 CONDSTORE parameter to SELECT and EXAMINE ................ X
4 Formal Syntax ............................................. X 4 Formal Syntax ............................................. X
5 Server implementation considerations ...................... X 5 Server implementation considerations ...................... X
6 Security Considerations ................................... X 6 Security Considerations ................................... X
7 References ................................................ X 7 References ................................................ X
7.1 Normative References ..................................... X 7.1 Normative References ..................................... X
7.2 Informative References ................................... X 7.2 Informative References ................................... X
8 IANA Considerations ....................................... X 8 IANA Considerations ....................................... X
9 Acknowledgments ........................................... X 9 Acknowledgments ........................................... X
10 Author's Addresses ........................................ X 10 Author's Addresses ........................................ X
11 Intellectual Property Rights .............................. X 11 Intellectual Property Rights .............................. X
skipping to change at line 181 skipping to change at line 180
g) adds new OK untagged responses for the SELECT and EXAMINE commands g) adds new OK untagged responses for the SELECT and EXAMINE commands
h) defines an additional parameter to SELECT/EXAMINE commands h) defines an additional parameter to SELECT/EXAMINE commands
i) adds the HIGHESTMODSEQ status data item to the STATUS command i) adds the HIGHESTMODSEQ status data item to the STATUS command
A client supporting CONDSTORE extension indicates its willingness to receive A client supporting CONDSTORE extension indicates its willingness to receive
mod-sequence updates in all untagged FETCH responses by issuing a SELECT or mod-sequence updates in all untagged FETCH responses by issuing a SELECT or
EXAMINE command with the CONDSTORE parameter, or STATUS (HIGHESTMODSEQ) command, EXAMINE command with the CONDSTORE parameter, or STATUS (HIGHESTMODSEQ) command,
or a FETCH, SEARCH, or SORT or a FETCH, or SEARCH command that includes
(if it also supports SORT=MODSEQ extension, see below) command that includes
the MODSEQ message data item, a FETCH command with the CHANGEDSINCE modifier, the MODSEQ message data item, a FETCH command with the CHANGEDSINCE modifier,
or a STORE command with the UNCHANGEDSINCE modifier. or a STORE command with the UNCHANGEDSINCE modifier.
The server MUST include mod-sequence data in all subsequent untagged FETCH The server MUST include mod-sequence data in all subsequent untagged FETCH
responses, whether they responses, whether they were caused by a regular STORE, STORE with
were caused by a regular STORE, STORE with UNCHANGEDSINCE modifier, or an external UNCHANGEDSINCE modifier, or an external agent, until the connection is closed.
agent, until the connection is closed.
This document uses the term "CONSTORE-aware client" to refer to a client This document uses the term "CONSTORE-aware client" to refer to a client
that announces its willingness to receive mod-sequence updates as described that announces its willingness to receive mod-sequence updates as described
above. The term "CONDSTORE enabling command" will refer any of the commands above. The term "CONDSTORE enabling command" will refer any of the commands
listed above. A first CONDSTORE enabling command executed in the session listed above. A future extension to this document may extend the list of
MUST cause the server to return HIGHESTMODSEQ (section 3.1.1) unless the CONDSTORE enabling commands. A first CONDSTORE enabling command executed in
server has sent NOMODSEQ (section 3.1.2) response code when the currently the session MUST cause the server to return HIGHESTMODSEQ (section 3.1.1) unless
the server has sent NOMODSEQ (section 3.1.2) response code when the currently
selected mailbox was selected. selected mailbox was selected.
This document also defines a new SORT extension with a capability name
"SORT=MODSEQ". This extension is upwards compatible with the SORT extension
defined in [SORT]. Server implementations that support both the CONDSTORE and
SORT extensions SHOULD also support the SORT=MODSEQ extension. The
SORT=MODSEQ extension makes the following additions to the SORT extension:
a) extends syntax of untagged SORT responses to include mod-sequence
(see section 3.6)
b) adds a new MODSEQ sort criterion (see sections 3.4 and 3.5)
The rest of this document describes the protocol changes more rigorously. The rest of this document describes the protocol changes more rigorously.
3. IMAP Protocol Changes 3. IMAP Protocol Changes
3.1. New OK untagged responses for SELECT and EXAMINE 3.1. New OK untagged responses for SELECT and EXAMINE
This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ. This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ.
One of those response codes MUST be returned in the OK untagged One of those response codes MUST be returned in the OK untagged
response for a successful SELECT/EXAMINE command. response for a successful SELECT/EXAMINE command.
skipping to change at line 725 skipping to change at line 712
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 [IMAPABNF]. Note, that "/flags/<flagname>" as defined in [IMAPABNF]. Note, that
the leading "\" character that denotes a system flag has to be the leading "\" character that denotes a system flag has to be
escaped as per Section 4.3 of [IMAP4], as the <entry-name> uses escaped as per Section 4.3 of [IMAP4], as the <entry-name> uses
syntax for quoted strings. syntax for quoted strings.
If client specifies a MODSEQ criterion in a SEARCH command and If client specifies a MODSEQ criterion in a SEARCH command and
the server returns a non-empty SEARCH result, the server MUST also the server returns a non-empty SEARCH result, the server MUST also
append (to the end of the untagged SEARCH response) the highest append (to the end of the untagged SEARCH response) the highest
mod-sequence for all messages being returned. See also section 3.6. mod-sequence for all messages being returned. See also section 3.5.
Example: Example:
C: a SEARCH MODSEQ "/flags/\\draft" all 20010320162338 C: a SEARCH MODSEQ "/flags/\\draft" all 20010320162338
S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500) S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500)
S: a OK Search complete S: a OK Search complete
In the above example, the message numbers of any messages In the above example, the message numbers of any messages
containing the string "IMAP4" in the "value" attribute of the containing the string "IMAP4" in the "value" attribute of the
"/comment" entry and having a mod-sequence equal to or "/comment" entry and having a mod-sequence equal to or
greater than 20010320162338 for the "\Draft" flag are returned in greater than 20010320162338 for the "\Draft" flag are returned in
the search results. the search results.
Example: Example:
C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000 C: a SEARCH OR NOT MODSEQ 20010320162338 LARGER 50000
S: * SEARCH S: * SEARCH
S: a OK Search complete, nothing found S: a OK Search complete, nothing found
3.5. MODSEQ Sort Criterion 3.5. Modified SEARCH untagged response
If a server implementing CONDSTORE also implements the SORT
extension as defined by [SORT], it SHOULD implement the
SORT=MODSEQ extension that allows for sorting on per-message
mod-sequence. SORT=MODSEQ extension adds MODSEQ sort criterion
that allows to sort the matching messages based on their mod-sequence.
If client specifies a MODSEQ search (as per section 3.4) or sort
criterion in the 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.
See also section 3.6.
Example (MODSEQ sort criterion):
C: A282 SORT (SUBJECT MODSEQ) UTF-8 SINCE 1-Feb-2001
S: * SORT 2 81 83 84 82 882 (MODSEQ 117)
S: A282 OK SORT completed
Example (MODSEQ search criterion):
C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 MODSEQ 21
S: * SORT 6 3 4 5 2 (MODSEQ 125)
S: A283 OK SORT completed
Example (MODSEQ search criterion and MODSEQ SORT criterion,
but no messages matching the search criteria):
C: A284 SORT (MODSEQ) KOI8-R OR NOT MODSEQ 20010320162338
SUBJECT "Privet"
S: * SORT
S: A284 OK Sort complete, nothing found
3.6. Modified SEARCH and SORT untagged responses
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 and SORT responses This document extends syntax of the untagged SEARCH response
to include the highest mod-sequence for all messages being returned. to 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 section highest mod-sequence for all messages being returned. See section
3.4 for examples. 3.4 for examples.
If client specifies a MODSEQ search or sort criterion in a SORT 3.6. HIGHESTMODSEQ status data items
(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. See section
3.5 for examples.
3.7. HIGHESTMODSEQ status data items
This document defines a new status data item: This document defines a new status data item:
HIGHESTMODSEQ HIGHESTMODSEQ
The highest mod-sequence value all messages The highest mod-sequence value all messages
in the mailbox. This is the same value that is returned by the server in the mailbox. This is the same value that is returned by the server
in the HIGHESTMODSEQ response code in OK untagged response in the HIGHESTMODSEQ response code in OK untagged response
(see section 3.1.1). (see section 3.1.1).
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ) Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
HIGHESTMODSEQ 200201011231777) HIGHESTMODSEQ 200201011231777)
S: A042 OK STATUS completed S: A042 OK STATUS completed
3.8. CONDSTORE parameter to SELECT and EXAMINE 3.7. CONDSTORE parameter to SELECT and EXAMINE
The CONDSTORE extension defines a single optional select parameter The CONDSTORE extension defines a single optional select parameter
"CONDSTORE", which tells the server that it MUST include the MODSEQ "CONDSTORE", which tells the server that it MUST include the MODSEQ
fetch response data items in all subsequent unsolicited FETCH responses. fetch response data items in all subsequent unsolicited FETCH responses.
The CONDSTORE parameter to SELECT/EXAMINE helps to avoid a race condition The CONDSTORE parameter to SELECT/EXAMINE helps to avoid a race condition
that might arise when a metadata item(s) is(are) modified in another session that might arise when a metadata item(s) is(are) modified in another session
after the server has sent the HIGHESTMODSEQ response code and before the after the server has sent the HIGHESTMODSEQ response code and before the
client was able to issue a CONDSTORE enabling command. client was able to issue a CONDSTORE enabling command.
skipping to change at line 846 skipping to change at line 793
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) [ABNF] notation. Elements not defined here can be found in Form (ABNF) [ABNF] notation. Elements not defined here can be found in
the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF extensions the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF extensions
[IMAPABNF] specifications. [IMAPABNF] specifications.
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define token insensitive. The use of upper or lower case characters to define token
strings is for editorial clarity only. Implementations MUST accept strings is for editorial clarity only. Implementations MUST accept
these strings in a case-insensitive fashion. these strings in a case-insensitive fashion.
capability =/ "CONDSTORE" / "SORT=MODSEQ" capability =/ "CONDSTORE"
status-att =/ "HIGHESTMODSEQ" status-att =/ "HIGHESTMODSEQ"
;; extends non-terminal defined in RFC 3501. ;; extends non-terminal defined in RFC 3501.
status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-value status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-value
store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
;; Only a single "UNCHANGEDSINCE" may be specified ;; Only a single "UNCHANGEDSINCE" may be specified
;; in a STORE operation ;; in a STORE operation
skipping to change at line 878 skipping to change at line 825
fetch-mod-sequence = "MODSEQ" fetch-mod-sequence = "MODSEQ"
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 command referencing this ;; This change applies to all command referencing this
;; non-terminal, in particular SEARCH and SORT. ;; non-terminal, in particular SEARCH.
search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer search-modsequence = "MODSEQ" [search-modseq-ext] SP 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 set "MODIFIED" SP set
entry-name = entry-flag-name entry-name = entry-flag-name
skipping to change at line 924 skipping to change at line 871
;; (1 <= n < 18,446,744,073,709,551,615) ;; (1 <= n < 18,446,744,073,709,551,615)
mod-sequence-valzer = "0" / mod-sequence-value mod-sequence-valzer = "0" / mod-sequence-value
search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")" search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")"
select-param =/ condstore-param select-param =/ condstore-param
;; conforms to the generic "select-param" non-terminal ;; conforms to the generic "select-param" non-terminal
;; syntax defined in [IMAPABNF]. ;; syntax defined in [IMAPABNF].
sort-key =/ "MODSEQ"
condstore-param = "CONDSTORE" condstore-param = "CONDSTORE"
mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search-sort-mod-seq] / mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search-sort-mod-seq]
"SORT" [1*(SP nz-number) SP search-sort-mod-seq]
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
skipping to change at line 1013 skipping to change at line 957
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 4234, October 2005. ABNF", RFC 4234, October 2005.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, March 2003. 4rev1", RFC 3501, University of Washington, March 2003.
[SORT] Crispin, M., Murchison, K., "Internet Message Access Protocol --
SORT AND THREAD EXTENSIONS", work in progress.
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-xx.txt>
[IMAPABNF] Melnikov, A., "Collected extensions to IMAP4 ABNF", [IMAPABNF] Melnikov, A., "Collected extensions to IMAP4 ABNF",
work in progress. work in progress.
<http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-xx.txt> <http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-xx.txt>
7.2. Informative References 7.2. Informative References
[ACAP] Newman, Myers, "ACAP -- Application Configuration Access [ACAP] Newman, Myers, "ACAP -- Application Configuration Access
Protocol", RFC 2244, Innosoft, Netscape, November 1997. Protocol", RFC 2244, Innosoft, Netscape, November 1997.
<ftp://ftp.isi.edu/in-notes/rfc2244.txt> <ftp://ftp.isi.edu/in-notes/rfc2244.txt>
skipping to change at line 1047 skipping to change at line 987
<ftp://ftp.isi.edu/in-notes/rfc2180.txt> <ftp://ftp.isi.edu/in-notes/rfc2180.txt>
8. IANA Considerations 8. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved experimental RFC. The registry is currently located
at: at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
This document defines the CONDSTORE and SORT=MODSEQ IMAP capabilities. This document defines the CONDSTORE IMAP capability.
IANA should add them to the registry accordingly. IANA should add them to the registry accordingly.
9. Acknowledgments 9. Acknowledgments
Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens Some text was borrowed from "IMAP ANNOTATE Extension" by Randall Gellens
and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol" and Cyrus Daboo, and "ACAP -- Application Configuration Access Protocol"
by Chris Newman and John Myers. by Chris Newman and John Myers.
Many thanks to Randall Gellens for his thorough review of the document. Many thanks to Randall Gellens for his thorough review of the document.
 End of changes. 18 change blocks. 
82 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/