idnits 2.17.1 draft-maes-lemonade-vfolder-02.txt: -(117): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(182): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(185): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(196): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(210): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(264): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(335): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(336): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(337): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 27 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC3501]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (January 2006) is 6676 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: 'RFC2119' is mentioned on line 57, but not defined == Missing Reference: 'RFC 3501' is mentioned on line 253, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Unused Reference: '1' is defined on line 309, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 314, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 315, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-melnikov-imap-ext-abnf-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNFEXTEND' -- Possible downref: Normative reference to a draft: ref. 'CREATEPARAM' -- No information found for draft-maes-lemonade-p-imap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'P-IMAP' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Duplicate reference: RFC3501, mentioned in '3', was also mentioned in 'RFC3501'. ** Obsolete normative reference: RFC 3501 (ref. '3') (Obsoleted by RFC 9051) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 January 2006 3 Lemonade 4 Internet Draft: VFOLDER S. H. Maes 5 Document: draft-maes-lemonade-vfolder-02 R. Cromwell 6 A. Srivastava 7 Eds. 9 Expires: July 2006 January 2006 11 Persistent Search Extensions and Virtual Folder to the IMAP Protocol 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Persistent Extensions to the IMAP Protocol (LPSEARCH) defines 43 extension parameters to the [RFC3501] CREATE command to allow virtual 44 mailboxes to be created which are views of other mailboxes narrowed 45 by search criteria. 47 Conventions used in this document 49 In examples, "C:" and "S:" indicate lines sent by the client and 50 server respectively. 52 January 2006 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 An implementation is not compliant if it fails to satisfy one or more 59 of the MUST or REQUIRED level requirements for the protocol(s) it 60 implements. An implementation that satisfies all the MUST or REQUIRED 61 level and all the SHOULD level requirements for a protocol is said to 62 be "unconditionally compliant" to that protocol; one that satisfies 63 all the MUST level requirements but not all the SHOULD level 64 requirements is said to be "conditionally compliant." When 65 describing the general syntax, some definitions are omitted as they 66 are defined in [RFC3501]. 68 Table of Contents 70 Status of this Memo...............................................1 71 Copyright Notice..................................................1 72 Abstract..........................................................1 73 Conventions used in this document.................................1 74 Table of Contents.................................................2 75 1. Introduction................................................2 76 2. LPSEARCH Capability.........................................3 77 3. CREATE and LPSEARCH Command Extension.......................3 78 4. Response Codes..............................................4 79 A.1. BADBACKING................................................4 80 A.2. BADSEARCH.................................................4 81 5. Formal Syntax...............................................4 82 7. Message and Mailbox changes.................................5 83 Security Considerations...........................................6 84 References........................................................6 85 Normative Appendices...........................................6 86 A. SEARCH extensions...........................................6 87 B. Dealing with mutable message state..........................7 88 Future Work.......................................................7 89 Version History...................................................7 90 Acknowledgments...................................................7 91 Authors Addresses.................................................8 92 Intellectual Property Statement...................................8 93 Disclaimer of Validity............................................9 94 Copyright Statement...............................................9 96 1. Introduction 98 The LPSEARCH extension is present in any IMAP4 implementation which 99 returns �LPSEARCH� as one of the supported capabilities in the 100 CAPABILITY command. 102 January 2006 104 A virtual folder is an IMAP4 folder with attached search criteria. 105 The search criteria specify the backing mailbox, as well as a subset 106 IMAP SEARCH grammar which may be applied to the immutable properties 107 of messages in the backing mailbox. Once created, all operations 108 applied to the virtual mailbox, such as APPEND and STORE, are 109 actually applied to the backing mailbox. For all intents and 110 purposes, the virtual folder looks and behaves like a real IMAP4 111 folder. 113 Any changes made to the underlying folder must pass the search 114 criteria for the virtual folder before being visible. UIDs are 115 preserved, and as well as the UIDVALIDITY value. In general, most 116 mailbox state and metadata present on the backing folder should be 117 identical on the virtual folder, except where it doesn�t make sense. 118 (e.g. EXISTS, RECENT, in general, values which are based on then 119 number of messages which have/do not have a certain property in the 120 mailbox) 122 Message sequence numbers will be different, but the order of the 123 messages in the sequence, and the ordering of UIDs, MUST be 124 preserved. 126 From the client�s perspective, whether or not a mailbox is a vfolder 127 is not visible, and for all intents and purposes, it appears as any 128 other mailbox name. This includes the ability for a new virtual 129 folder to be created by using another virtual folder as a backing 130 mailbox. 132 For the purposes of this draft, �immutability� refers to message 133 flags and non-immutable messages annotations. 135 2. LPSEARCH Capability 137 A server which supports LPSEARCH returns �LPSEARCH� as one of the 138 responses of the CAPABILITY command. LPSEARCH adheres to 139 [CREATEPARAM] and [ABNFEXTEND] syntax so a server MAY also wish to 140 report additional capabilities for extended CREATE. 142 3. CREATE and LPSEARCH Command Extension 144 Arguments: mailbox name 145 Optional �LPSEARCH� backing mailbox name & 146 search criteria 148 Responses: optional NO responses BADSEARCH,BADBACKING 149 Result: OK created lpsearch completed 150 NO can�t create mailbox with that name 151 January 2006 153 BAD command unknown or arguments invalid 155 All of the semantics of CREATE as defined in 6.3.3 of [RFC3501] must 156 hold. Additionally, if the backing mailbox name doesn�t exist, the 157 creation MUST fail with a NO result and BADBACKING response code. If 158 the search criteria are invalid because the search would violate some 159 of the required properties (immutable message properties only), 160 BADSEARCH must be reported with a NO response, or if the SEARCH 161 contains an error in one of its argument values, a NO with a 162 BADSEARCH response is returned. 164 4. Response Codes 165 A.1. 166 BADBACKING 167 The mailbox name used for the backing mailbox doesn�t exist. 169 A.2. 170 BADSEARCH 171 The search criteria violates the pre-conditions mentioned in 172 section 1, or some of the arguments of the search are invalid. 174 5. Formal Syntax 176 The following syntax specification uses the Augmented Backus-Naur 177 Form (ABNF) notation. Elements not defined here can be found in 178 the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND]. 180 The create ABNF grammar in [RFC3501] is hereby modified to the 181 grammar defined in [ABNFEXTEND]. An additional CREATE param 182 �LPSEARCH� is introduced whose value is a list containing the backing 183 store mailbox and the search parameters. 185 create_param =/ �LPSEARCH� SP �(� backing-mailbox psearch �)� 186 ;; conforms to generic "create-param" syntax as 187 defined in [ABNFEXTEND] 189 backing-mailbox = mailbox 191 psearch = search-program 192 ; defined in [ABNFEXTEND] 194 6. Examples 196 C: a1 CREATE lemonade (LPSEARCH (INBOX HEADER �Sender� �lemonade- 197 bounces�)) 198 S: a1 OK CREATE LPSEARCH Completed 199 January 2006 201 Create a persistent mailbox which shows only messages sent to 202 lemonade mailing list. 204 C: a2 CREATE mobile (LPSEARCH (INBOX FROM �boss@mycompany.com�)) 205 S: a2 OK CREATE LPSEARCH Completed 207 Create a mailbox to be synchronized (not in scope of this 208 document) with a mobile device. 210 C: a2 CREATE mobile (LPSEARCH (INBOX FROM �boss@mycompany.com� WITHIN 211 259200)) 212 S: a2 OK CREATE LPSEARCH Completed 214 Create a mailbox that contains all messages from 215 boss@mycompany.com that were sent within the last 3 days according to 216 the timezone of the server. 218 C: a3 CREATE foo (LPSEARCH (IMBOX FROM �boss@mycompany.com�)) 219 S: a3 NO [BADBACKING] CREATE failed. IMBOX is not a valid mailbox. 221 Attempt to create a mailbox with a non-existence backing mailbox 222 (fail) 224 C: a3 CREATE foo (LPSEARCH (INBOX FLAGGED)) 225 S: a3 NO [BADSEARCH] CREATE failed. SEARCH refers to mutable 226 properties 228 Attempt to create a mailbox with a search for flagged messages 229 (fail)_ 231 7. Message and Mailbox changes 233 When new messages arrive, or messages are expunged, an untagged 234 response MUST be sent to the client just as it would if the backing 235 mailbox was selected. Modifications to mutable state (flags, 236 annotations) have no affect on the whether or not messages are 237 included virtual folders, nor do they generate events. A client 238 fetching the FLAGS of a message in a virtual folder will however see 239 the latest value of those values in the backing mailbox. 241 If a backing mailbox is deleted, then all vfolders attached to that 242 backing mailbox as deleted as well. 244 January 2006 246 Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of 247 the backing mailbox are reflected in all attached vfolders. 249 Security Considerations 251 The LPSEARCH extension does not raise any security considerations 252 which are not present in the base protocol. Considerations are the 253 same as for IMAP [RFC 3501]. 255 References 257 [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: 258 ABNF�, RFC 2234, November 1997. 259 http://www.ietf.org/rfc/rfc2234 261 [ABNFEXTEND] Melnikov, A., and C. Daboo, "Collected extensions to 262 IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 264 [CREATEPARAM] Melnikov, A., �IMAP CREATE/RENAME parameters�, draft- 265 melnikov-imap-createparams-01.txt, September 2005. 267 [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 268 Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn 269 S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP 270 Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in 271 progress). 273 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 274 Version 4 rev1", RFC 3501, March 2003. 275 http://www.ietf.org/rfc/rfc3501 277 Normative Appendices 279 A. 280 SEARCH extensions 282 In order to support certain mobile uses cases, the ABNF search-key 283 grammar of [RFC3501] has been extended with a new search key: WITHIN 284 286 search-key /= �WITHIN� nz-number 288 The key returns messages whose sent date is within the specified 289 interval starting from the current date of the server. 291 January 2006 293 B. 294 Dealing with mutable message state 296 In order to gain implementation simplicity, vfolder prohibits the 297 usage of mutable message state in search criteria when creating a 298 folder. It does not however, prevent searching on mutable state 299 elsewhere. 301 Clients that wish to create virtual folders based on mutable state 302 such as flags, are urged to create a virtual folder containing the 303 non-mutable search criteria, and then implement the mutable criteria 304 by issuing IMAP SEARCH commands from the client within the virtual 305 folder. 307 Future Work 309 [1] Decide whether virtual mailboxes may have their own annotations 310 and whether messages in a virtual mailbox may have their own 311 annotations, both of which are not reflected in the backing mailbox. 312 View dependent annotations may be useful for multi-device 313 synchronization. 314 [2] Address editor�s notes. 315 [3] Determine whether section 6 conflicts with RFC3501 guarantees or 316 any IMAP extensions, and if so, how to resolve such conflicts. 318 Version History 320 Release 02 321 Update to address comments from Alexey Melnikov, and a new 322 restricted model using immutable message properties 323 Release 01 324 Update to address comments from Alexey Melnikov to follow 325 appropriately the generic syntax provided in draft-melnikov-imap-ext- 326 abnf-05.txt. 327 Release 00 328 Initial release 330 Acknowledgments 332 The authors want to thank all who have contributed key insight and 333 extensively reviewed and discussed the concepts of LPSEARCH and its 334 early introduction P-IMAP [P-IMAP]. In particular, this includes the 335 authors of the P-IMAP draft: Rafiul Ahad � Oracle Corporation, Eugene 336 Chiu � Oracle Corporation, Ray Cromwell � Oracle Corporation, Jia-der 337 Day � Oracle Corporation, Vi Ha � Oracle Corporation, Wook-Hyun Jeong 338 � Samsung Electronics Co. LTF, Chang Kuang � Oracle Corporation, 339 Rodrigo Lima � Oracle Corporation, Stephane H. Maes � Oracle 340 Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini � Symbol 341 Technologies, Sung-Mu Son � LG Electronics, Fan Xiaohui - CHINA 342 MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE 343 January 2006 345 COMMUNICATIONS CORPORATION (CMCC). We also want to give a special 346 thanks to A. Melnikov for his review and suggestions. 348 Authors Addresses 350 Stephane H. Maes 351 Oracle Corporation 352 500 Oracle Parkway 353 M/S 4op634 354 Redwood Shores, CA 94065 355 USA 356 Phone: +1-650-607-6296 357 Email: stephane.maes@oracle.com 359 Ray Cromwell 360 Oracle Corporation 361 500 Oracle Parkway 362 Redwood Shores, CA 94065 363 USA 365 Anil Srivastava 366 Sun Microsystems 367 4150 Network Circle SCA15/201 368 Santa Clara, CA 94065 369 anil.srivastava@sun.com 371 Intellectual Property Statement 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 January 2006 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at ietf- 395 ipr@ietf.org. 397 Disclaimer of Validity 399 This document and the information contained herein are provided on an 400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 402 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 403 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 404 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 407 Copyright Statement 409 Copyright (C) The Internet Society (2006). This document is subject 410 to the rights, licenses and restrictions contained in BCP 78, and 411 except as set forth therein, the authors retain all their rights. 413 Acknowledgement 415 Funding for the RFC Editor function is currently provided by the 416 Internet Society.