Internet DRAFT - draft-melnikov-condstore-sort
draft-melnikov-condstore-sort
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
