Internet Draft: SORT extension to IMAP Conditional STORE A. Melnikov Document: draft-melnikov-condstore-sort-00.txt Isode Ltd. Expires: June 2006 S. Hole ACI WorldWide/MessagingDirect December 2005 SORT extension to IMAP Conditional STORE Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies SORT extension to the IMAP Conditional STORE extension, which allows a client to request a sorted list of metadata (flag) changes. Table of Contents 1 Conventions Used in This Document ......................... X 2 Introduction and Overview ................................. X 3 IMAP Protocol Changes ..................................... X 3.1 MODSEQ Sort Criterion .................................... X 3.2 Modified SEARCH and SORT untagged responses .............. X 4 Formal Syntax ............................................. X 5 Security Considerations ................................... X 6 References ................................................ X 6.1 Normative References ..................................... X 7 IANA Considerations ....................................... X 9 Author's Addresses ........................................ X 10 Intellectual Property Rights .............................. X 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. In examples, lines beginning with "S:" are sent by the IMAP server, and lines beginning with "C:" are sent by the client. Line breaks may appear in example commands solely for editorial clarity; when present in the actual message they are represented by "CRLF". Formal syntax is defined using ABNF [ABNF]. The terms "metadata" (or "metadata item") and "CONDSTORE enabling command" are defined in [CONDSTORE]. 2. Introduction and Overview This document 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.2) b) adds a new MODSEQ sort criterion (see section 3.1) This document extends the list of "CONDSTORE enabling commands" defined in [CONDSTORE] to include the SORT command that includes the MODSEQ message data item. The rest of this document describes the protocol changes more rigorously. 3. IMAP Protocol Changes 3.1. MODSEQ Sort Criterion 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.2. Modified SORT untagged 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 client specifies a MODSEQ search [CONDSTORE] or sort 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. See section 3.1 for examples. 4. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [ABNF] notation. Elements not defined here can be found in the formal syntax of the ABNF [ABNF], IMAP [IMAP4], [CONDSTORE] <<, and IMAP ABNF extensions [IMAPABNF] specifications>>. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "SORT=MODSEQ" search-key =/ search-modsequence ;; modifies original IMAP4 search-key ;; ;; This change applies to all command referencing ;; this non-terminal, in particular SORT. <<This production duplicates the one specified in CONDSTORE, but the comment was updated that this also affects the SORT command.>> sort-key =/ "MODSEQ" mailbox-data =/ "SORT" [1*(SP nz-number) SP search-sort-mod-seq] 5. Security Considerations It is believed that this extension doesn't raise any new security concerns that are not already discussed in [IMAP4], [CONDSTORE] or [SORT]. 6. References 6.1. Normative References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 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> [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE operation", work in progress. <http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-xx.txt> <<[IMAPABNF] Melnikov, A., "Collected extensions to IMAP4 ABNF", work in progress.>> <http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-xx.txt> 7. IANA Considerations IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at: http://www.iana.org/assignments/imap4-capabilities This document defines the SORT=MODSEQ IMAP capability. IANA should add them to the registry accordingly. 8. Author's Addresses Alexey Melnikov mailto: Alexey.Melnikov@isode.com Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom Steve Hole mailto: Steve.Hole@messagingdirect.com ACI WorldWide/MessagingDirect #900, 10117 Jasper Avenue, Edmonton, Alberta, T5J 1W8, CANADA 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Appendix A. Change History Note that this appendix will be removed before publication. 0.1. Change History