idnits 2.17.1 draft-gulbrandsen-imap-nostore-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 255. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UIDNEXT 10001' is mentioned on line 133, but not defined == Missing Reference: 'UIDVALIDITY 1' is mentioned on line 134, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4551 (ref. 'CONDSTORE') (Obsoleted by RFC 7162) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Arnt Gulbrandsen 2 Request for Comments: DRAFT Oryx Mail Systems GmbH 3 draft-gulbrandsen-imap-nostore-00.txt February 2006 5 The IMAP NOSTORE Extension 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 26 Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire in February, 2007. 31 Copyright Notice 33 Copyright (C) The Internet Society (2006). 35 Abstract 37 The NOSTORE extension allows an IMAP server to send EXPUNGE and 38 EXISTS responses to a support client at any time, while preserving 39 the advantages of message-number arithmentic. 41 The extension requires that UID STORE be used instead of STORE. 43 Internet-draft August 2006 45 Conventions Used in This Document 47 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 48 NOT", and "MAY" in this document are to be interpreted as described 49 in "Key words for use in RFCs to Indicate Requirement Levels" 50 [KEYWORDS]. Formal syntax is defined by [ABNF] as modified by [IMAP] 51 and [IMAPABNF]. 53 In the example, "C:" and "S:" indicate lines sent by the client and 54 server respectively. 56 Introduction 58 An [IMAP] server that supports this extension announces "NOSTORE" as 59 one of its capabilities. This extension adds one new select 60 parameter, no commands and no responses. 62 While the extension is active, the server notifies the client at 63 once about external changes to the mailbox. 65 Client Requirements 67 To enable NOSTORE for a mailbox session, the client uses the NOSTORE 68 select-param on the SELECT command. 70 In such a session, the client MUST NOT use the STORE command. It 71 should always use the UID STORE command instead. 73 The client MUST tolerate that EXPUNGE, EXISTS and other untagged 74 responses can arrive at any time, even when no command is being 75 executed. 77 It follows that commands with MSN arguments are best not used. This 78 includes FETCH, COPY, often SEARCH and sometimes UID SEARCH. The 79 commands UID STORE, UID FETCH, UID COPY and UID SEARCH can do the 80 same job. 82 Server Requirements 84 When NOSTORE has been enabled for a mailbox session, the server 85 changes its behaviour as follows: 87 The server MUST reject the STORE command with a BAD response. 89 Internet-draft August 2006 91 If a command is found to contains MSNs outside the currently valid 92 range, the server MUST silently ignore these MSNs. (This is similar 93 to how UIDs are handled.) 95 The server SHOULD send EXISTS and EXPUNGED responses promptly when 96 messages are added to the mailbox or expunged from the mailbox. The 97 server MAY send flag updates and other unsolicited responses at any 98 time. 100 Examples 102 In examples, some lines have been wrapped for editorial clarity. 104 In this example, a client selects a mailbox and updates its UID and 105 flag cache. 107 C: a SELECT INBOX (NOSTORE) 108 S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen) 109 S: * 999 EXISTS 110 S: * 0 RECENT 111 S: * OK [UIDNEXT 10001] next uid 112 S: * OK [UIDVALIDITY 1] uid validity 113 S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft 114 \Seen \*)] permanent flags 115 S: a OK [READ-WRITE] Mailbox selected with NOSTORE active 116 C: b UID FETCH 1:* (FLAGS) 117 S: * 1 FETCH (UID 10 FLAGS (\seen)) 118 S: * 2 FETCH (UID 20 FLAGS (\seen)) 119 [996 similar responses elided] 120 S: * 999 FETCH (UID 10000 FLAGS ()) 121 S: c OK That was fun 123 In the next example, an advanced client uses MSN arithmetic to do 124 the same job much more efficiently. Before connecting, the client 125 has 1000 messages cached, with UIDs 10, 20 and so on to 10000. When 126 connecting, it sees that the server has just 999 messages, and so 127 knows that at least one message has been deleted. 129 C: a SELECT INBOX (NOSTORE) 130 S: * FLAGS (\Deleted \Answered \Flagged \Draft \Seen) 131 S: * 999 EXISTS 132 S: * 0 RECENT 133 S: * OK [UIDNEXT 10001] next uid 134 S: * OK [UIDVALIDITY 1] uid validity 135 S: * OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft 136 \Seen \*)] permanent flags 137 S: a OK [READ-WRITE] Mailbox selected with NOSTORE active 139 Internet-draft August 2006 141 To find out which message was deleted without using too much 142 bandwidth, this very smart client starts with a search command using 143 MSNs: 145 C: d UID SEARCH 1,200,400,600,800,999,* UID 146 S: * SEARCH 10,2000,4000,6000,8000,10000 147 S: d OK Search completed 149 At this time, the client knows the approximate UID of the deleted 150 messages. The server has 198 messages with UIDs between 10 and 2000, 151 199 between 2000 and 4000, etc. The client determines that since the 152 server has 198 messages between UID 8000 and 10000 and its own cache 153 contains 199 messages, the deleted message must be in this range. 154 Accordingly it sends another search: 156 C: e UID SEARCH 801:998 157 S: * SEARCH 8010,8030,8040,8040,[196 more UIDs elided] 158 S: e OK Search completed 160 The second search reveals that the cached message with UID 8020 has 161 been expunged. 163 Note that this command sequence works perfectly even if the server 164 expunges messages at the same time. 166 If the server supports [CONDSTORE], the client can now go on to 167 update its flag cache. 169 C: f UID FETCH 1:* FLAGS (CHANGEDSINCE 42) 170 S: * 997 FETCH (UID 9980 FLAGS (\seen) MODSEQ 42) 171 S: f OK That was much more fun! 173 Formal Syntax 175 The following syntax specification uses the Augmented Backus-Naur 176 Form (ABNF) notation as specified in [ABNF]. [IMAPABNF] defines the 177 non-terminals search-param. 179 Except as noted otherwise, all alphabetic characters are case- 180 insensitive. The use of upper or lower case characters to define 181 token strings is for editorial clarity only. Implementations MUST 182 accept these strings in a case-insensitive fashion. 184 search-param =/ "NOSTORE" 186 Security considerations 187 Internet-draft August 2006 189 There are no known security issues with this extension. 191 IANA considerations 193 The IANA is requested to add NOSTORE to the list of IMAP extensions. 195 Credits 197 (Your name here :) 199 Normative References 201 [ABNF] Crocker, Overell, "Augmented BNF for Syntax 202 Specifications: ABNF", RFC 2234, Internet Mail 203 Consortium, Demon Internet Ltd, November 1997. 205 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 206 Requirement Levels", RFC 2119, Harvard University, March 207 1997. 209 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 210 4rev1", RFC 3501, University of Washington, June 2003. 212 [IMAPABNF] Melnikov, A. and Daboo, C., "Collected Extensions to 213 IMAP4 ABNF", RFC 4466, Isode Ltd., April 2006. 215 [CONDSTORE] Melnikov, A. and Hole, S.., "IMAP Extension for 216 Conditional STORE Operation or Quick Flag Changes 217 Resynchronization", RFC 4551, Isode Ltd., June 2006. 219 Author's Address 221 Arnt Gulbrandsen 222 Oryx Mail Systems GmbH 223 Schweppermannstr. 8 224 D-81671 Muenchen 225 Germany 227 Fax: +49 89 4502 9758 229 Email: arnt@oryx.com 231 Internet-draft August 2006 233 Intellectual Property Statement 235 The IETF takes no position regarding the validity or scope of any 236 Intellectual Property Rights or other rights that might be claimed 237 to pertain to the implementation or use of the technology described 238 in this document or the extent to which any license under such 239 rights might or might not be available; nor does it represent that 240 it has made any independent effort to identify any such rights. 241 Information on the procedures with respect to rights in RFC 242 documents can be found in BCP 78 and BCP 79. 244 Copies of IPR disclosures made to the IETF Secretariat and any 245 assurances of licenses to be made available, or the result of an 246 attempt made to obtain a general license or permission for the use 247 of such proprietary rights by implementers or users of this 248 specification can be obtained from the IETF on-line IPR repository 249 at http://www.ietf.org/ipr. 251 The IETF invites any interested party to bring to its attention any 252 copyrights, patents or patent applications, or other proprietary 253 rights that may cover technology that may be required to implement 254 this standard. Please address the information to the IETF at ietf- 255 ipr@ietf.org. 257 Full Copyright Statement 259 Copyright (C) The Internet Society (2006). This document is subject 260 to the rights, licenses and restrictions contained in BCP 78, and 261 except as set forth therein, the authors retain all their rights. 263 This document and the information contained herein are provided on 264 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 265 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 266 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 267 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 268 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 271 Acknowledgment 273 Funding for the RFC Editor function is currently provided by the 274 Internet Society.