idnits 2.17.1 draft-melnikov-imap-createparams-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 413. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([IMAP4]), 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 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 (September 2005) is 6760 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: 'UNSEEN 12' is mentioned on line 230, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 231, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 232, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- No information found for draft-melnikov-imap-ext-abnf-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IMAPABNF' Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Reporting flag state in IMAP A. Melnikov 3 Document: draft-melnikov-imap-createparams-01.txt Isode Ltd. 4 Expires: March 2006 September 2005 5 Intended category: Standards Track 7 IMAP CREATE/RENAME parameters 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 A revised version of this draft document will be submitted to the RFC 33 editor as a Proposed Standard for the Internet Community. Discussion 34 and suggestions for improvement are requested, and should be sent to 35 the IMAPEXT Mailing list . Distribution of this 36 draft is unlimited. 38 Abstract 40 When creating (or renaming) a mailbox in [IMAP4] it is desirable to 41 be able to specify additional creation time parameters that can't be 42 changed after the mailbox is created. Some examples of the creation 43 time parameters are: mailbox type, mailbox location on a server or a 44 cluster of servers, mailbox flag state. This document extends IMAP 45 CREATE and RENAME commands to allow for such parameters. 47 A server which supports this extension indicates this with a 48 capability name of "X-DRAFT-I01-CREATEPARAM". 50 Table of Contents 52 0. To do.........................................................1 53 1. Conventions Used in this Document.............................2 54 2. Extended CREATE command.......................................X 55 2.1. Partition identifier parameter to CREATE command.............X 56 2.2. TYPE parameter to CREATE command.............................X 57 2.3. SHAREDFLAGS parameter to CREATE command......................X 58 3. Extended RENAME command.......................................X 59 4. Security Considerations.......................................X 60 5. Formal Syntax.................................................X 61 6. IANA considerations...........................................X 62 7. Acknowledgments...............................................X 63 8. Normative References..........................................X 64 9. Author's Addresses............................................X 65 10. Intellectual Property.........................................X 66 11. Full Copyright Statement......................................X 68 1. Conventions Used in this Document 70 "C:" and "S:" in examples show lines sent by the client and server 71 respectively. 73 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 74 in this document when typed in uppercase are to be interpreted as 75 defined in "Key words for use in RFCs to Indicate Requirement Levels" 76 [KEYWORDS]. 78 2. Extended CREATE command 80 Arguments: mailbox name 81 OPTIONAL list of CREATE parameters 83 Responses: no specific responses for this command 85 Result: OK - create completed 86 NO - create failure: can't create mailbox with that name 87 and parameters 88 BAD - argument(s) invalid 90 See section 6.3.3 of [IMAP4] for the description of the basic CREATE 91 command. The text in this section only describes how this behavior is 92 modified by additional parameter. 94 This extension adds the ability to include one or more parameters 95 with the IMAP CREATE command, to turn on or off certain standard 96 behaviour, or to add new optional behaviours required for a 97 particular extension. Optional parameters to the CREATE command are 98 added as a parenthesised list of attribute/value pairs after the 99 mailbox name. Each value can be either an atom, a string or a list. 100 The order of individual parameters is arbitrary. Individual 101 parameters may consist of one or more atoms or strings in a specific 102 order. If a parameter consists of more than one atom or string, it 103 MUST appear in its own parenthesised list. Any parameter not defined 104 by extensions that the server supports MUST be rejected with a BAD 105 response. 107 Several new CREATE command parameters are defined in subsequent 108 sections. 110 Extended CREATE can't be used to modify parameters of an already 111 existing mailbox. The server MUST return NO to any such request. 113 Example: C: a CREATE Forms (PARTITION Server1:partition5 TYPE 114 CALENDAR) 115 S: a OK CREATE complete 117 In the above example, the mailbox "Forms" is create on partition 118 names "Server1:partition5" and has a type CALENDAR. See also 119 section 2.2. 121 2.1. Partition identifier parameter to CREATE and RENAME commands 123 Several existing IMAP servers support a concept of "partition". A 124 partition describes a collection of related mailboxes in a 125 mailstore. Each partition is identified by a unique partition 126 identifier, which may contains a globally unique prefix (e.g. host 127 name or domain name), followed by a local partition identifier. For 128 example, a server implementation that stores mailboxes in a 129 filesystem may choose to use the root directory for a partition as 130 the local partition identifier. (See also the Security 131 Considerations section for discussions about partition naming.) 133 Servers that don't support the partition concept SHOULD ignore the 134 partition parameter to CREATE and RENAME commands. 136 2.1.1. Additional requirements on the partition identifier parameter 137 to CREATE 139 Note, If the partition identifier parameter is not specified, the 140 server supporting multiple partitions uses internal policy to 141 assign the new mailbox to one of the existing partitions. 143 If one or more of the superior hierarchical mailboxes doesn't exist 144 the server SHOULD create such superior mailboxes, as described in 145 section 6.3.3 of [IMAP4]. Such superior mailboxes SHOULD be 146 assigned to the same partition as the mailbox itself. In other 147 words, an attempt to create "foo/bar/zap" on a server in which "/" 148 is the hierarchy separator character SHOULD create foo/ and 149 foo/bar/ if they do not already exist. If the mailbox "foo" already 150 exists and is assigned to "partition1" and the client requests to 151 create "foo/bar/zap" on "partition2", than the server SHOULD create 152 both "foo/bar" and "foo/bar/zap" on "partition2". 154 2.2. TYPE parameter to CREATE command 156 Many existing IMAP servers provide access to specialized 157 mailstores, for example mailstores that can store voice messages as 158 described in VPIM <>. 160 The TYPE parameter to CREATE command allows the client to give a 161 hint about intended usage of the mailbox to be created. Such hint 162 can be used by the server to choose storage format. For example, 163 some storage formats can only store or be optimized for certain 164 types of MIME messages. 166 This document defines the following initial set of mailbox types: 167 - "CONTACT" - can contain MIME messages containing text/plain (?) 168 and 169 vCARD 170 - "CALENDAR" - can contain vCALENDAR objects as described in <<>> 171 - "VOICE" 172 - "IMAGE" 173 - "VIDEO" 174 - "JUNK" - messages identified by the user as junk. Messages MAY 175 be deleted 176 automatically from such mailbox after some period of 177 time. 178 - "VIEW" - "virtual mailbox", created using a persistent mailbox 179 search mechanism. 181 <> 184 2.3. SHAREDFLAGS parameter to CREATE command 186 <> 188 Let's call a flag shared for a mailbox if the mailbox may be set up 189 so that any changes to this flag by a user A are persistent and 190 visible to a different user B. Note, that different mailboxes may 191 have different flags as shared. 193 SHAREDFLAGS parameter allows to specify which system flags and user 194 defined keywords should be shared for the mailbox. It also allows 195 to "precreate" some user defined keyword. 197 The server is not required to be able to store any particular 198 system flag or user defined keyword as shared. If the server is 199 unable to persistently store certain flags from SHAREFLAGS list or 200 store certain flags as shared (or unable to store any user defined 201 flag, when a user defined flag is specified), it MUST return NO to 202 the CREATE command with the SHAREDFLAGS parameter and MUST NOT 203 create the mailbox. 205 If multiple flags are specified in the SHAREDFLAGS parameter the 206 server MUST either be able to store all requested flags as shared 207 or fail the command with the tagged NO response. 209 The server MAY restrict which users can create a mailbox with 210 SHAREDFLAGS parameter and which flags may be stored as shared. 212 When a child submailbox is created and no SHAREDFLAGS parameter is 213 specified, the parent SHAREDFLAGS settings SHOULD be used. 215 If a mailbox created with SHAREDFLAGS parameter is subsequently 216 renamed, the SHAREDFLAGS settings SHOULD be preserved. <> 219 A server which supports the SHAREDFLAGS parameter to the CREATE 220 command indicates this with a capability name of "X-DRAFT- 221 I00-CREATEFLAGS". This is in addition to the "X-DRAFT- 222 I00-CREATEPARAM" capability. 224 Example: C: a CREATE Forms (SHAREDFLAGS (\Seen $MDNSent)) 225 S: a OK CREATE completed. Requested flags are shared. 226 ... 227 C: b SELECT Forms 228 S: * 172 EXISTS 229 S: * 1 RECENT 230 S: * OK [UNSEEN 12] Message 12 is first unseen 231 S: * OK [UIDVALIDITY 3857529045] UIDs valid 232 S: * OK [UIDNEXT 4392] Predicted next UID 233 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft 234 $MDNSent) 235 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted 236 \Seen $MDNSent)] Draft flag is not permanent 237 S: * OK [SHAREDFLAGS (\Seen $MDNSent)] Limited 238 S: b OK [READ-WRITE] SELECT completed 240 3. Extended RENAME command 242 Arguments: existing mailbox name 243 new mailbox name 244 OPTIONAL list of RENAME parameters 246 Responses: no specific responses for this command 248 Result: OK - rename completed 249 NO - rename failure: can't rename mailbox with that 250 name, can't rename to mailbox with that name, 251 can't move the mailbox to the specified partition, 252 etc. 253 BAD - argument(s) invalid 255 See section 6.3.5 of [IMAP4] for the description of the basic 256 RENAME command. The text in this section only describes how this 257 behavior is modified by additional parameter. 259 This extension adds the ability to include one or more parameters 260 with the IMAP RENAME command, to turn on or off certain standard 261 behaviour, or to add new optional behaviours required for a 262 particular extension. Optional parameters to the RENAME command 263 are added as a parenthesised list of attribute/value pairs after 264 the mailbox name. Each value can be either an atom, a string or a 265 list. The order of individual parameters is arbitrary. Individual 266 parameters may consist of one or more atoms or strings in a 267 specific order. If a parameter consists of more than one atom or 268 string, it MUST appear in its own parenthesised list. Any parameter 269 not defined by extensions that the server supports MUST be rejected 270 with a BAD response. 272 Note that not all CREATE parameters are allowed as RENAME 273 parameters and vice versa. 275 The RENAME command changes the name of a mailbox from "existing 276 mailbox name" to "new mailbox name". 278 One of the RENAME command parameters is the partition identifier 279 parameter, which is described in more details in section 2.1. 280 Servers that don't support the partition concept SHOULD ignore the 281 partition parameter. When the new partition identifier parameter 282 is specified the server is requested to "move" the mailbox to a 283 different partition. Thus in order to move a mailbox between two 284 partitions the client can issue a RENAME command with the new 285 mailbox name being the same as the existing mailbox name, and the 286 partition identifier parameter specifying the new partition. 288 If one or more of the superior hierarchical mailboxes for the new 289 mailbox name doesn't exist the server SHOULD create such superior 290 mailboxes, as described in section 6.3.5 of [IMAP4]. Such superior 291 mailboxes SHOULD be assigned to the same partition as the new 292 mailbox name itself. In other words, an attempt to rename 293 "foo/bar/zap" to "baz/rag/zowie" on a server in which "/" is the 294 hierarchy separator character SHOULD create baz/ and baz/rag/ if 295 they do not already exist. If the mailbox "baz" already exists and 296 is assigned to "partition1" and the client requests to move 297 "foo/bar/zap" to "partition2", than the server SHOULD create both 298 "baz/rag" and "baz/rag/zowie" on "partition2". 300 If the existing mailbox name has inferior hierarchical mailboxes, 301 then the inferior hierarchical mailboxes MUST also be renamed. For 302 example, a rename of "foo" to "zap" will rename "foo/bar" (assuming 303 "/" is the hierarchy delimiter character) to "zap/bar". If the new 304 partition identifer parameter is specified, than all inferior 305 mailboxes SHOULD be moved to the specified partition. 307 4. Security Considerations 309 <> 313 A partition name may disclose too match information about 314 particular implementation. For example, if different partitions are 315 implemented as different directories in a file system, and a 316 partition name is the file system path, partition name may disclose 317 the file system layout. 319 5. Formal Syntax 321 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 322 Non-terminals referenced but not defined below are as defined by 323 [ABNF], [IMAP4] or [IMAPABNF]. 325 Except as noted otherwise, all alphabetic characters are case- 326 insensitive. The use of upper or lower case characters to define 327 token strings is for editorial clarity only. Implementations MUST 328 accept these strings in a case-insensitive fashion. 330 capability =/ "X-DRAFT-I00-CREATEPARAM" / 331 "X-DRAFT-I00-CREATEFLAGS" 332 ;; "capability" is defined in [IMAP4] 334 create-param =/ partition-param / 335 ("TYPE" SP mailbox-type) / 336 ("SHAREDFLAGS" SP flag-list) 337 ;; "flag-list" is defined in [IMAP4] 339 mailbox-type = "CONTACT" / "CALENDAR" / "VOICE" / "IMAGE" / 340 "VIDEO" / "JUNK" / "VIEW" 341 <> 343 partition-param = "PARTITION" SP partition 345 partition = [partition-server ":"] partition-local 346 ;; use astring instead? 348 partition-server = atom 349 ;; No ":" allowed, unless IPv6 address? 351 partition-local = atom 352 ;; No ":" allowed 354 rename-param =/ partition-param 356 6. IANA considerations 357 <> 359 7. Acknowledgments 361 The author would like to thank Cyrus Daboo for the initial 362 motivation for this document. 364 8. Normative References 366 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", RFC 2119, March 1997. 369 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 370 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 371 November 1997. 373 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 374 4rev1", RFC 3501, University of Washington, March 2003. 376 [IMAPABNF] Melnikov, A., and C. Daboo, "Collected extensions to IMAP4 377 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 379 9. Author's Addresses 381 Alexey Melnikov 382 Isode Limited 383 5 Castle Business Village 384 36 Station Road 385 Hampton, Middlesex 386 TW12 2BX, UK 388 Email: Alexey.Melnikov@isode.com 389 URI: http://www.melnikov.ca/ 391 10. Intellectual Property 393 The IETF takes no position regarding the validity or scope of any 394 Intellectual Property Rights or other rights that might be claimed to 395 pertain to the implementation or use of the technology described in 396 this document or the extent to which any license under such rights 397 might or might not be available; nor does it represent that it has 398 made any independent effort to identify any such rights. Information 399 on the procedures with respect to rights in RFC documents can be 400 found in BCP 78 and BCP 79. 402 Copies of IPR disclosures made to the IETF Secretariat and any 403 assurances of licenses to be made available, or the result of an 404 attempt made to obtain a general license or permission for the use of 405 such proprietary rights by implementers or users of this 406 specification can be obtained from the IETF on-line IPR repository at 407 http://www.ietf.org/ipr. 409 The IETF invites any interested party to bring to its attention any 410 copyrights, patents or patent applications, or other proprietary 411 rights that may cover technology that may be required to implement 412 this standard. Please address the information to the IETF at ietf- 413 ipr@ietf.org. 415 11. Full Copyright Statement 417 Copyright (C) The Internet Society (2005). 419 This document is subject to the rights, licenses and restrictions 420 contained in BCP 78, and except as set forth therein, the authors 421 retain all their rights. 423 This document and the information contained herein are provided on an 424 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 425 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 426 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 427 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 428 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 429 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 431 Acknowledgement 433 Funding for the RFC Editor function is currently provided by the 434 Internet Society.