idnits 2.17.1 draft-daboo-imap-annotatemore-11.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1540. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 25, 2007) is 6268 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'METADATA TOOMANY' is mentioned on line 917, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-imapext-i18n-06 == Outdated reference: A later version (-18) exists of draft-ietf-imapext-list-extensions-17 == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-17 == Outdated reference: A later version (-14) exists of draft-newman-i18n-comparator-13 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-16) exists of draft-ietf-imapext-annotate-15 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple 4 Intended status: Standards Track February 25, 2007 5 Expires: August 29, 2007 7 IMAP METADATA Extension 8 draft-daboo-imap-annotatemore-11 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The METADATA extension to the Internet Message Access Protocol 42 permits clients and servers to maintain "annotations" or "meta data" 43 on IMAP servers. It is possible to have annotations on a per-mailbox 44 basis or on the server as a whole. For example, this would allow 45 comments about the purpose of a particular mailbox to be "attached" 46 to that mailbox, or a "message of the day" containing server status 47 information to be made available to anyone logging in to the server. 49 Change History (to be removed prior to publication as an RFC) 51 Changes from -10 to -11: 52 1. Added new paragraph to indicate that values may be read-only or 53 computed. 54 2. /admin server annotation value now must be a URI. 55 3. Clarified that SORT and THREAD extensions are not required. 56 4. Fixed use of undefined entries in some examples. 57 5. Fixed many examples. 58 6. Added IANA registration for LIST-EXTENDED items. 59 7. Added match type and collation identifier to the LIST-EXTENDED 60 selection option. 61 8. Made support for IMAP-I18N a requirement. 62 9. Minor text clarifications applied. 63 10. Remove mailbox list set atomicity requirement. 64 11. Clarified that annotations can only be set on mailboxes that 65 actually exist. 67 Changes from -09 to -10: 68 1. Updated to rfc 4466 reference. 69 2. Reworded data model description. 70 3. Reworked LIST-EXTENDED so that responses have metadata items 71 after the mailbox info. 72 4. Various spelling fixes. 74 Changes from -08 to -09: 75 1. Remove content-language attribute and reference. 76 2. Changed capability and command names. 77 3. Revised abstract. 79 Changes from -07 to -08: 80 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 81 for entry/attribute names. 82 2. Updated examples to match new astring syntax. 83 3. Changed CAPABILITY name due to incompatible syntax change. 84 4. Removed content-type attribute. 85 5. Added Content-type to IANA registration for entries. 86 6. Removed vendor attributes. 87 7. Fixed examples in section 3.3 for multi-mailbox and multi-entry 88 cases. 89 8. Removed wildcards for attributes. 90 9. Entry/attributes can now only be ASCII. 91 10. Tied up text wrt storing/fetching. 92 11. Added Conventions section 93 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 94 '.'. 96 13. Changed to use IMAP ABNF extensions document for some formal 97 syntax items. 99 Changes from -06 to -07: 100 1. Reworded /checkperiod item. 101 2. Clarified unsolicited response behavior. 103 Changes from -05 to -06: 104 1. Removed 'modifiedsince' attribute as there is currently no use 105 for it. 106 2. Added content-language attribute. 107 3. Changed access to allow .priv and .shared on any mailbox returned 108 by LIST/LSUB. 109 4. Added IANA registrations for items defined in this document. 110 5. Added latest IPR statement. 111 6. Updated references. 113 Changes from -04 to -05: 114 1. Fix for valid IMAP state of commands. 115 2. Fix formatting, ID nits etc. 117 Changes from -03 to -04: 118 1. Allow retrieval of shared annotations for READ-ONLY mailbox. 119 2. Clarification of annotation loss on implicit removal of \Noselect 120 mailboxes. 121 3. Now requires roll-back of all changes to matching mailboxes if 122 there is a partial failure in SETANNOTATION. 124 Changes from -02 to -03: 125 1. Reworked entry naming scheme to split out mailbox name and use 126 empty string for server items. 128 Changes from -01 to -02: 129 1. SETANNOTATION lists use (..). 130 2. Explicitly state behavior of unsolicited responses. 131 3. Adding SHOULD behavior for rename/delete of mailboxes. 132 4. Added statement about supporting annotations on \Noselect 133 mailboxes. 134 5. Cleaned up formal syntax to use IMAP string type for entry and 135 attributes, with requirements on how the string is formatted. 136 6. Use of ACAP vendor subtree registry for vendor tokens. 138 Changes from -00 to -01: 139 1. Multiple entry-att responses are now simply delimited by spaces 140 in line with ANNOTATE spec. Adjusted examples to match. 141 2. Fixed entry-list formal syntax item to account for unsolicited 142 parenthesized list of entries. 144 3. Removed setentries formal syntax item for simplicity since its 145 only used once. 146 4. Removed reference to 'message annotation' in section 5.1. 147 5. Changed formal syntax to restrict top level entries to /server 148 and /mailbox/{...} only. Re-arranged entry names section to 149 account for this change. 150 6. Added comment and example for ANNOTATION response to allow 151 servers to return separate responses for each entry if desired. 153 Table of Contents 155 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 156 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 157 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 7 158 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 159 3.2. Namespace of entries and attributes . . . . . . . . . . . 7 160 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 8 161 3.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 10 162 3.3. Private versus Shared and Access Control . . . . . . . . . 10 163 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 11 164 4.1. General Considerations . . . . . . . . . . . . . . . . . . 11 165 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 12 166 4.3. Extended LIST Command Extensions . . . . . . . . . . . . . 13 167 4.3.1. Unsolicited LIST response . . . . . . . . . . . . . . 18 168 4.4. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 18 169 4.5. METADATA Response . . . . . . . . . . . . . . . . . . . . 21 170 4.5.1. METADATA response with attributes and values . . . . . 21 171 4.5.2. Unsolicited METADATA response without attributes 172 and values . . . . . . . . . . . . . . . . . . . . . . 22 173 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23 174 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 175 6.1. Entry and Attribute Registration Template . . . . . . . . 26 176 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 26 177 6.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 27 178 6.2.2. /motd . . . . . . . . . . . . . . . . . . . . . . . . 27 179 6.2.3. /admin . . . . . . . . . . . . . . . . . . . . . . . . 28 180 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 28 181 6.3.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 28 182 6.3.2. /sort . . . . . . . . . . . . . . . . . . . . . . . . 29 183 6.3.3. /thread . . . . . . . . . . . . . . . . . . . . . . . 29 184 6.3.4. /check . . . . . . . . . . . . . . . . . . . . . . . . 30 185 6.3.5. /checkperiod . . . . . . . . . . . . . . . . . . . . . 30 186 6.4. Attribute Registrations . . . . . . . . . . . . . . . . . 30 187 6.4.1. value . . . . . . . . . . . . . . . . . . . . . . . . 31 188 6.4.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 31 189 6.5. LIST-EXTENDED Registration . . . . . . . . . . . . . . . . 31 190 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 191 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 192 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 193 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 194 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 195 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 196 Intellectual Property and Copyright Statements . . . . . . . . . . 35 198 1. Introduction and Overview 200 The METADATA extension is present in any IMAP [RFC3501] 201 implementation which returns "METADATA" as one of the supported 202 capabilities in the CAPABILITY command response. The "LIST-EXTENDED" 203 [I-D.ietf-imapext-list-extensions] extension MUST also be present. 205 The goal of METADATA is to provide a means for clients to set and 206 retrieve "annotations" or "meta data" on an IMAP server. The 207 annotations can be associated with specific mailboxes or the server 208 as a whole. 210 The METADATA extension adds two new commands and one new untagged 211 response to the IMAP base protocol. It adds one new LIST-EXTENDED 212 "selection" [I-D.ietf-imapext-list-extensions] option type and one 213 new LIST-EXTENDED "return" [I-D.ietf-imapext-list-extensions] option 214 type. 216 This extension makes the following changes to the IMAP protocol: 218 o adds a new SETMETADATA command 219 o adds a new GETMETADATA command 220 o adds a new METADATA untagged response 221 o adds a new METADATA response code 222 o adds a new METADATA LIST-EXTENDED selection option type 223 o adds a new METADATA LIST-EXTENDED return option type 225 The data model used in METADATA is exactly the same as that used in 226 the ANNOTATE [I-D.ietf-imapext-annotate] extension to IMAP. This is 227 modeled after that of the Application Configuration Access Protocol 228 [RFC2244] with the exception of inheritance which is not deemed 229 necessary here. 231 Text comparisons may be done as part of the GETMETADATA or LIST- 232 EXTENDED commands. As a result, support for the COMPARATOR 233 [I-D.ietf-imapext-i18n] extension is REQUIRED. 235 The rest of this document describes the data model and protocol 236 changes more rigorously. 238 2. Conventions Used in This Document 240 In examples, "C:" and "S:" indicate lines sent by the client and 241 server respectively. 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119]. 247 Whitespace and line breaks have been added to the examples in this 248 document to promote readability. 250 3. Data Model 252 3.1. Overview 254 Mailboxes or the server as a whole may have zero or more annotations 255 associated with them. An annotation contains a uniquely named entry 256 with a set of uniquely named attributes, each of which has a value. 257 Annotations can be added to mailboxes when a mailbox name is provided 258 as the first argument to the new command, or to the server as a whole 259 when the empty string is provided as the first argument to the new 260 command. 262 For example, a general comment being added to a mailbox may have an 263 entry name of "/comment". This entry could include named attributes 264 such as "value" and "size" etc to represent properties and data 265 associated with the entry. 267 The protocol changes to IMAP described below allow a client to access 268 or change the values of any attributes in any annotation entry, 269 assuming it has sufficient access rights to do so. 271 3.2. Namespace of entries and attributes 273 Each annotation is an entry that has a hierarchical name, with each 274 component of the name separated by a slash ("/"). An entry name MUST 275 NOT contain two consecutive "/" characters and MUST NOT end with a 276 "/" character. 278 Each entry is made up of a set of attributes. Each attribute has a 279 hierarchical name, with each component of the name separated by a 280 period ("."). An attribute name MUST NOT contain two consecutive "." 281 characters and MUST NOT end with a "." character. 283 The value of an attribute is NIL (has no value), or a string of zero 284 or more octets. 286 Entry and attribute names MUST NOT contain asterisk ("*") or percent 287 ("%") characters and MUST NOT contain non-ASCII characters or the NUL 288 octet. Invalid entry or attribute names result in a BAD response in 289 any IMAP commands where they are used. 291 Attribute names MUST NOT contain any hierarchical components with the 292 names "priv" or "shared" as those have special meaning (see 293 Section 3.3). 295 Entry and attribute names are case-sensitive. 297 Use of control or punctuation characters in entry and attribute names 298 is strongly discouraged. 300 This specification defines an initial set of entry and attribute 301 names available for use with mailbox and server annotations. In 302 addition an extension mechanism is described to allow additional 303 names to be added for extensibility. 305 3.2.1. Entry Names 307 Entry names MUST be specified in a standards track or IESG approved 308 experimental RFC, or fall under the vendor namespace. See 309 Section 6.1 for the registration template. 311 3.2.1.1. Server Entries 313 These entries are used when the mailbox name argument to the new 314 SETMETADATA command is the empty string or with the new GETMETADATA 315 command. 317 /comment 318 Defines a comment or note associated with the server. 320 /motd 321 Defines a "message of the day" for the server. This entry is 322 always read-only - clients cannot change it. 324 /admin 325 Indicates a method for contacting the server administrator. The 326 value MUST be a URI (e.g., a mailto: or tel: URL). This entry is 327 always read-only - clients cannot change it. 329 /vendor/ 330 Defines the top-level of entries associated with the server as 331 created by a particular product of some vendor. This entry can be 332 used by vendors to provide server or client specific annotations. 333 The vendor-token MUST be registered with IANA, using the ACAP 334 [RFC2244] vendor subtree registry. 336 3.2.1.2. Mailbox Entries 338 These entries are used when the mailbox name argument to the new 339 SETMETADATA command is not the empty string, or with the new LIST- 340 EXTENDED selection option type, or in responses to these commands. 342 /comment 343 Defines a comment or note associated with a mailbox. 345 /sort 346 Defines the default sort criteria [I-D.ietf-imapext-sort] to use 347 when first displaying the mailbox contents to the user, or NIL if 348 sorting is not required. Note that the presence of this attribute 349 does not imply that the server supports the IMAP SORT 350 [I-D.ietf-imapext-sort] extension - servers can choose to support 351 or not support SORT independently of this extension. In the 352 absence of the SORT extension, clients can choose to interpret 353 this entry as suggesting a client-side sort ordering of the 354 corresponding mailbox. 356 /thread 357 Defines the default thread criteria [I-D.ietf-imapext-sort] to use 358 when first displaying the mailbox contents to the user, or NIL if 359 threading is not required. If both sort and thread are not NIL, 360 then threading should take precedence over sorting. Note that the 361 presence of this attribute does not imply that the server supports 362 the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can 363 choose to support or not support THREAD independently of this 364 extension. In the absence of the THREAD extension, clients can 365 choose to interpret this entry as a client-side thread ordering of 366 the corresponding mailbox. 368 /check 369 Boolean value "true" or "false" that indicates whether this 370 mailbox should be checked at regular intervals by the client. The 371 interval in minutes is specified by the /checkperiod entry. 373 /checkperiod 374 Numeric value indicating a period of minutes that the client uses 375 to determine the interval of regular 'new mail' checks for the 376 corresponding mailbox. 378 /vendor/ 379 Defines the top-level of entries associated with a specific 380 mailbox as created by a particular product of some vendor. This 381 entry can be used by vendors to provide client specific 382 annotations. The vendor-token MUST be registered with IANA, using 383 the ACAP [RFC2244] vendor subtree registry. 385 3.2.2. Attribute Names 387 Attribute names MUST be specified in a standards track or IESG 388 approved experimental RFC. See Section 6.1 for the registration 389 template. 391 All attribute names implicitly have a ".priv" and a ".shared" suffix 392 which maps to private and shared versions of the entry. Retrieving 393 an annotation without using either suffix includes both. The client 394 MUST specify either a ".priv" or ".shared" suffix when setting an 395 annotation. 397 value 398 A string or binary data representing the value of the annotation. 399 To delete an annotation, the client can store "NIL" into the 400 value. The content represented by the string is determined by the 401 Content-Type used to register the entry (see Section 6.1 for entry 402 registration templates). Where applicable, the registered 403 Content-Type MUST include a charset parameter. Text values SHOULD 404 use the utf-8 [RFC3629] character set. 405 Note that binary data (data which may contain the NUL octet) is 406 allowed (e.g., for storing images etc), and this extension uses 407 the "literal8" syntax element [RFC4466] to allow such data to be 408 written to or read from the server. 410 size 411 The size of the value, in octets. Set automatically by the 412 server, read-only to clients. If the client requests the size 413 attribute for a non-existent entry, then the server MUST return 414 "0" (zero) for the size. 416 3.3. Private versus Shared and Access Control 418 As discussed in the ANNOTATE [I-D.ietf-imapext-annotate] extension 419 there is a need to support both private and shared annotations. This 420 document adopts the scheme used in [I-D.ietf-imapext-annotate] that 421 adds two standard suffixes for all attributes: ".shared" and ".priv". 422 A GETMETADATA or extended LIST command which specifies neither uses 423 both. SETMETADATA commands MUST explicitly use .priv or .shared 424 suffixes. 426 A user can only set and retrieve private or shared annotations on a 427 mailbox which exists and is returned to them via a LIST or LSUB 428 command, irrespective of whether they have read or write access to 429 the actual message content of the mailbox. If the client attempts to 430 set or retrieve annotations on other mailboxes, the server MUST 431 respond with a NO response. 433 If the METADATA extension is present, support for shared annotations 434 is REQUIRED, whilst support for private annotations is OPTIONAL. 435 This recognizes the fact that support for private annotations may 436 introduce significantly more complexity to a server in terms of 437 tracking ownership of the annotations, how quota is determined for 438 users based on their own annotations etc. Clients that support the 439 METADATA extension MUST handle both shared and private annotations. 441 4. IMAP Protocol Changes 443 4.1. General Considerations 445 The new SETMETADATA command and the METADATA response each have a 446 mailbox name argument, indicating that the annotations being referred 447 to are attached to the specified mailbox. An empty string can be 448 used for the mailbox name to signify server annotations. 450 Both "*" and "%" list wildcard characters MAY be used in the mailbox 451 name argument in the SETMETADATA command to match all possible 452 occurrences of a mailbox name pattern. However, "*" or "%" by 453 themselves MUST NOT match the empty string (server) entries. Server 454 entries can only be accessed by explicitly using the empty string as 455 the mailbox name. 457 Servers SHOULD ensure that mailbox annotations are automatically 458 moved when the mailbox they refer to is renamed, i.e. the annotations 459 follow the mailbox. Servers SHOULD delete annotations for a mailbox 460 when the mailbox is deleted, so that a mailbox created with the same 461 name as a previously existing mailbox does not inherit the old 462 mailbox annotations. Servers SHOULD allow annotations on all 'types' 463 of mailbox, including ones reporting \Noselect for their LIST 464 response. Servers can implicitly remove \Noselect mailboxes when all 465 child mailboxes are removed, and as such any annotations associated 466 with the \Noselect mailbox SHOULD be removed. 468 The server is allowed to impose limitations on the size of any one 469 annotation or the total number of annotations for a single mailbox or 470 for the server as a whole. However, the server MUST accept a minimum 471 annotation data size of at least 1024 bytes, and a minimum annotation 472 count per server or mailbox of at least 10. 474 Some annotations may be "read-only" - i.e. they are set by the server 475 and cannot be changed by the client. Also, such annotations may be 476 "computed" - i.e. the value changes based on underlying properties of 477 the mailbox. For example, an annotation reporting the total size of 478 all messages in the mailbox would change as messages are added or 479 removed. Or, an annotation containing an IMAP URL for the mailbox 480 would change if the mailbox was renamed. 482 4.2. GETMETADATA Command 484 This extension adds the GETMETADATA command. This allows clients to 485 retrieve server annotations. Mailbox annotations are retrieved via 486 the extended LIST command described in the next section. 488 This command is only available in authenticated or selected state 489 [RFC3501]. 491 Arguments: entry-specifier 492 attribute-specifier 494 Responses: required METADATA response 496 Result: OK - command completed 497 NO - command failure: can't access annotations on 498 the server 499 BAD - command unknown or arguments invalid 501 Example: 503 C: a GETMETADATA /comment value.priv 504 S: * METADATA /comment (value.priv "My comment") 505 S: a OK GETMETADATA complete 507 In the above example, the contents of the "value.priv" attribute 508 for the "/comment" server entry is requested by the client and 509 returned by the server. 511 "*" and "%" wildcard characters can be used in the entry specifier to 512 match one or more characters at that position, with the exception 513 that "%" does not match the "/" hierarchy delimiter. Thus an entry 514 specifier of "/%" would match entries such as "/comment" and "/motd", 515 but not "/comment/note". 517 Example: 519 C: a GETMETADATA /* value.priv 520 S: * METADATA /comment (value.priv "My comment") 521 /motd (value.priv "Closed at 1 pm") 522 S: a OK GETMETADATA complete 524 In the above example, the contents of the "value.priv" attributes 525 for any server entries are requested by the client and returned by 526 the server. 528 Example: 530 C: a GETMETADATA /% value 531 S: * METADATA /comment (value.priv "My comment") 532 (value.shared "Your comment") 533 /motd (value.priv "Its sunny outside!" 534 (value.shared "Today is a Holiday") 535 S: a OK GETMETADATA complete 537 In the above example, the contents of the "value" attributes for 538 server entries at the top level of the entry hierarchy only, are 539 requested by the client and returned by the server. Both the 540 .priv and .shared values are returned, as neither were explicitly 541 requested. 543 Entry and attribute specifiers can be lists of atomic specifiers, so 544 that multiple items of each type may be returned in a single 545 GETMETADATA command. 547 Example: 549 C: a GETMETADATA (/comment /motd) value.priv 550 S: * METADATA /comment (value.priv "My comment") 551 /motd (value.priv "Its sunny outside!") 552 S: a OK GETMETADATA complete 554 In the above example, the contents of the "value.priv" attributes 555 for the two server entries "/comment" and "/motd" are requested by 556 the client and returned by the server. 558 Example: 560 C: a GETMETADATA /comment (value.priv 561 size.priv) 562 S: * METADATA /comment (value.priv "My comment" 563 size.priv "10") 564 S: a OK GETMETADATA complete 566 In the above example, the contents of the "value.priv" and 567 "size.priv" attributes for the "/comment" server entry are 568 requested by the client and returned by the server. 570 4.3. Extended LIST Command Extensions 572 This extension adds the METADATA LIST command selection and return 573 option types, extending the LIST-EXTENDED extension. This allows 574 clients to retrieve mailbox annotations. 576 The LIST-EXTENDED "METADATA" selection option type is used to request 577 that the extended LIST command match mailboxes which have an 578 annotation with a specific entry and value. It can also be used to 579 test for the existence of a particular annotation entry on a mailbox. 580 This selection option takes one or more entry/attribute/value triples 581 to use as tests. A mailbox matches this criteria if it has an entry, 582 attribute and value matching the ones specified. In the case of 583 multiple criteria being specified, mailbox MUST only match when all 584 criteria match ("and" operation). To test for the existence of an 585 entry, a test for the attribute "value" with the empty string "" as 586 the value argument can be used. To test for the absence of an entry, 587 a test for the attribute "value" with NIL as the value argument can 588 be used. Clients SHOULD only use entries defined with a "text" 589 Content-Type in the selection option arguments. 591 Each entry/attribute/value triple specified in the selection option 592 MAY include a match type specifier and MAY include a collation 593 [I-D.ietf-imapext-i18n] identifier. If the match type is specified, 594 then that match operation MUST be used when matching the provided 595 value with the corresponding annotation entry values in mailboxes. 596 If the match type is not specified, then a default of "CONTAINS" 597 (substring match) MUST be used. If the collation identifier is 598 specified, then that collation MUST be used to do the comparison of 599 the annotation entry values being tested. If the collation 600 identifier is not specified, then the active collation as defined by 601 [I-D.ietf-imapext-i18n] is used. Possible values for the match type 602 are: 604 +----------+-----------------------------------------------+ 605 | Match | Description | 606 +----------+-----------------------------------------------+ 607 | IS | Equality test is done | 608 | CONTAINS | Substring match is done | 609 | GT | Greater than relational test is done | 610 | GE | Greater than or equal relational test is done | 611 | LE | Less than or equal relational test is done | 612 | LT | Less than relational test is done | 613 +----------+-----------------------------------------------+ 615 The "NOT" match type modifier results in a negation of the comparison 616 - i.e. it adds the ability to search for annotations that do not 617 match or contain specific text. 619 The LIST-EXTENDED "METADATA" return option type is used to request 620 that the extended LIST command return specific annotation entries for 621 each mailbox returned in the LIST responses. A list of entries and 622 attributes to return can be specified in a manner similar to the 623 GETMETADATA command. 625 Example: 627 C: a LIST "" "INBOX" RETURN (METADATA (/comment value.priv)) 628 S: * LIST "/" "INBOX" 629 (METADATA (/comment (value.priv "My comment"))) 630 S: a OK LIST complete 632 In the above example, the contents of the "value.priv" attribute 633 for the "/comment" entry for the mailbox INBOX is requested by the 634 client and returned by the server. 636 "*" and "%" wildcard characters can be used in the entry specifier to 637 match one or more characters at that position, with the exception 638 that "%" does not match the "/" hierarchy delimiter. Thus an entry 639 specifier of "/%" would match entries such as "/comment" and 640 "/check", but not "/comment/note". 642 Example: 644 C: a LIST "" "INBOX" RETURN (METADATA (/* value.priv)) 645 S: * LIST "/" "INBOX" 646 (METADATA (/comment (value.priv "My comment") 647 /check (value.priv "true"))) 648 S: a OK LIST complete 650 In the above example, the contents of the "value.priv" attributes 651 for any entries for the mailbox INBOX are requested by the client 652 and returned by the server. 654 Example: 656 C: a LIST "" "INBOX" RETURN (METADATA (/% value)) 657 S: * LIST "/" "INBOX" 658 (METADATA (/comment (value.priv "My comment") 659 (value.shared "Your comment") 660 /motd (value.priv "Its sunny outside!" 661 (value.shared "Today is a Holiday"))) 662 S: a OK LIST complete 664 In the above example, the contents of the "value" attributes for 665 entries for the mailbox INBOX at the top level of the entry 666 hierarchy only, are requested by the client and returned by the 667 server. Both the .priv and .shared values are returned, as 668 neither were explicitly requested. 670 Entry and attribute specifiers can be lists of atomic specifiers, so 671 that multiple items of each type may be returned in a single LIST 672 command. 674 Example: 676 C: a LIST "" "INBOX" RETURN (METADATA ((/comment /motd) 677 value.priv)) 678 S: * LIST "/" "INBOX" 679 (METADATA (/comment (value.priv "My comment") 680 /motd (value.priv "Its sunny outside!"))) 681 S: a OK LIST complete 683 In the above example, the contents of the "value.priv" attributes 684 for the two entries "/comment" and "/motd" for the mailbox INBOX 685 are requested by the client and returned by the server. 687 Example: 689 C: a LIST "" "INBOX" RETURN (METADATA (/comment 690 (value.priv size.priv))) 691 S: * LIST "/" "INBOX" 692 (METADATA (/comment (value.priv "My comment" 693 size.priv "10"))) 694 S: a OK LIST complete 696 In the above example, the contents of the "value.priv" and 697 "size.priv" attributes for the "/comment" entry for the mailbox 698 INBOX are requested by the client and returned by the server. 700 Example: 702 C: a LIST "" ("INBOX" "FOOBOX" "BARBOX") RETURN 703 (METADATA (/comment value.priv)) 704 S: * LIST "/" "INBOX" 705 (METADATA (/comment (value.priv "My comment"))) 706 S: * LIST "/" "FOOBOX" 707 (METADATA (/comment (value.priv "Another comment"))) 708 S: * LIST "/" "BARBOX" 709 (METADATA (/comment (value.priv NIL))) 710 S: a OK LIST complete 712 In the above example, the contents of the "value.priv" attribute 713 for the "/comment" entry for the mailboxes INBOX, FOOBOX and 714 BARBOX are requested by the client and returned by the server. 715 Note that the mailbox BARBOX does not contain the entry, hence NIL 716 is returned for the attribute value. 718 Example: 720 C: a LIST (METADATA ("/comment" "value" "comm" 721 (NOT CONTAINS))) "" "*" 722 S: * LIST () "/" "INBOX" 723 S: * LIST (\NoInferiors) "/" "FOOBOX" 724 S: a OK LIST complete 726 In the above example, the client requests that any mailbox in the 727 entire hierarchy that does not contain the text "comm" in any 728 "value" attribute of the "/comment" entry be returned. Two 729 mailboxes are returned in separate responses. Note that the 730 client did not ask for annotations to be returned in the 731 responses. 733 Example: 735 C: a LIST (METADATA ("/comment" "value" "")) 736 "" "*" 737 S: * LIST () "/" "INBOX" 738 S: * LIST (\NoInferiors) "/" "FOOBOX" 739 S: a OK LIST complete 741 In the above example, the client requests that any mailbox in the 742 entire hierarchy containing the "/comment" entry be returned. Two 743 mailboxes are returned in separate responses. Note that the 744 client did not ask for annotations to be returned in the 745 responses. 747 Example: 749 C: a LIST (METADATA ("/comment" "value" NIL)) 750 "" "*" 751 S: * LIST (\NoInferiors) "/" "BARBOX" 752 S: a OK LIST complete 754 In the above example, the client requests that any mailbox in the 755 entire hierarchy that does not have a "/comment" entry be 756 returned. One mailbox is returned in a response. Note that the 757 client did not ask for annotations to be returned in the 758 responses. 760 Example: 762 C: a LIST (METADATA ("/comment" "value" "HELP" 763 (IS "i;octet")) "" "*" 764 RETURN (METADATA (/comment size.priv)) 765 S: * LIST "/" "INBOX" 766 (METADATA (/comment (size.priv "10"))) 767 S: * LIST "/" "FOOBOX" 768 (METADATA (/comment (size.priv "15"))) 769 S: a OK LIST complete 771 In the above example, the client requests that any mailbox in the 772 entire hierarchy with the exact text "HELP" in any "value" 773 attribute of the "/comment" entry be returned. The client 774 provides an explicit match type and collation identifier. Two 775 mailboxes are returned in separate responses. The client also 776 asked for annotation sizes to be returned in the responses. 778 4.3.1. Unsolicited LIST response 780 Servers SHOULD send unsolicited LIST responses if mailbox annotations 781 are changed by a third-party, allowing servers to keep clients 782 updated with changes. Unless explicitly changed by an IMAP 783 extension, unsolicited mailbox annotations MUST only be returned for 784 the currently selected mailbox. 786 Unsolicited LIST responses MUST only contain entry names, not the 787 attributes and values. If the client wants to update any cached 788 values it must explicitly retrieve those using a LIST command. 790 The LIST response can contain multiple entries in a single response, 791 but the server is free to return multiple responses for each entry or 792 group of entries if it desires. 794 Example: 796 C: a NOOP 797 S: * LIST "/" "INBOX" (METADATA (/comment)) 798 S: a OK NOOP complete 800 In the above example, the server sends an unsolicited LIST 801 response indicating that the "/comment" entry of the mailbox 802 "INBOX" has been changed. 804 4.4. SETMETADATA Command 806 This extension adds the SETMETADATA command. This allows clients to 807 set annotations. 809 This command is only available in authenticated or selected state 811 [RFC3501]. 813 Arguments: mailbox-name 814 entry 815 attribute-value 816 list of entry, attribute-values 818 Responses: no specific responses for this command 820 Result: OK - command completed 821 NO - command failure: can't set annotations, 822 or annotation too big or too many 823 BAD - command unknown or arguments invalid 825 This command sets the specified list of entries by adding or 826 replacing the specified attributes with the values provided, on the 827 specified existing mailboxes. Clients can use NIL for values of 828 attributes it wants to remove from entries. The server MAY return a 829 METADATA response containing the updated annotation data. Clients 830 MUST NOT assume that a METADATA response will be sent, and MUST 831 assume that if the command succeeds then the annotation has been 832 changed. 834 If the server is unable to set an annotation because the size of its 835 value is too large, the server MUST return a tagged NO response with 836 a "[METADATA TOOBIG]" response code. 838 If the server is unable to set a new annotation because the maximum 839 number of allowed annotations has already been reached, the server 840 MUST return a tagged NO response with a "[METADATA TOOMANY]" response 841 code. 843 If the server is unable to set a new annotation because it does not 844 support private annotations on one of the specified mailboxes, the 845 server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" 846 response code. 848 Example: 850 C: a SETMETADATA INBOX /comment 851 (value.priv "My new comment") 852 S: a OK SETMETADATA complete 854 In the above example, the entry "/comment" for the mailbox "INBOX" 855 is created (if not already present) and the private attribute 856 "value" with data set to "My new comment" is created if not 857 already present, or replaced if it previously exists. 859 Example: 861 C: a SETMETADATA INBOX /comment (value.priv NIL) 862 S: a OK SETMETADATA complete 864 In the above example, the private "value" attribute of the entry 865 "/comment" is removed from the mailbox "INBOX". 867 Annotations on multiple mailboxes can be set in a single SETMETADATA 868 command by using a wildcard specification for the mailbox name. 870 Example: 872 C: a SETMETADATA INBOX.% /comment 873 (value.priv "My new comment") 874 S: a OK SETMETADATA complete 876 In the above example, the entry "/comment" for all mailboxes at 877 the top-level of the "INBOX" hierarchy are created (if not already 878 present) and the private attribute "value" are created 879 respectively for each entry if not already present, or replaced if 880 they previously existed. 882 Multiple entries can be set in a single SETMETADATA command by 883 listing entry-attribute-value pairs in the list. 885 Example: 887 C: a SETMETADATA INBOX (/comment 888 (value.priv "My new comment") 889 /thread 890 (value.priv "REFERENCES ALL")) 891 S: a OK SETMETADATA complete 893 In the above example, the entries "/comment" and "/thread" for the 894 mailbox "INBOX" are created (if not already present) and the 895 "value.priv" attributes are created respectively for each entry if 896 not already present, or replaced if they previously existed. 898 Multiple attributes can be set in a single SETMETADATA command by 899 listing multiple attribute-value pairs in the entry list. 901 Example: 903 C: a SETMETADATA INBOX /comment 904 (value.priv "My new comment" 905 value.shared "foo's bar") 906 S: a OK SETMETADATA complete 908 In the above example, the entry "/comment" for the mailbox "INBOX" 909 is created (if not already present) and the attributes 910 "value.priv" and "value.shared" are created if not already 911 present, or replaced if they previously existed. 913 Example: 915 C: a SETMETADATA INBOX /comment 916 (value.priv "My new comment") 917 S: a NO [METADATA TOOMANY] SETMETADATA failed 919 In the above example, the server is unable to set the requested 920 (new) annotation as it has reached the limit on the number of 921 annotations it can support on the specified mailbox. 923 4.5. METADATA Response 925 The METADATA response displays results of a GETMETADATA command, or 926 can be returned as an unsolicited response at anytime by the server 927 in response to a change in a server annotation. 929 Servers SHOULD send unsolicited METADATA responses if server 930 annotations are changed by a third-party, allowing servers to keep 931 clients updated with changes. 933 Unsolicited METADATA responses MUST only contain entry names, not the 934 attributes and values. If the client wants to update any cached 935 values it must explicitly retrieve those using a GETMETADATA command. 937 The METADATA response can contain multiple entries in a single 938 response, but the server is free to return multiple responses for 939 each entry or group of entries if it desires. 941 This response is only available in authenticated or selected state 942 [RFC3501]. 944 4.5.1. METADATA response with attributes and values 946 The response consists of a list of entries each of which has a list 947 of attribute-value pairs. 949 Example: 951 C: a GETMETADATA /comment value.priv 952 S: * METADATA /comment (value.priv "My comment") 953 S: a OK GETMETADATA complete 955 In the above example, a single entry with a single attribute-value 956 pair is returned by the server. 958 Example: 960 C: a GETMETADATA (/comment /motd) value.priv 961 S: * METADATA /comment (value.priv "My comment") 962 /motd (value.priv "Its sunny outside!") 963 S: a OK GETMETADATA complete 965 In the above example, two entries each with a single attribute- 966 value pair is returned by the server. 968 Example: 970 C: a GETMETADATA (/comment /motd) value.priv 971 S: * METADATA /comment (value.priv "My comment") 972 S: * METADATA /motd (value.priv "Its sunny outside!") 973 S: a OK GETMETADATA complete 975 In the above example, the server returns two separate responses 976 for each of the two entries requested. 978 Example: 980 C: a GETMETADATA /comment (value.priv size.priv) 981 S: * METADATA /comment (value.priv "My comment" 982 size.priv "10") 983 S: a OK GETMETADATA complete 985 In the above example, a single entry with two attribute-value 986 pairs is returned by the server. 988 4.5.2. Unsolicited METADATA response without attributes and values 990 The response consists of a parenthesized list of entries, each of 991 which have changed on the server. 993 Example: 995 C: a NOOP 996 S: * METADATA (/comment) 997 S: a OK NOOP complete 999 In the above example, the server indicates that the "/comment" 1000 server entry has been changed. 1002 Example: 1004 C: a NOOP 1005 S: * METADATA (/comment /motd) 1006 S: a OK NOOP complete 1008 In the above example, the server indicates a change to two server 1009 entries. 1011 5. Formal Syntax 1013 The following syntax specification uses the Augmented Backus-Naur 1014 Form (ABNF) notation as specified in [RFC4234]. 1016 Non-terminals referenced but not defined below are as defined by 1017 [RFC3501] with the new definitions in [RFC4466] superseding those in 1018 [RFC3501]. 1020 Except as noted otherwise, all alphabetic characters are case- 1021 insensitive. The use of upper or lower case characters to define 1022 token strings is for editorial clarity only. Implementations MUST 1023 accept these strings in a case-insensitive fashion. 1025 annotate-data = "METADATA" SP entry-list 1027 att-select = "value" / "value.priv" / "value.shared" 1028 ; the only attributes that can be selected 1030 att-value = attrib SP value 1032 attrib = astring 1033 ; dot-separated attribute name 1034 ; MUST NOT contain "*" or "%" 1036 attribs = attrib / "(" attrib *(SP attrib) ")" 1037 ; one or more attribute specifiers 1039 capability =/ "METADATA" 1040 ; defines the capability for this extension 1042 command-auth =/ setmetadata / getmetadata 1043 ; adds to original IMAP command 1045 collation = astring 1046 ; collation identifier as defined by 1047 ; [I-D.newman-i18n-comparator] 1049 entries = entry-match / 1050 "(" entry-match *(SP entry-match) ")" 1051 ; entry specifiers that can include wildcards 1053 entry = astring 1054 ; slash-separated path to entry 1055 ; MUST NOT contain "*" or "%" 1057 entry-att = entry SP "(" att-value *(SP att-value) ")" 1059 entry-list = entry-att *(SP entry-att) / 1060 "(" entry *(SP entry) ")" 1061 ; entry attribute-value pairs list for 1062 ; GETMETADATA response, or 1063 ; parenthesised entry list for unsolicited 1064 ; notification of annotation changes 1066 entry-match = list-mailbox 1067 ; slash-separated path to entry 1068 ; MAY contain "*" or "%" for use as wildcards 1070 getmetadata = "GETMETADATA" SP entries SP attribs 1072 list-select-base-opt =/ "METADATA" SP 1073 "(" list-select-metadata 1074 *(SP list-select-metadata) ")" 1075 ; adds a new selection option type to 1076 ; LIST-EXTENDED. When evaluating multiple entry, 1077 ; attribute, value combinations, a match to 1078 ; a mailbox must occur when all items match. 1080 list-select-metadata = entry-match SP att-select SP value 1081 [SP "(" matchtype [SP collation] ")"] 1082 ; value set to the empty string means match 1083 ; if that entry and attribute exist. 1084 ; value set to NIL means match if that entry 1085 ; and attribute do not exist. 1086 ; An optional match type and collation can also 1087 ; be specified. 1089 matchtype = ["NOT" SP] ("IS" / "CONTAINS" / 1090 "GT" / "GE" / "LE" / "LT") 1091 ; match types for LIST-EXTENDED string 1092 ; comparisons - see Section 4.3. 1094 response-payload =/ annotate-data 1095 ; adds to original IMAP data responses 1097 resp-text-code =/ "METADATA" SP ("TOOBIG" / "TOOMANY" / 1098 "NOPRIVATE") 1099 ; new response codes for SETMETADATA 1100 ; failures 1102 setmetadata = "SETMETADATA" SP list-mailbox 1103 SP setentryatt 1104 ; empty string for list-mailbox implies 1105 ; server annotation. 1107 setentryatt = entry-att / "(" entry-att *(SP entry-att) ")" 1109 value = nstring / literal8 1111 6. IANA Considerations 1113 Entry names MUST be specified in a standards track or IESG approved 1114 experimental RFC, or fall under the vendor namespace. Attribute 1115 names MUST be specified in a standards track or IESG approved 1116 experimental RFC. 1118 Each entry registration MUST include a content-type that is used to 1119 indicate the nature of the annotation value. Where applicable a 1120 charset parameter MUST be included with the content-type. 1122 6.1. Entry and Attribute Registration Template 1124 To: iana@iana.org 1125 Subject: IMAP METADATA Registration 1127 Please register the following IMAP METADATA item: 1129 [ ] Entry [ ] Attribute 1131 [ ] Mailbox [ ] Server 1133 Name: ______________________________ 1135 Description: _______________________ 1137 ____________________________________ 1139 ____________________________________ 1141 Content-type: ____________________ 1143 Contact person: ____________________ 1145 email: ____________________ 1147 6.2. Server Entry Registrations 1149 The following templates specify the IANA registrations of annotation 1150 entries specified in this document. 1152 6.2.1. /comment 1154 To: iana@iana.org 1155 Subject: IMAP METADATA Registration 1157 Please register the following IMAP METADATA item: 1159 [x] Entry [ ] Attribute 1161 [ ] Mailbox [x] Server 1163 Name: /comment 1165 Description: Defined in IMAP METADATA extension document. 1167 Content-type: text/plain; charset=utf-8 1169 Contact person: Cyrus Daboo 1171 email: cyrus@daboo.name 1173 6.2.2. /motd 1175 To: iana@iana.org 1176 Subject: IMAP METADATA Registration 1178 Please register the following IMAP METADATA item: 1180 [x] Entry [ ] Attribute 1182 [ ] Mailbox [x] Server 1184 Name: /motd 1186 Description: Defined in IMAP METADATA extension document. 1188 Content-type: text/plain; charset=utf-8 1190 Contact person: Cyrus Daboo 1192 email: cyrus@daboo.name 1194 6.2.3. /admin 1196 To: iana@iana.org 1197 Subject: IMAP METADATA Registration 1199 Please register the following IMAP METADATA item: 1201 [x] Entry [ ] Attribute 1203 [ ] Mailbox [x] Server 1205 Name: /admin 1207 Description: Defined in IMAP METADATA extension document. 1209 Content-type: text/plain; charset=utf-8 1211 Contact person: Cyrus Daboo 1213 email: cyrus@daboo.name 1215 6.3. Mailbox Entry Registrations 1217 The following templates specify the IANA registrations of annotation 1218 entries specified in this document. 1220 6.3.1. /comment 1222 To: iana@iana.org 1223 Subject: IMAP METADATA Registration 1225 Please register the following IMAP METADATA item: 1227 [x] Entry [ ] Attribute 1229 [x] Mailbox [ ] Server 1231 Name: /comment 1233 Description: Defined in IMAP METADATA extension document. 1235 Content-type: text/plain; charset=utf-8 1237 Contact person: Cyrus Daboo 1239 email: cyrus@daboo.name 1241 6.3.2. /sort 1243 To: iana@iana.org 1244 Subject: IMAP METADATA Registration 1246 Please register the following IMAP METADATA item: 1248 [x] Entry [ ] Attribute 1250 [x] Mailbox [ ] Server 1252 Name: /sort 1254 Description: Defined in IMAP METADATA extension document. 1256 Content-type: text/plain; charset=utf-8 1258 Contact person: Cyrus Daboo 1260 email: cyrus@daboo.name 1262 6.3.3. /thread 1264 To: iana@iana.org 1265 Subject: IMAP METADATA Registration 1267 Please register the following IMAP METADATA item: 1269 [x] Entry [ ] Attribute 1271 [x] Mailbox [ ] Server 1273 Name: /thread 1275 Description: Defined in IMAP METADATA extension document. 1277 Content-type: text/plain; charset=utf-8 1279 Contact person: Cyrus Daboo 1281 email: cyrus@daboo.name 1283 6.3.4. /check 1285 To: iana@iana.org 1286 Subject: IMAP METADATA Registration 1288 Please register the following IMAP METADATA item: 1290 [x] Entry [ ] Attribute 1292 [x] Mailbox [ ] Server 1294 Name: /check 1296 Description: Defined in IMAP METADATA extension document. 1298 Content-type: text/plain; charset=utf-8 1300 Contact person: Cyrus Daboo 1302 email: cyrus@daboo.name 1304 6.3.5. /checkperiod 1306 To: iana@iana.org 1307 Subject: IMAP METADATA Registration 1309 Please register the following IMAP METADATA item: 1311 [x] Entry [ ] Attribute 1313 [x] Mailbox [ ] Server 1315 Name: /checkperiod 1317 Description: Defined in IMAP METADATA extension document. 1319 Content-type: text/plain; charset=utf-8 1321 Contact person: Cyrus Daboo 1323 email: cyrus@daboo.name 1325 6.4. Attribute Registrations 1327 The following templates specify the IANA registrations of annotation 1328 attributes specified in this document. 1330 6.4.1. value 1332 To: iana@iana.org 1333 Subject: IMAP METADATA Registration 1335 Please register the following IMAP METADATA item: 1337 [ ] Entry [x] Attribute 1339 [ ] Mailbox [ ] Server 1341 Name: value 1343 Description: Defined in IMAP METADATA extension document. 1345 Content-type: - 1347 Contact person: Cyrus Daboo 1349 email: cyrus@daboo.name 1351 6.4.2. size 1353 To: iana@iana.org 1354 Subject: IMAP METADATA Registration 1356 Please register the following IMAP METADATA item: 1358 [ ] Entry [x] Attribute 1360 [ ] Mailbox [ ] Server 1362 Name: size 1364 Description: Defined in IMAP METADATA extension document. 1366 Content-type: - 1368 Contact person: Cyrus Daboo 1370 email: cyrus@daboo.name 1372 6.5. LIST-EXTENDED Registration 1374 To: iana@iana.org 1375 Subject: Registration of LIST-EXTENDED option METADATA 1377 LIST-EXTENDED option name: METADATA 1378 LIST-EXTENDED option type: SELECTION 1380 Implied return options(s): (none) 1382 LIST-EXTENDED option description: 1383 The "METADATA" selection option type is used to request 1384 that the extended LIST command match mailboxes which have 1385 an annotation with a specific entry and value. It can 1386 also be used to test for the existence of a particular 1387 annotation entry on a mailbox. 1389 Published specification : XXXX, Section 4.3. 1391 Security considerations: XXXX, Section 7. 1393 Intended usage: COMMON 1395 Person and email address to contact for further information: 1396 Cyrus Daboo 1398 Owner/Change controller: iesg@ietf.org 1400 To: iana@iana.org 1401 Subject: Registration of LIST-EXTENDED option METADATA 1403 LIST-EXTENDED option name: METADATA 1405 LIST-EXTENDED option type: RETURN 1407 LIST-EXTENDED option description: Causes the LIST command to 1408 return the specified mailbox annotations. 1410 Published specification : XXXX, Section 4.3. 1412 Security considerations: XXXX, Section 7. 1414 Intended usage: COMMON 1416 Person and email address to contact for further information: 1417 Cyrus Daboo 1419 Owner/Change controller: iesg@ietf.org 1421 7. Security Considerations 1423 Annotations whose values are intended to remain private MUST use 1424 .priv values, and not .shared values which may be accessible to other 1425 users. 1427 Annotations can contain arbitrary sized data. As such servers MUST 1428 ensure that size limits are enforced to prevent a user from using up 1429 all available space on a server and preventing use by others. 1431 Excluding the above issues the METADATA extension does not raise any 1432 security considerations that are not present in the base IMAP 1433 protocol, and these issues are discussed in [RFC3501]. 1435 8. References 1437 8.1. Normative References 1439 [I-D.ietf-imapext-i18n] 1440 Newman, C., "Internet Message Access Protocol 1441 Internationalization", draft-ietf-imapext-i18n-06 (work in 1442 progress), March 2006. 1444 [I-D.ietf-imapext-list-extensions] 1445 Leiba, B. and A. Melnikov, "IMAP4 LIST Command 1446 Extensions", draft-ietf-imapext-list-extensions-17 (work 1447 in progress), April 2006. 1449 [I-D.ietf-imapext-sort] 1450 Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 1451 PROTOCOL - SORT AND THREAD EXTENSION", 1452 draft-ietf-imapext-sort-17 (work in progress), May 2004. 1454 [I-D.newman-i18n-comparator] 1455 Newman, C., "Internet Application Protocol Collation 1456 Registry", draft-newman-i18n-comparator-13 (work in 1457 progress), August 2006. 1459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1460 Requirement Levels", BCP 14, RFC 2119, March 1997. 1462 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1463 Configuration Access Protocol", RFC 2244, November 1997. 1465 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1466 4rev1", RFC 3501, March 2003. 1468 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1469 10646", STD 63, RFC 3629, November 2003. 1471 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1472 Specifications: ABNF", RFC 4234, October 2005. 1474 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1475 ABNF", RFC 4466, April 2006. 1477 8.2. Informative References 1479 [I-D.ietf-imapext-annotate] 1480 Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension", 1481 draft-ietf-imapext-annotate-15 (work in progress), 1482 March 2006. 1484 Appendix A. Acknowledgments 1486 The ideas expressed in this document are based on the message 1487 annotation document that was co-authored by Randall Gellens. The 1488 participants of the IMAPext working group made significant 1489 contributions to this work. 1491 Author's Address 1493 Cyrus Daboo 1494 Apple Inc. 1495 1 Infinite Loop 1496 Cupertino, CA 95014 1497 USA 1499 Email: cyrus@daboo.name 1500 URI: http://www.apple.com/ 1502 Full Copyright Statement 1504 Copyright (C) The IETF Trust (2007). 1506 This document is subject to the rights, licenses and restrictions 1507 contained in BCP 78, and except as set forth therein, the authors 1508 retain all their rights. 1510 This document and the information contained herein are provided on an 1511 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1512 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1513 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1514 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1515 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1516 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1518 Intellectual Property 1520 The IETF takes no position regarding the validity or scope of any 1521 Intellectual Property Rights or other rights that might be claimed to 1522 pertain to the implementation or use of the technology described in 1523 this document or the extent to which any license under such rights 1524 might or might not be available; nor does it represent that it has 1525 made any independent effort to identify any such rights. Information 1526 on the procedures with respect to rights in RFC documents can be 1527 found in BCP 78 and BCP 79. 1529 Copies of IPR disclosures made to the IETF Secretariat and any 1530 assurances of licenses to be made available, or the result of an 1531 attempt made to obtain a general license or permission for the use of 1532 such proprietary rights by implementers or users of this 1533 specification can be obtained from the IETF on-line IPR repository at 1534 http://www.ietf.org/ipr. 1536 The IETF invites any interested party to bring to its attention any 1537 copyrights, patents or patent applications, or other proprietary 1538 rights that may cover technology that may be required to implement 1539 this standard. Please address the information to the IETF at 1540 ietf-ipr@ietf.org. 1542 Acknowledgment 1544 Funding for the RFC Editor function is provided by the IETF 1545 Administrative Support Activity (IASA).