Internet DRAFT - draft-gulbrandsen-imap-nostore
draft-gulbrandsen-imap-nostore
Network Working Group Arnt Gulbrandsen
Request for Comments: DRAFT Oryx Mail Systems GmbH
draft-gulbrandsen-imap-nostore-00.txt February 2006
The IMAP NOSTORE Extension
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.
This Internet-Draft will expire in February, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The NOSTORE extension allows an IMAP server to send EXPUNGE and
EXISTS responses to a support client at any time, while preserving
the advantages of message-number arithmentic.
The extension requires that UID STORE be used instead of STORE.
Gulbrandsen Expires Feburary 2007 [Page 1]
Internet-draft August 2006
Conventions Used in This Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS]. Formal syntax is defined by [ABNF] as modified by [IMAP]
and [IMAPABNF].
In the example, "C:" and "S:" indicate lines sent by the client and
server respectively.
Introduction
An [IMAP] server that supports this extension announces "NOSTORE" as
one of its capabilities. This extension adds one new select
parameter, no commands and no responses.
While the extension is active, the server notifies the client at
once about external changes to the mailbox.
Client Requirements
To enable NOSTORE for a mailbox session, the client uses the NOSTORE
select-param on the SELECT command.
In such a session, the client MUST NOT use the STORE command. It
should always use the UID STORE command instead.
The client MUST tolerate that EXPUNGE, EXISTS and other untagged
responses can arrive at any time, even when no command is being
executed.
It follows that commands with MSN arguments are best not used. This
includes FETCH, COPY, often SEARCH and sometimes UID SEARCH. The
commands UID STORE, UID FETCH, UID COPY and UID SEARCH can do the
same job.
Server Requirements
When NOSTORE has been enabled for a mailbox session, the server
changes its behaviour as follows:
The server MUST reject the STORE command with a BAD response.
Gulbrandsen Expires Feburary 2007 [Page 2]
Internet-draft August 2006
If a command is found to contains MSNs outside the currently valid
range, the server MUST silently ignore these MSNs. (This is similar
to how UIDs are handled.)
The server SHOULD send EXISTS and EXPUNGED responses promptly when
messages are added to the mailbox or expunged from the mailbox. The
server MAY send flag updates and other unsolicited responses at any
time.
Examples
In examples, some lines have been wrapped for editorial clarity.
In this example, a client selects a mailbox and updates its UID and
flag cache.
C: a SELECT INBOX (NOSTORE)
S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
S: * 999 EXISTS
S: * 0 RECENT
S: * OK [UIDNEXT 10001] next uid
S: * OK [UIDVALIDITY 1] uid validity
S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft
\Seen \*)] permanent flags
S: a OK [READ-WRITE] Mailbox selected with NOSTORE active
C: b UID FETCH 1:* (FLAGS)
S: * 1 FETCH (UID 10 FLAGS (\seen))
S: * 2 FETCH (UID 20 FLAGS (\seen))
[996 similar responses elided]
S: * 999 FETCH (UID 10000 FLAGS ())
S: c OK That was fun
In the next example, an advanced client uses MSN arithmetic to do
the same job much more efficiently. Before connecting, the client
has 1000 messages cached, with UIDs 10, 20 and so on to 10000. When
connecting, it sees that the server has just 999 messages, and so
knows that at least one message has been deleted.
C: a SELECT INBOX (NOSTORE)
S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
S: * 999 EXISTS
S: * 0 RECENT
S: * OK [UIDNEXT 10001] next uid
S: * OK [UIDVALIDITY 1] uid validity
S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft
\Seen \*)] permanent flags
S: a OK [READ-WRITE] Mailbox selected with NOSTORE active
Gulbrandsen Expires Feburary 2007 [Page 3]
Internet-draft August 2006
To find out which message was deleted without using too much
bandwidth, this very smart client starts with a search command using
MSNs:
C: d UID SEARCH 1,200,400,600,800,999,* UID
S: * SEARCH 10,2000,4000,6000,8000,10000
S: d OK Search completed
At this time, the client knows the approximate UID of the deleted
messages. The server has 198 messages with UIDs between 10 and 2000,
199 between 2000 and 4000, etc. The client determines that since the
server has 198 messages between UID 8000 and 10000 and its own cache
contains 199 messages, the deleted message must be in this range.
Accordingly it sends another search:
C: e UID SEARCH 801:998
S: * SEARCH 8010,8030,8040,8040,[196 more UIDs elided]
S: e OK Search completed
The second search reveals that the cached message with UID 8020 has
been expunged.
Note that this command sequence works perfectly even if the server
expunges messages at the same time.
If the server supports [CONDSTORE], the client can now go on to
update its flag cache.
C: f UID FETCH 1:* FLAGS (CHANGEDSINCE 42)
S: * 997 FETCH (UID 9980 FLAGS (\seen) MODSEQ 42)
S: f OK That was much more fun!
Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF]. [IMAPABNF] defines the
non-terminals search-param.
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.
search-param =/ "NOSTORE"
Security considerations
Gulbrandsen Expires Feburary 2007 [Page 4]
Internet-draft August 2006
There are no known security issues with this extension.
IANA considerations
The IANA is requested to add NOSTORE to the list of IMAP extensions.
Credits
(Your name here :)
Normative References
[ABNF] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail
Consortium, Demon Internet Ltd, November 1997.
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March
1997.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, June 2003.
[IMAPABNF] Melnikov, A. and Daboo, C., "Collected Extensions to
IMAP4 ABNF", RFC 4466, Isode Ltd., April 2006.
[CONDSTORE] Melnikov, A. and Hole, S.., "IMAP Extension for
Conditional STORE Operation or Quick Flag Changes
Resynchronization", RFC 4551, Isode Ltd., June 2006.
Author's Address
Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
Fax: +49 89 4502 9758
Email: arnt@oryx.com
Gulbrandsen Expires Feburary 2007 [Page 5]
Internet-draft August 2006
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.
Full Copyright Statement
Copyright (C) The Internet Society (2006). 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gulbrandsen Expires Feburary 2007 [Page 6]
