idnits 2.17.1 draft-melnikov-imap-createparams-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 435. ** 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 (July 2005) is 6859 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 224, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 225, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 226, 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-00.txt Isode Ltd. 4 Expires: January 2006 July 2005 5 Intended category: Standards Track 7 IMAP CREATE 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-I00-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 partition identifier 82 OPTIONAL list of CREATE parameters 84 Responses: no specific responses for this command 86 Result: OK - create completed 87 NO - create failure: can't create mailbox with that name 88 and parameters 89 BAD - argument(s) invalid 91 See section 6.3.3 of [IMAP4] for the description of the basic CREATE 92 command. The text in this section only describes how this behavior is 93 modified by additional parameter. 95 This extension adds the ability to include one or more parameters 96 with the IMAP CREATE command, to turn on or off certain standard 97 behaviour, or to add new optional behaviours required for a 98 particular extension. Optional parameters to the CREATE command are 99 added as a parenthesised list of attribute/value pairs after the 100 mailbox name. Each value can be either an atom, a string or a list. 101 The order of individual parameters is arbitrary. Individual 102 parameters may consist of one or more atoms or strings in a specific 103 order. If a parameter consists of more than one atom or string, it 104 MUST appear in its own parenthesised list. Any parameter not defined 105 by extensions that the server supports MUST be rejected with a BAD 106 response. 108 The mailbox name may be followed by an optional partition identifier 109 parameter, which is described in more details in the following 110 section. Servers that don't support the partition concept SHOULD 111 ignore the partition parameter. 113 <> 117 (Note, If the partition identifier parameter is not specified, the 118 server supporting multiple partitions uses internal policy to assign 119 the new mailbox to one of the existing partitions.) 121 If one or more of the superior hierarchical mailboxes doesn't exist 122 the server SHOULD create such superior mailboxes, as described in 123 section 6.3.3 of [IMAP4]. Such superior mailboxes SHOULD be assigned 124 to the same partition as the mailbox itself. In other words, an 125 attempt to create "foo/bar/zap" on a server in which "/" is the 126 hierarchy separator character SHOULD create foo/ and foo/bar/ if they 127 do not already exist. If the mailbox "foo" already exists and is 128 assigned to "partition1" and the client requests to create 129 "foo/bar/zap" on "partition2", than the server SHOULD create both 130 "foo/bar" and "foo/bar/zap" on "partition2". 132 Extended CREATE can't be used to modify parameters of an already 133 existing mailbox. The server MUST return NO to any such request. 135 Example: C: a CREATE Forms Server1:partition5 (TYPE CALENDAR) 136 S: a OK CREATE complete 138 In the above example, the mailbox "Forms" is create on partition 139 names "Server1:partition5" and has a type CALENDAR. See also 140 section 2.2. 142 2.1. Partition identifier parameter to CREATE and RENAME commands 144 Several existing IMAP servers support a concept of "partition". A 145 partition describes a collection of related mailboxes in a 146 mailstore. Each partition is identified by a unique partition 147 identifier, which may contains a globally unique prefix (e.g. host 148 name or domain name), followed by a local partition identifier. For 149 example, a server implementation that stores mailboxes in a 150 filesystem may choose to use the root directory for a partition as 151 the local partition identifier. (See also the Security 152 Considerations section for discussions about partition naming.) 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" 175 <> 178 2.3. SHAREDFLAGS parameter to CREATE command 180 Let's call a flag shared for a mailbox if the mailbox may be set up 181 so that any changes to this flag by a user A are persistent and 182 visible to a different user B. Note, that different mailboxes may 183 have different flags as shared. 185 SHAREDFLAGS parameter allows to specify which system flags and user 186 defined keywords should be shared for the mailbox. It also allows 187 to "precreate" some user defined keyword. 189 The server is not required to be able to store any particular 190 system flag or user defined keyword as shared. If the server is 191 unable to persistently store certain flags from SHAREFLAGS list or 192 store certain flags as shared (or unable to store any user defined 193 flag, when a user defined flag is specified), it MUST return NO to 194 the CREATE command with the SHAREDFLAGS parameter and MUST NOT 195 create the mailbox. 197 If multiple flags are specified in the SHAREDFLAGS parameter the 198 server MUST either be able to store all requested flags as shared 199 or fail the command with the tagged NO response. 201 The server MAY restrict which users can create a mailbox with 202 SHAREDFLAGS parameter and which flags may be stored as shared. 204 When a child submailbox is created and no SHAREDFLAGS parameter is 205 specified, the parent SHAREDFLAGS settings SHOULD be used. 207 If a mailbox created with SHAREDFLAGS parameter is subsequently 208 renamed, the SHAREDFLAGS settings SHOULD be preserved. <> 212 A server which supports the SHAREDFLAGS parameter to the CREATE 213 command indicates this with a capability name of "X-DRAFT- 214 I00-CREATEFLAGS". This is in addition to the "X-DRAFT- 215 I00-CREATEPARAM" capability. 217 Example: C: a CREATE Forms (SHAREDFLAGS (\Seen $MDNSent)) 218 S: a OK CREATE completed. Requested flags are shared. 219 ... 221 C: b SELECT Forms 222 S: * 172 EXISTS 223 S: * 1 RECENT 224 S: * OK [UNSEEN 12] Message 12 is first unseen 225 S: * OK [UIDVALIDITY 3857529045] UIDs valid 226 S: * OK [UIDNEXT 4392] Predicted next UID 227 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft 228 $MDNSent) 229 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted 230 \Seen $MDNSent)] Draft flag is not permanent 231 S: * OK [SHAREDFLAGS (\Seen $MDNSent)] Limited 232 S: b OK [READ-WRITE] SELECT completed 234 3. Extended RENAME command 236 Arguments: existing mailbox name 237 new mailbox name 238 OPTIONAL new partition identifier 239 OPTIONAL list of RENAME parameters 241 Responses: no specific responses for this command 243 Result: OK - rename completed 244 NO - rename failure: can't rename mailbox with that 245 name, can't rename to mailbox with that name, 246 can't move the mailbox to the specified partition, 247 etc. 248 BAD - argument(s) invalid 250 See section 6.3.5 of [IMAP4] for the description of the basic 251 RENAME command. The text in this section only describes how this 252 behavior is modified by additional parameter. 254 This extension adds the ability to include one or more parameters 255 with the IMAP RENAME command, to turn on or off certain standard 256 behaviour, or to add new optional behaviours required for a 257 particular extension. Optional parameters to the RENAME command 258 are added as a parenthesised list of attribute/value pairs after 259 the mailbox name. Each value can be either an atom, a string or a 260 list. The order of individual parameters is arbitrary. Individual 261 parameters may consist of one or more atoms or strings in a 262 specific order. If a parameter consists of more than one atom or 263 string, it MUST appear in its own parenthesised list. Any parameter 264 not defined by extensions that the server supports MUST be rejected 265 with a BAD response. 267 Note that not all CREATE parameters are allowed as RENAME 268 parameters and vice versa. 270 The RENAME command changes the name of a mailbox from "existing 271 mailbox name" to "new mailbox name". 273 The new mailbox name may be followed by an optional new partition 274 identifier parameter, which is described in more details in section 275 2.1. Servers that don't support the partition concept SHOULD ignore 276 the partition parameter. When the new partition identifier 277 parameter is specified the server is requested to "move" the 278 mailbox to a different partition. Thus in order to move a mailbox 279 between two partitions the client can issue a RENAME command with 280 the new mailbox name being the same as the existing mailbox name, 281 and the partition identifier parameter specifying the new 282 partition. 284 <> 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 <> 314 A partition name may disclose too match information about 315 particular implementation. For example, if different partitions are 316 implemented as different directories in a file system, and a 317 partition name is the file system path, partition name may disclose 318 the file system layout. 320 5. Formal Syntax 322 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 323 Non-terminals referenced but not defined below are as defined by 324 [ABNF], [IMAP4] or [IMAPABNF]. 326 Except as noted otherwise, all alphabetic characters are case- 327 insensitive. The use of upper or lower case characters to define 328 token strings is for editorial clarity only. Implementations MUST 329 accept these strings in a case-insensitive fashion. 331 capability =/ "X-DRAFT-I00-CREATEPARAM" / 332 "X-DRAFT-I00-CREATEFLAGS" 333 ;;capability is defined in [IMAP4] 335 create = "CREATE" SP mailbox [SP partition] 336 [SP create_params] 337 ; Use of INBOX gives a NO error 339 create_params = "(" create_param *( SP create_param) ")" 341 create_param_name = atom 342 ;; IMAPABNF tagged-ext-label? 344 create_param = create_param_name SP create_param_value 346 create_param_value= astring / "(" astring *(SP astring) ")" 347 ;; As SELECT parameters in ANNOTATE. 348 ;; <> 351 partition = [partition_server ":"] partition_local 352 ;; use astring instead? 354 partition_server = atom 355 ;; No ":" allowed, unless IPv6 address? 357 partition_local = atom 358 ;; No ":" allowed 360 rename = "RENAME" SP mailbox SP mailbox 361 [SP partition] [SP rename_params] 362 ;; Use of INBOX as a destination gives 363 ;; a NO error 365 rename_params = "(" rename_param *( SP rename_param) ")" 367 rename_param_name = atom 368 ;; IMAPABNF tagged-ext-label? 370 rename_param = rename_param_name SP rename_param_value 372 rename_param_value= astring / "(" astring *(SP astring) ")" 373 ;; As SELECT parameters in ANNOTATE. 374 ;; <> 377 6. IANA considerations 379 <> 381 7. Acknowledgments 383 The author would like to thank Cyrus Daboo for the initial 384 motivation for this document. 386 8. Normative References 388 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", RFC 2119, March 1997. 391 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 392 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 393 November 1997. 395 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 396 4rev1", RFC 3501, University of Washington, March 2003. 398 [IMAPABNF] Melnikov, A., and C. Daboo, "Collected extensions to IMAP4 399 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 401 9. Author's Addresses 403 Alexey Melnikov 404 Isode Limited 405 5 Castle Business Village 406 36 Station Road 407 Hampton, Middlesex 408 TW12 2BX, UK 410 Email: Alexey.Melnikov@isode.com 411 URI: http://www.melnikov.ca/ 413 10. Intellectual Property 415 The IETF takes no position regarding the validity or scope of any 416 Intellectual Property Rights or other rights that might be claimed to 417 pertain to the implementation or use of the technology described in 418 this document or the extent to which any license under such rights 419 might or might not be available; nor does it represent that it has 420 made any independent effort to identify any such rights. Information 421 on the procedures with respect to rights in RFC documents can be 422 found in BCP 78 and BCP 79. 424 Copies of IPR disclosures made to the IETF Secretariat and any 425 assurances of licenses to be made available, or the result of an 426 attempt made to obtain a general license or permission for the use of 427 such proprietary rights by implementers or users of this 428 specification can be obtained from the IETF on-line IPR repository at 429 http://www.ietf.org/ipr. 431 The IETF invites any interested party to bring to its attention any 432 copyrights, patents or patent applications, or other proprietary 433 rights that may cover technology that may be required to implement 434 this standard. Please address the information to the IETF at ietf- 435 ipr@ietf.org. 437 11. Full Copyright Statement 439 Copyright (C) The Internet Society (2005). 441 This document is subject to the rights, licenses and restrictions 442 contained in BCP 78, and except as set forth therein, the authors 443 retain all their rights. 445 This document and the information contained herein are provided on an 446 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 447 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 448 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 449 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 450 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 451 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 453 Acknowledgement 455 Funding for the RFC Editor function is currently provided by the 456 Internet Society.