idnits 2.17.1 draft-daboo-imap-annotatemore-12.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 1508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1532. 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 (December 22, 2007) is 5962 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 855, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-imapext-i18n-14 == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-19 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 3 errors (**), 0 flaws (~~), 4 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 December 22, 2007 5 Expires: June 24, 2008 7 IMAP METADATA Extension 8 draft-daboo-imap-annotatemore-12 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 June 24, 2008. 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 Table of Contents 51 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 53 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Namespace of entries and attributes . . . . . . . . . . . 5 56 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5 57 3.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 7 58 3.3. Private versus Shared and Access Control . . . . . . . . . 8 59 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 8 60 4.1. General Considerations . . . . . . . . . . . . . . . . . . 8 61 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 9 62 4.3. Extended LIST Command Extensions . . . . . . . . . . . . . 11 63 4.3.1. Unsolicited LIST response . . . . . . . . . . . . . . 16 64 4.4. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 16 65 4.5. METADATA Response . . . . . . . . . . . . . . . . . . . . 19 66 4.5.1. METADATA response with attributes and values . . . . . 19 67 4.5.2. Unsolicited METADATA response without attributes 68 and values . . . . . . . . . . . . . . . . . . . . . . 20 69 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 71 6.1. Entry and Attribute Registration Template . . . . . . . . 23 72 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 23 73 6.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 24 74 6.2.2. /motd . . . . . . . . . . . . . . . . . . . . . . . . 24 75 6.2.3. /admin . . . . . . . . . . . . . . . . . . . . . . . . 25 76 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 25 77 6.3.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 25 78 6.3.2. /sort . . . . . . . . . . . . . . . . . . . . . . . . 26 79 6.3.3. /thread . . . . . . . . . . . . . . . . . . . . . . . 26 80 6.3.4. /check . . . . . . . . . . . . . . . . . . . . . . . . 27 81 6.3.5. /checkperiod . . . . . . . . . . . . . . . . . . . . . 27 82 6.4. LIST-EXTENDED Registration . . . . . . . . . . . . . . . . 27 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 87 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 88 Appendix B. Change History (to be removed prior to 89 publication as an RFC) . . . . . . . . . . . . . . . 30 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 Intellectual Property and Copyright Statements . . . . . . . . . . 34 93 1. Introduction and Overview 95 The goal of the METADATA extension is to provide a means for clients 96 to set and retrieve "annotations" or "meta data" on an IMAP server. 97 The annotations can be associated with specific mailboxes or the 98 server as a whole. The server can choose to support only server 99 annotations or both server and mailbox annotations. 101 A server that supports both server and mailbox annotations indicates 102 the presence of this extension by returning "METADATA" as one of the 103 supported capabilities in the CAPABILITY command response. The 104 "LIST-EXTENDED" [I-D.ietf-imapext-list-extensions] and "ENABLE" 105 [I-D.gulbrandsen-imap-enable] extensions MUST also be present. 107 A server that supports only server annotations indicates the presence 108 of this extension by returning "METADATA-SERVER" as one of the 109 supported capabilities in the CAPABILITY command response. The 110 "ENABLE" [I-D.gulbrandsen-imap-enable] extension MUST also be 111 present. There is no requirement that other extensions, including 112 "LIST-EXTENDED", be present in this case. 114 The METADATA extension adds two new commands and one new untagged 115 response to the IMAP base protocol. It adds one new LIST-EXTENDED 116 "selection" [I-D.ietf-imapext-list-extensions] option type and one 117 new LIST-EXTENDED "return" [I-D.ietf-imapext-list-extensions] option 118 type. 120 This extension makes the following changes to the IMAP protocol: 122 For server annotations only: 124 * adds a new SETMETADATA command 125 * adds a new GETMETADATA command 126 * adds a new METADATA untagged response 127 * adds a new METADATA response code 129 For server and mailbox annotation support: 131 * adds a new SETMETADATA command 132 * adds a new GETMETADATA command 133 * adds a new METADATA untagged response 134 * adds a new METADATA response code 135 * adds a new METADATA LIST-EXTENDED selection option type 136 * adds a new METADATA LIST-EXTENDED return option type 138 The data model used in METADATA is exactly the same as that used in 139 the ANNOTATE [I-D.ietf-imapext-annotate] extension to IMAP. This is 140 modeled after that of the Application Configuration Access Protocol 142 [RFC2244] with the exception of inheritance which is not deemed 143 necessary here. 145 Text comparisons may be done as part of the GETMETADATA or LIST- 146 EXTENDED commands. If the COMPARATOR [I-D.ietf-imapext-i18n] 147 extension is present, then comparisons are done using the comparator 148 in effect at the time. If the COMPARATOR extension is not present, 149 then comparisons MUST use the i;unicode-casemap comparator, as 150 defined in [RFC5051]. 152 The rest of this document describes the data model and protocol 153 changes more rigorously. 155 2. Conventions Used in This Document 157 In examples, "C:" and "S:" indicate lines sent by the client and 158 server respectively. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 Whitespace and line breaks have been added to the examples in this 165 document to promote readability. 167 3. Data Model 169 3.1. Overview 171 Mailboxes or the server as a whole may have zero or more annotations 172 associated with them. An annotation contains a uniquely named entry 173 with a set of uniquely named attributes, each of which has a value. 174 Annotations can be added to mailboxes when a mailbox name is provided 175 as the first argument to the new command, or to the server as a whole 176 when the empty string is provided as the first argument to the new 177 command. 179 For example, a general comment being added to a mailbox may have an 180 entry name of "/comment". This entry could include named attributes 181 such as "value" and "size" etc to represent properties and data 182 associated with the entry. 184 The protocol changes to IMAP described below allow a client to access 185 or change the values of any attributes in any annotation entry, 186 assuming it has sufficient access rights to do so. 188 3.2. Namespace of entries and attributes 190 Each annotation is an entry that has a hierarchical name, with each 191 component of the name separated by a slash ("/"). An entry name MUST 192 NOT contain two consecutive "/" characters and MUST NOT end with a 193 "/" character. 195 Each entry is made up of a set of attributes. Each attribute has a 196 hierarchical name, with each component of the name separated by a 197 period ("."). An attribute name MUST NOT contain two consecutive "." 198 characters and MUST NOT end with a "." character. 200 The value of an attribute is NIL (has no value), or a string of zero 201 or more octets. 203 Entry and attribute names MUST NOT contain asterisk ("*") or percent 204 ("%") characters and MUST NOT contain non-ASCII characters or the NUL 205 octet. Invalid entry or attribute names result in a BAD response in 206 any IMAP commands where they are used. 208 Attribute names MUST NOT contain any hierarchical components with the 209 names "priv" or "shared" as those have special meaning (see 210 Section 3.3). 212 Entry and attribute names are case-sensitive. 214 Use of control or punctuation characters in entry and attribute names 215 is strongly discouraged. 217 This specification defines an initial set of entry and attribute 218 names available for use with mailbox and server annotations. In 219 addition an extension mechanism is described to allow additional 220 names to be added for extensibility. 222 3.2.1. Entry Names 224 Entry names MUST be specified in a standards track or IESG approved 225 experimental RFC, or fall under the vendor namespace. See 226 Section 6.1 for the registration template. 228 3.2.1.1. Server Entries 230 These entries are used when the mailbox name argument to the new 231 SETMETADATA command is the empty string or with the new GETMETADATA 232 command. 234 /comment 235 Defines a comment or note associated with the server. 237 /motd 238 Defines a "message of the day" for the server. This entry is 239 always read-only - clients cannot change it. 241 /admin 242 Indicates a method for contacting the server administrator. The 243 value MUST be a URI (e.g., a mailto: or tel: URL). This entry is 244 always read-only - clients cannot change it. 246 /vendor/ 247 Defines the top-level of entries associated with the server as 248 created by a particular product of some vendor. This entry can be 249 used by vendors to provide server or client specific annotations. 250 The vendor-token MUST be registered with IANA, using the ACAP 251 [RFC2244] vendor subtree registry. 253 3.2.1.2. Mailbox Entries 255 These entries are used when the mailbox name argument to the new 256 SETMETADATA command is not the empty string, or with the new LIST- 257 EXTENDED selection option type, or in responses to these commands. 259 /comment 260 Defines a comment or note associated with a mailbox. 262 /sort 263 Defines the default sort criteria [I-D.ietf-imapext-sort] to use 264 when first displaying the mailbox contents to the user, or NIL if 265 sorting is not required. The text value MUST use the 'sort- 266 criteria' syntax defined by the Formal Syntax of 267 [I-D.ietf-imapext-sort] Section 5. Note that the presence of this 268 attribute does not imply that the server supports the IMAP SORT 269 [I-D.ietf-imapext-sort] extension - servers can choose to support 270 or not support SORT independently of this extension. In the 271 absence of the SORT extension, clients can choose to interpret 272 this entry as suggesting a client-side sort ordering of the 273 corresponding mailbox. 275 /thread 276 Defines the default thread criteria [I-D.ietf-imapext-sort] to use 277 when first displaying the mailbox contents to the user, or NIL if 278 threading is not required. If both sort and thread are not NIL, 279 then threading should take precedence over sorting. The text 280 value MUST use the 'thread-alg' syntax defined by the Formal 281 Syntax of [I-D.ietf-imapext-sort] Section 5. Note that the 282 presence of this attribute does not imply that the server supports 283 the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can 284 choose to support or not support THREAD independently of this 285 extension. In the absence of the THREAD extension, clients can 286 choose to interpret this entry as a client-side thread ordering of 287 the corresponding mailbox. 289 /check 290 Boolean value "true" or "false" that indicates whether this 291 mailbox should be checked at regular intervals by the client. The 292 interval in minutes is specified by the /checkperiod entry. When 293 appropriate clients SHOULD use the IMAP IDLE [RFC2177] extension 294 to poll the currently selected mailbox even when this value is set 295 to "true". 297 /checkperiod 298 Numeric value indicating a period of minutes that the client uses 299 to determine the interval of regular 'new mail' checks for the 300 corresponding mailbox. 302 /vendor/ 303 Defines the top-level of entries associated with a specific 304 mailbox as created by a particular product of some vendor. This 305 entry can be used by vendors to provide client specific 306 annotations. The vendor-token MUST be registered with IANA, using 307 the ACAP [RFC2244] vendor subtree registry. 309 3.2.2. Attribute Names 311 This specification defines two attribute names. Each attribute name 312 implicitly has a ".priv" and a ".shared" suffix which maps to private 313 and shared versions of the entry. Retrieving an annotation without 314 using either suffix includes both. The client MUST specify either a 315 ".priv" or ".shared" suffix when setting an annotation. 317 value 318 A string or binary data representing the value of the annotation. 319 To delete an annotation, the client can store "NIL" into the 320 value. The content represented by the string is determined by the 321 Content-Type used to register the entry (see Section 6.1 for entry 322 registration templates). Where applicable, the registered 323 Content-Type MUST include a charset parameter. Text values SHOULD 324 use the utf-8 [RFC3629] charset. 325 Note that binary data (data which may contain the NUL octet) is 326 allowed (e.g., for storing images etc), and this extension uses 327 the "literal8" syntax element [RFC4466] to allow such data to be 328 written to or read from the server. 330 size 331 The size of the value, in octets. Set automatically by the 332 server, read-only to clients. The text value MUST use the 333 'number' syntax defined by the Formal Syntax of [RFC3501] Section 334 9. In particular neither "NIL" nor the empty string are allowed. 335 If the client requests the size attribute for a non-existent 336 entry, then the server MUST return "0" (zero) for the size. 338 3.3. Private versus Shared and Access Control 340 As discussed in the ANNOTATE [I-D.ietf-imapext-annotate] extension 341 there is a need to support both private and shared annotations. This 342 document adopts the scheme used in [I-D.ietf-imapext-annotate] that 343 adds two standard suffixes for all attributes: ".shared" and ".priv". 344 A GETMETADATA or extended LIST command which specifies neither uses 345 both. SETMETADATA commands MUST explicitly use .priv or .shared 346 suffixes. 348 A user can only set and retrieve private or shared annotations on a 349 mailbox which exists and is returned to them via a LIST or LSUB 350 command, irrespective of whether they have read or write access to 351 the actual message content of the mailbox. If the client attempts to 352 set or retrieve annotations on other mailboxes, the server MUST 353 respond with a NO response. 355 If the METADATA extension is present, support for shared annotations 356 is REQUIRED, whilst support for private annotations is OPTIONAL. 357 This recognizes the fact that support for private annotations may 358 introduce significantly more complexity to a server in terms of 359 tracking ownership of the annotations, how quota is determined for 360 users based on their own annotations etc. Clients that support the 361 METADATA extension MUST handle both shared and private annotations. 363 4. IMAP Protocol Changes 365 4.1. General Considerations 367 The new SETMETADATA command and the METADATA response each have a 368 mailbox name argument. An empty string is used for the mailbox name 369 to signify server annotations. A non-empty string is used to signify 370 mailbox annotations attached to the corresponding mailbox. 372 Both "*" and "%" list wildcard characters MAY be used in the mailbox 373 name argument in the SETMETADATA command to match all possible 374 occurrences of a mailbox name pattern. However, "*" or "%" by 375 themselves MUST NOT match the empty string (server) entries. Server 376 entries can only be accessed by explicitly using the empty string as 377 the mailbox name. 379 Servers SHOULD ensure that mailbox annotations are automatically 380 moved when the mailbox they refer to is renamed, i.e. the annotations 381 follow the mailbox. This applies to a rename of the INBOX, with the 382 additional behavior that the annotations are copied from the original 383 INBOX to the renamed mailbox. i.e. mailbox annotations are preserved 384 on the INBOX when it is renamed. 386 Servers SHOULD delete annotations for a mailbox when the mailbox is 387 deleted, so that a mailbox created with the same name as a previously 388 existing mailbox does not inherit the old mailbox annotations. 390 Servers SHOULD allow annotations on all 'types' of mailbox, including 391 ones reporting \Noselect for their LIST response. Servers can 392 implicitly remove \Noselect mailboxes when all child mailboxes are 393 removed, and as such any annotations associated with the \Noselect 394 mailbox SHOULD be removed. 396 The server is allowed to impose limitations on the size of any one 397 annotation or the total number of annotations for a single mailbox or 398 for the server as a whole. However, the server MUST accept a minimum 399 annotation data size of at least 1024 bytes, and a minimum annotation 400 count per server or mailbox of at least 10. 402 Some annotations may be "read-only" - i.e. they are set by the server 403 and cannot be changed by the client. Also, such annotations may be 404 "computed" - i.e. the value changes based on underlying properties of 405 the mailbox. For example, an annotation reporting the total size of 406 all messages in the mailbox would change as messages are added or 407 removed. Or, an annotation containing an IMAP URL for the mailbox 408 would change if the mailbox was renamed. 410 This extension defines some unsolicited responses for use when 411 annotations are changed by some "third-party" (see Section 4.3.1 and 412 Section 4.5). The server MUST only send these unsolicited responses 413 if the client used the ENABLE command [I-D.gulbrandsen-imap-enable] 414 extension with the capability string "METADATA" earlier in the 415 session. 417 4.2. GETMETADATA Command 419 This extension adds the GETMETADATA command. This allows clients to 420 retrieve server annotations. Mailbox annotations are retrieved via 421 the extended LIST command described in the next section. 423 This command is only available in authenticated or selected state 424 [RFC3501]. 426 Arguments: entry-specifier 427 attribute-specifier 429 Responses: required METADATA response 431 Result: OK - command completed 432 NO - command failure: can't access annotations on 433 the server 434 BAD - command unknown or arguments invalid 436 Example: 438 C: a GETMETADATA /comment value.priv 439 S: * METADATA /comment (value.priv "My comment") 440 S: a OK GETMETADATA complete 442 In the above example, the contents of the "value.priv" attribute 443 for the "/comment" server entry is requested by the client and 444 returned by the server. 446 "*" and "%" wildcard characters can be used in the entry specifier to 447 match one or more characters at that position, with the exception 448 that "%" does not match the "/" hierarchy delimiter. Thus an entry 449 specifier of "/%" would match entries such as "/comment" and "/motd", 450 but not "/comment/note". 452 Example: 454 C: a GETMETADATA /* value.priv 455 S: * METADATA /comment (value.priv "My comment") 456 /motd (value.priv "Closed at 1 pm") 457 S: a OK GETMETADATA complete 459 In the above example, the contents of the "value.priv" attributes 460 for any server entries are requested by the client and returned by 461 the server. 463 Example: 465 C: a GETMETADATA /% value 466 S: * METADATA /comment (value.priv "My comment") 467 (value.shared "Your comment") 468 /motd (value.priv "Its sunny outside!" 469 (value.shared "Today is a Holiday") 470 S: a OK GETMETADATA complete 472 In the above example, the contents of the "value" attributes for 473 server entries at the top level of the entry hierarchy only, are 474 requested by the client and returned by the server. Both the 475 .priv and .shared values are returned, as neither were explicitly 476 requested. 478 Entry and attribute specifiers can be lists of atomic specifiers, so 479 that multiple items of each type may be returned in a single 480 GETMETADATA command. 482 Example: 484 C: a GETMETADATA (/comment /motd) value.priv 485 S: * METADATA /comment (value.priv "My comment") 486 /motd (value.priv "Its sunny outside!") 487 S: a OK GETMETADATA complete 489 In the above example, the contents of the "value.priv" attributes 490 for the two server entries "/comment" and "/motd" are requested by 491 the client and returned by the server. 493 Example: 495 C: a GETMETADATA /comment (value.priv 496 size.priv) 497 S: * METADATA /comment (value.priv "My comment" 498 size.priv "10") 499 S: a OK GETMETADATA complete 501 In the above example, the contents of the "value.priv" and 502 "size.priv" attributes for the "/comment" server entry are 503 requested by the client and returned by the server. 505 4.3. Extended LIST Command Extensions 507 This extension adds the METADATA LIST command selection and return 508 option types, extending the LIST-EXTENDED extension. This allows 509 clients to retrieve mailbox annotations. 511 The LIST-EXTENDED "METADATA" selection option type is used to request 512 that the extended LIST command match mailboxes which have an 513 annotation with a specific entry and value. It can also be used to 514 test for the existence of a particular annotation entry on a mailbox. 515 This selection option takes one or more entry/attribute/value triples 516 to use as tests. A mailbox matches this criteria if it has an entry, 517 attribute and value matching the ones specified. In the case of 518 multiple criteria being specified, mailbox MUST only match when all 519 criteria match ("and" operation). To test for the existence of an 520 entry, a test for the attribute "value" with the empty string "" as 521 the value argument can be used. To test for the absence of an entry, 522 a test for the attribute "value" with NIL as the value argument can 523 be used. Clients SHOULD only use entries defined with a "text" 524 Content-Type in the selection option arguments. 526 Each entry/attribute/value triple specified in the selection option 527 MAY include a match type specifier and MAY include a collation 528 [I-D.ietf-imapext-i18n] identifier. If the match type is specified, 529 then that match operation MUST be used when matching the provided 530 value with the corresponding annotation entry values in mailboxes. 531 If the match type is not specified, then a default of "CONTAINS" 532 (substring match) MUST be used. If the collation identifier is 533 specified, then that collation MUST be used to do the comparison of 534 the annotation entry values being tested. If the collation 535 identifier is not specified, then the active collation as defined by 536 [I-D.ietf-imapext-i18n] is used. If the client specifies a collation 537 identifier not known to the server, the server MUST return a BAD 538 response. Possible values for the match type are: 540 +----------+-----------------------------------------------+ 541 | Match | Description | 542 +----------+-----------------------------------------------+ 543 | IS | Equality test is done | 544 | CONTAINS | Substring match is done | 545 | GT | Greater than relational test is done | 546 | GE | Greater than or equal relational test is done | 547 | LE | Less than or equal relational test is done | 548 | LT | Less than relational test is done | 549 +----------+-----------------------------------------------+ 551 The "NOT" match type modifier results in a negation of the comparison 552 - i.e. it adds the ability to search for annotations that do not 553 match or contain specific text. 555 The LIST-EXTENDED "METADATA" return option type is used to request 556 that the extended LIST command return specific annotation entries for 557 each mailbox returned in the LIST responses. A list of entries and 558 attributes to return can be specified in a manner similar to the 559 GETMETADATA command. 561 Example: 563 C: a LIST "" "INBOX" RETURN (METADATA (/comment value.priv)) 564 S: * LIST "/" "INBOX" 565 (METADATA (/comment (value.priv "My comment"))) 566 S: a OK LIST complete 568 In the above example, the contents of the "value.priv" attribute 569 for the "/comment" entry for the mailbox INBOX is requested by the 570 client and returned by the server. 572 "*" and "%" wildcard characters can be used in the entry specifier to 573 match one or more characters at that position, with the exception 574 that "%" does not match the "/" hierarchy delimiter. Thus an entry 575 specifier of "/%" would match entries such as "/comment" and 576 "/check", but not "/comment/note". 578 Example: 580 C: a LIST "" "INBOX" RETURN (METADATA (/* value.priv)) 581 S: * LIST "/" "INBOX" 582 (METADATA (/comment (value.priv "My comment") 583 /check (value.priv "true"))) 584 S: a OK LIST complete 586 In the above example, the contents of the "value.priv" attributes 587 for any entries for the mailbox INBOX are requested by the client 588 and returned by the server. 590 Example: 592 C: a LIST "" "INBOX" RETURN (METADATA (/% value)) 593 S: * LIST "/" "INBOX" 594 (METADATA (/comment (value.priv "My comment") 595 (value.shared "Your comment") 596 /motd (value.priv "Its sunny outside!" 597 (value.shared "Today is a Holiday"))) 598 S: a OK LIST complete 600 In the above example, the contents of the "value" attributes for 601 entries for the mailbox INBOX at the top level of the entry 602 hierarchy only, are requested by the client and returned by the 603 server. Both the .priv and .shared values are returned, as 604 neither were explicitly requested. 606 Entry and attribute specifiers can be lists of atomic specifiers, so 607 that multiple items of each type may be returned in a single LIST 608 command. 610 Example: 612 C: a LIST "" "INBOX" RETURN (METADATA ((/comment /motd) 613 value.priv)) 614 S: * LIST "/" "INBOX" 615 (METADATA (/comment (value.priv "My comment") 616 /motd (value.priv "Its sunny outside!"))) 617 S: a OK LIST complete 619 In the above example, the contents of the "value.priv" attributes 620 for the two entries "/comment" and "/motd" for the mailbox INBOX 621 are requested by the client and returned by the server. 623 Example: 625 C: a LIST "" "INBOX" RETURN (METADATA (/comment 626 (value.priv size.priv))) 627 S: * LIST "/" "INBOX" 628 (METADATA (/comment (value.priv "My comment" 629 size.priv "10"))) 630 S: a OK LIST complete 632 In the above example, the contents of the "value.priv" and 633 "size.priv" attributes for the "/comment" entry for the mailbox 634 INBOX are requested by the client and returned by the server. 636 Example: 638 C: a LIST "" ("INBOX" "FOOBOX" "BARBOX") RETURN 639 (METADATA (/comment value.priv)) 640 S: * LIST "/" "INBOX" 641 (METADATA (/comment (value.priv "My comment"))) 642 S: * LIST "/" "FOOBOX" 643 (METADATA (/comment (value.priv "Another comment"))) 644 S: * LIST "/" "BARBOX" 645 (METADATA (/comment (value.priv NIL))) 646 S: a OK LIST complete 648 In the above example, the contents of the "value.priv" attribute 649 for the "/comment" entry for the mailboxes INBOX, FOOBOX and 650 BARBOX are requested by the client and returned by the server. 651 Note that the mailbox BARBOX does not contain the entry, hence NIL 652 is returned for the attribute value. 654 Example: 656 C: a LIST (METADATA ("/comment" "value" "comm" 657 (NOT CONTAINS))) "" "*" 658 S: * LIST () "/" "INBOX" 659 S: * LIST (\NoInferiors) "/" "FOOBOX" 660 S: a OK LIST complete 662 In the above example, the client requests that any mailbox in the 663 entire hierarchy that does not contain the text "comm" in any 664 "value" attribute of the "/comment" entry be returned. Two 665 mailboxes are returned in separate responses. Note that the 666 client did not ask for annotations to be returned in the 667 responses. 669 Example: 671 C: a LIST (METADATA ("/comment" "value" "")) 672 "" "*" 673 S: * LIST () "/" "INBOX" 674 S: * LIST (\NoInferiors) "/" "FOOBOX" 675 S: a OK LIST complete 677 In the above example, the client requests that any mailbox in the 678 entire hierarchy containing the "/comment" entry be returned. Two 679 mailboxes are returned in separate responses. Note that the 680 client did not ask for annotations to be returned in the 681 responses. 683 Example: 685 C: a LIST (METADATA ("/comment" "value" NIL)) 686 "" "*" 687 S: * LIST (\NoInferiors) "/" "BARBOX" 688 S: a OK LIST complete 690 In the above example, the client requests that any mailbox in the 691 entire hierarchy that does not have a "/comment" entry be 692 returned. One mailbox is returned in a response. Note that the 693 client did not ask for annotations to be returned in the 694 responses. 696 Example: 698 C: a LIST (METADATA ("/comment" "value" "HELP" 699 (IS "i;octet")) "" "*" 700 RETURN (METADATA (/comment size.priv)) 701 S: * LIST "/" "INBOX" 702 (METADATA (/comment (size.priv "10"))) 703 S: * LIST "/" "FOOBOX" 704 (METADATA (/comment (size.priv "15"))) 705 S: a OK LIST complete 707 In the above example, the client requests that any mailbox in the 708 entire hierarchy with the exact text "HELP" in any "value" 709 attribute of the "/comment" entry be returned. The client 710 provides an explicit match type and collation identifier. Two 711 mailboxes are returned in separate responses. The client also 712 asked for annotation sizes to be returned in the responses. 714 4.3.1. Unsolicited LIST response 716 Subject to unsolicited responses being activated by the ENABLE 717 [I-D.gulbrandsen-imap-enable] command for this extension, servers 718 SHOULD send unsolicited LIST responses if mailbox annotations are 719 changed by a third-party, allowing servers to keep clients updated 720 with changes. Unless explicitly changed by an IMAP extension, 721 unsolicited mailbox annotations MUST only be returned for the 722 currently selected mailbox. 724 Unsolicited LIST responses MUST only contain entry names, not the 725 attributes and values. If the client wants to update any cached 726 values it must explicitly retrieve those using a LIST command. 728 The LIST response can contain multiple entries in a single response, 729 but the server is free to return multiple responses for each entry or 730 group of entries if it desires. 732 Example: 734 C: a NOOP 735 S: * LIST "/" "INBOX" (METADATA (/comment)) 736 S: a OK NOOP complete 738 In the above example, the server sends an unsolicited LIST 739 response indicating that the "/comment" entry of the mailbox 740 "INBOX" has been changed. 742 4.4. SETMETADATA Command 744 This extension adds the SETMETADATA command. This allows clients to 745 set annotations. 747 This command is only available in authenticated or selected state 748 [RFC3501]. 750 Arguments: mailbox-name 751 entry 752 attribute-value 753 list of entry, attribute-values 755 Responses: no specific responses for this command 757 Result: OK - command completed 758 NO - command failure: can't set annotations, 759 or annotation too big or too many 760 BAD - command unknown or arguments invalid 762 This command sets the specified list of entries by adding or 763 replacing the specified attributes with the values provided, on the 764 specified existing mailboxes or on the server (if the mailbox 765 argument is the empty string). Clients can use NIL for values of 766 attributes it wants to remove from entries. The server SHOULD NOT 767 return a METADATA or LIST response containing the updated annotation 768 data. Clients MUST NOT assume that a METADATA or LIST response will 769 be sent, and MUST assume that if the command succeeds then the 770 annotation has been changed. 772 If the server is unable to set an annotation because the size of its 773 value is too large, the server MUST return a tagged NO response with 774 a "[METADATA TOOBIG]" response code. 776 If the server is unable to set a new annotation because the maximum 777 number of allowed annotations has already been reached, the server 778 MUST return a tagged NO response with a "[METADATA TOOMANY]" response 779 code. 781 If the server is unable to set a new annotation because it does not 782 support private annotations on one of the specified mailboxes, the 783 server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" 784 response code. 786 Example: 788 C: a SETMETADATA INBOX /comment 789 (value.priv "My new comment") 790 S: a OK SETMETADATA complete 792 In the above example, the entry "/comment" for the mailbox "INBOX" 793 is created (if not already present) and the private attribute 794 "value" with data set to "My new comment" is created if not 795 already present, or replaced if it previously exists. 797 Example: 799 C: a SETMETADATA INBOX /comment (value.priv NIL) 800 S: a OK SETMETADATA complete 802 In the above example, the private "value" attribute of the entry 803 "/comment" is removed from the mailbox "INBOX". 805 Annotations on multiple mailboxes can be set in a single SETMETADATA 806 command by using a wildcard specification for the mailbox name. 808 Example: 810 C: a SETMETADATA INBOX.% /comment 811 (value.priv "My new comment") 812 S: a OK SETMETADATA complete 814 In the above example, the entry "/comment" for all mailboxes at 815 the top-level of the "INBOX" hierarchy are created (if not already 816 present) and the private attribute "value" are created 817 respectively for each entry if not already present, or replaced if 818 they previously existed. 820 Multiple entries can be set in a single SETMETADATA command by 821 listing entry-attribute-value pairs in the list. 823 Example: 825 C: a SETMETADATA INBOX (/comment 826 (value.priv "My new comment") 827 /thread 828 (value.priv "REFERENCES ALL")) 829 S: a OK SETMETADATA complete 831 In the above example, the entries "/comment" and "/thread" for the 832 mailbox "INBOX" are created (if not already present) and the 833 "value.priv" attributes are created respectively for each entry if 834 not already present, or replaced if they previously existed. 836 Multiple attributes can be set in a single SETMETADATA command by 837 listing multiple attribute-value pairs in the entry list. 839 Example: 841 C: a SETMETADATA INBOX /comment 842 (value.priv "My new comment" 843 value.shared "foo's bar") 844 S: a OK SETMETADATA complete 846 In the above example, the entry "/comment" for the mailbox "INBOX" 847 is created (if not already present) and the attributes 848 "value.priv" and "value.shared" are created if not already 849 present, or replaced if they previously existed. 851 Example: 853 C: a SETMETADATA INBOX /comment 854 (value.priv "My new comment") 855 S: a NO [METADATA TOOMANY] SETMETADATA failed 857 In the above example, the server is unable to set the requested 858 (new) annotation as it has reached the limit on the number of 859 annotations it can support on the specified mailbox. 861 4.5. METADATA Response 863 The METADATA response displays results of a GETMETADATA command, or 864 can be returned as an unsolicited response at anytime by the server 865 in response to a change in a server annotation. 867 Subject to unsolicited responses being activated by the ENABLE 868 [I-D.gulbrandsen-imap-enable] command for this extension, servers 869 SHOULD send unsolicited METADATA responses if server annotations are 870 changed by a third-party, allowing servers to keep clients updated 871 with changes. 873 Unsolicited METADATA responses MUST only contain entry names, not the 874 attributes and values. If the client wants to update any cached 875 values it must explicitly retrieve those using a GETMETADATA command. 877 The METADATA response can contain multiple entries in a single 878 response, but the server is free to return multiple responses for 879 each entry or group of entries if it desires. 881 This response is only available in authenticated or selected state 882 [RFC3501]. 884 4.5.1. METADATA response with attributes and values 886 The response consists of a list of entries each of which has a list 887 of attribute-value pairs. 889 Example: 891 C: a GETMETADATA /comment value.priv 892 S: * METADATA /comment (value.priv "My comment") 893 S: a OK GETMETADATA complete 895 In the above example, a single entry with a single attribute-value 896 pair is returned by the server. 898 Example: 900 C: a GETMETADATA (/comment /motd) value.priv 901 S: * METADATA /comment (value.priv "My comment") 902 /motd (value.priv "Its sunny outside!") 903 S: a OK GETMETADATA complete 905 In the above example, two entries each with a single attribute- 906 value pair is returned by the server. 908 Example: 910 C: a GETMETADATA (/comment /motd) value.priv 911 S: * METADATA /comment (value.priv "My comment") 912 S: * METADATA /motd (value.priv "Its sunny outside!") 913 S: a OK GETMETADATA complete 915 In the above example, the server returns two separate responses 916 for each of the two entries requested. 918 Example: 920 C: a GETMETADATA /comment (value.priv size.priv) 921 S: * METADATA /comment (value.priv "My comment" 922 size.priv "10") 923 S: a OK GETMETADATA complete 925 In the above example, a single entry with two attribute-value 926 pairs is returned by the server. 928 4.5.2. Unsolicited METADATA response without attributes and values 930 The response consists of a parenthesized list of entries, each of 931 which have changed on the server. 933 Example: 935 C: a NOOP 936 S: * METADATA (/comment) 937 S: a OK NOOP complete 939 In the above example, the server indicates that the "/comment" 940 server entry has been changed. 942 Example: 944 C: a NOOP 945 S: * METADATA (/comment /motd) 946 S: a OK NOOP complete 948 In the above example, the server indicates a change to two server 949 entries. 951 5. Formal Syntax 953 The following syntax specification uses the Augmented Backus-Naur 954 Form (ABNF) notation as specified in [RFC4234]. 956 Non-terminals referenced but not defined below are as defined by 957 [RFC3501] with the new definitions in [RFC4466] superseding those in 958 [RFC3501]. 960 Except as noted otherwise, all alphabetic characters are case- 961 insensitive. The use of upper or lower case characters to define 962 token strings is for editorial clarity only. Implementations MUST 963 accept these strings in a case-insensitive fashion. 965 annotate-data = "METADATA" SP entry-list 967 att-select = "value" / "value.priv" / "value.shared" 968 ; the only attributes that can be selected 970 att-value = attrib SP value 972 attrib = astring 973 ; dot-separated attribute name 974 ; MUST NOT contain "*" or "%" 976 attribs = attrib / "(" attrib *(SP attrib) ")" 977 ; one or more attribute specifiers 979 capability =/ "METADATA" / "METADATA-SERVER" 980 ; defines the capabilities for this extension 982 command-auth =/ setmetadata / getmetadata 983 ; adds to original IMAP command 985 collation = astring 986 ; collation identifier as defined by 987 ; [RFC4790] 989 entries = entry-match / 990 "(" entry-match *(SP entry-match) ")" 991 ; entry specifiers that can include wildcards 993 entry = astring 994 ; slash-separated path to entry 995 ; MUST NOT contain "*" or "%" 997 entry-att = entry SP "(" att-value *(SP att-value) ")" 999 entry-list = entry-att *(SP entry-att) / 1000 "(" entry *(SP entry) ")" 1001 ; entry attribute-value pairs list for 1002 ; GETMETADATA response, or 1003 ; parenthesised entry list for unsolicited 1004 ; notification of annotation changes 1006 entry-match = list-mailbox 1007 ; slash-separated path to entry 1008 ; MAY contain "*" or "%" for use as wildcards 1010 getmetadata = "GETMETADATA" SP entries SP attribs 1012 list-select-base-opt =/ "METADATA" SP 1013 "(" list-select-metadata 1014 *(SP list-select-metadata) ")" 1015 ; adds a new selection option type to 1016 ; LIST-EXTENDED. When evaluating multiple entry, 1017 ; attribute, value combinations, a match to 1018 ; a mailbox must occur when all items match. 1020 list-select-metadata = entry-match SP att-select SP value 1021 [SP "(" matchtype [SP collation] ")"] 1022 ; value set to the empty string means match 1023 ; if that entry and attribute exist. 1024 ; value set to NIL means match if that entry 1025 ; and attribute do not exist. 1026 ; An optional match type and collation can also 1027 ; be specified. 1029 matchtype = ["NOT" SP] ("IS" / "CONTAINS" / 1030 "GT" / "GE" / "LE" / "LT") 1031 ; match types for LIST-EXTENDED string 1032 ; comparisons - see Section 4.3. 1034 response-payload =/ annotate-data 1035 ; adds to original IMAP data responses 1037 resp-text-code =/ "METADATA" SP ("TOOBIG" / "TOOMANY" / 1038 "NOPRIVATE") 1039 ; new response codes for SETMETADATA 1040 ; failures 1042 setmetadata = "SETMETADATA" SP list-mailbox 1043 SP setentryatt 1044 ; empty string for list-mailbox implies 1045 ; server annotation. 1047 setentryatt = entry-att / "(" entry-att *(SP entry-att) ")" 1049 value = nstring / literal8 1051 6. IANA Considerations 1053 Entry names MUST be specified in a standards track or IESG approved 1054 experimental RFC, or fall under the vendor namespace. 1056 Each entry registration MUST include a content-type that is used to 1057 indicate the nature of the annotation value. Where applicable a 1058 charset parameter MUST be included with the content-type. 1060 6.1. Entry and Attribute Registration Template 1062 To: iana@iana.org 1063 Subject: IMAP METADATA Entry Registration 1065 Type: [Either "Mailbox" or "Server"] 1067 Name: [the name of the entry] 1069 Description: [a description of what the entry is for] 1071 Content-type: [MIME Content-Type and charset for the entry value] 1073 RFC Number: [for entries published as RFCs] 1075 Contact: [email and/or physical address to contact for 1076 additional information] 1078 6.2. Server Entry Registrations 1080 The following templates specify the IANA registrations of annotation 1081 entries specified in this document. 1083 6.2.1. /comment 1085 To: iana@iana.org 1086 Subject: IMAP METADATA Entry Registration 1088 Type: Server 1090 Name: /comment 1092 Description: Defined in IMAP METADATA extension document. 1094 Content-type: text/plain; charset=utf-8 1096 RFC Number: This RFC. 1098 Contact: IMAP Extensions 1100 6.2.2. /motd 1102 To: iana@iana.org 1103 Subject: IMAP METADATA Entry Registration 1105 Type: Server 1107 Name: /motd 1109 Description: Defined in IMAP METADATA extension document. 1111 Content-type: text/plain; charset=utf-8 1113 RFC Number: This RFC. 1115 Contact: IMAP Extensions 1117 6.2.3. /admin 1119 To: iana@iana.org 1120 Subject: IMAP METADATA Entry Registration 1122 Type: Server 1124 Name: /admin 1126 Description: Defined in IMAP METADATA extension document. 1128 Content-type: text/plain; charset=utf-8 1130 RFC Number: This RFC. 1132 Contact: IMAP Extensions 1134 6.3. Mailbox Entry Registrations 1136 The following templates specify the IANA registrations of annotation 1137 entries specified in this document. 1139 6.3.1. /comment 1141 To: iana@iana.org 1142 Subject: IMAP METADATA Entry Registration 1144 Type: Mailbox 1146 Name: /comment 1148 Description: Defined in IMAP METADATA extension document. 1150 Content-type: text/plain; charset=utf-8 1152 RFC Number: This RFC. 1154 Contact: IMAP Extensions 1156 6.3.2. /sort 1158 To: iana@iana.org 1159 Subject: IMAP METADATA Entry Registration 1161 Type: Mailbox 1163 Name: /sort 1165 Description: Defined in IMAP METADATA extension document. 1167 Content-type: text/plain; charset=utf-8 1169 RFC Number: This RFC. 1171 Contact: IMAP Extensions 1173 6.3.3. /thread 1175 To: iana@iana.org 1176 Subject: IMAP METADATA Entry Registration 1178 Type: Mailbox 1180 Name: /thread 1182 Description: Defined in IMAP METADATA extension document. 1184 Content-type: text/plain; charset=utf-8 1186 RFC Number: This RFC. 1188 Contact: IMAP Extensions 1190 6.3.4. /check 1192 To: iana@iana.org 1193 Subject: IMAP METADATA Entry Registration 1195 Type: Mailbox 1197 Name: /check 1199 Description: Defined in IMAP METADATA extension document. 1201 Content-type: text/plain; charset=utf-8 1203 RFC Number: This RFC. 1205 Contact: IMAP Extensions 1207 6.3.5. /checkperiod 1209 To: iana@iana.org 1210 Subject: IMAP METADATA Entry Registration 1212 Please register the following IMAP METADATA entry: 1214 Type: Mailbox 1216 Name: /checkperiod 1218 Description: Defined in IMAP METADATA extension document. 1220 Content-type: text/plain; charset=utf-8 1222 RFC Number: This RFC. 1224 Contact: IMAP Extensions 1226 6.4. LIST-EXTENDED Registration 1228 To: iana@iana.org 1229 Subject: Registration of LIST-EXTENDED option METADATA 1231 LIST-EXTENDED option name: METADATA 1233 LIST-EXTENDED option type: SELECTION 1235 Implied return options(s): (none) 1237 LIST-EXTENDED option description: 1239 The "METADATA" selection option type is used to request 1240 that the extended LIST command match mailboxes which have 1241 an annotation with a specific entry and value. It can 1242 also be used to test for the existence of a particular 1243 annotation entry on a mailbox. 1245 Published specification : XXXX, Section 4.3. 1247 Security considerations: XXXX, Section 7. 1249 Intended usage: COMMON 1251 Person and email address to contact for further information: 1252 IMAP Extensions 1254 Owner/Change controller: iesg@ietf.org 1256 To: iana@iana.org 1257 Subject: Registration of LIST-EXTENDED option METADATA 1259 LIST-EXTENDED option name: METADATA 1261 LIST-EXTENDED option type: RETURN 1263 LIST-EXTENDED option description: Causes the LIST command to 1264 return the specified mailbox annotations. 1266 Published specification : XXXX, Section 4.3. 1268 Security considerations: XXXX, Section 7. 1270 Intended usage: COMMON 1272 Person and email address to contact for further information: 1273 IMAP Extensions 1275 Owner/Change controller: iesg@ietf.org 1277 7. Security Considerations 1279 Annotations whose values are intended to remain private MUST use 1280 .priv values, and not .shared values which may be accessible to other 1281 users. 1283 Annotations can contain arbitrary sized data. As such servers MUST 1284 ensure that size limits are enforced to prevent a user from using up 1285 all available space on a server and preventing use by others. 1287 Excluding the above issues the METADATA extension does not raise any 1288 security considerations that are not present in the base IMAP 1289 protocol, and these issues are discussed in [RFC3501]. 1291 8. References 1293 8.1. Normative References 1295 [I-D.gulbrandsen-imap-enable] 1296 Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 1297 Extension", draft-gulbrandsen-imap-enable-05 (work in 1298 progress), December 2007. 1300 [I-D.ietf-imapext-i18n] 1301 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 1302 Message Access Protocol Internationalization", 1303 draft-ietf-imapext-i18n-14 (work in progress), 1304 December 2007. 1306 [I-D.ietf-imapext-list-extensions] 1307 Leiba, B. and A. Melnikov, "IMAP4 LIST Command 1308 Extensions", draft-ietf-imapext-list-extensions-18 (work 1309 in progress), September 2006. 1311 [I-D.ietf-imapext-sort] 1312 Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 1313 PROTOCOL - SORT AND THREAD EXTENSIONS", 1314 draft-ietf-imapext-sort-19 (work in progress), 1315 September 2007. 1317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1318 Requirement Levels", BCP 14, RFC 2119, March 1997. 1320 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1321 Configuration Access Protocol", RFC 2244, November 1997. 1323 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1324 4rev1", RFC 3501, March 2003. 1326 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1327 10646", STD 63, RFC 3629, November 2003. 1329 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1330 Specifications: ABNF", RFC 4234, October 2005. 1332 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1333 ABNF", RFC 4466, April 2006. 1335 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 1336 Application Protocol Collation Registry", RFC 4790, 1337 March 2007. 1339 [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation 1340 Algorithm", RFC 5051, October 2007. 1342 8.2. Informative References 1344 [I-D.ietf-imapext-annotate] 1345 Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension", 1346 draft-ietf-imapext-annotate-16 (work in progress), 1347 October 2006. 1349 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 1351 Appendix A. Acknowledgments 1353 The ideas expressed in this document are based on the message 1354 annotation document that was co-authored by Randall Gellens. The 1355 participants of the IMAPext working group made significant 1356 contributions to this work. 1358 Appendix B. Change History (to be removed prior to publication as an 1359 RFC) 1361 Changes from -11 to -12: 1362 1. Allow server annotations to be used without mailbox annotations. 1363 2. Require i;unicode-casemap when COMPARATOR is not present. 1364 3. Use ENABLE to turn on unsolicited responses. 1365 4. Use formal syntax elements from SORT/THREAD extensions to define 1366 the values for /sort and /thread entries. 1367 5. Added a comment that use of IDLE is preferred even when /check 1368 is true. 1369 6. Use formal syntax element from base spec for the /size value. 1370 7. Removed IANA registration for attributes as we don't expect any 1371 more to be defined. 1372 8. Tweaked IANA registration template to be more compact and add 1373 RFC Number reference. 1374 9. Some minor re-phrasing was done. 1375 10. Added text about handling of annotations on INBOX when it is 1376 renamed. 1378 11. Require a BAD response when an unknown collation is used in 1379 LISTEXT selection option. 1381 Changes from -10 to -11: 1382 1. Added new paragraph to indicate that values may be read-only or 1383 computed. 1384 2. /admin server annotation value now must be a URI. 1385 3. Clarified that SORT and THREAD extensions are not required. 1386 4. Fixed use of undefined entries in some examples. 1387 5. Fixed many examples. 1388 6. Added IANA registration for LIST-EXTENDED items. 1389 7. Added match type and collation identifier to the LIST-EXTENDED 1390 selection option. 1391 8. Made support for IMAP-I18N a requirement. 1392 9. Minor text clarifications applied. 1393 10. Remove mailbox list set atomicity requirement. 1394 11. Clarified that annotations can only be set on mailboxes that 1395 actually exist. 1397 Changes from -09 to -10: 1398 1. Updated to rfc 4466 reference. 1399 2. Reworded data model description. 1400 3. Reworked LIST-EXTENDED so that responses have metadata items 1401 after the mailbox info. 1402 4. Various spelling fixes. 1404 Changes from -08 to -09: 1405 1. Remove content-language attribute and reference. 1406 2. Changed capability and command names. 1407 3. Revised abstract. 1409 Changes from -07 to -08: 1410 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 1411 for entry/attribute names. 1412 2. Updated examples to match new astring syntax. 1413 3. Changed CAPABILITY name due to incompatible syntax change. 1414 4. Removed content-type attribute. 1415 5. Added Content-type to IANA registration for entries. 1416 6. Removed vendor attributes. 1417 7. Fixed examples in section 3.3 for multi-mailbox and multi-entry 1418 cases. 1419 8. Removed wildcards for attributes. 1420 9. Entry/attributes can now only be ASCII. 1421 10. Tied up text wrt storing/fetching. 1422 11. Added Conventions section 1423 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 1424 '.'. 1426 13. Changed to use IMAP ABNF extensions document for some formal 1427 syntax items. 1429 Changes from -06 to -07: 1430 1. Reworded /checkperiod item. 1431 2. Clarified unsolicited response behavior. 1433 Changes from -05 to -06: 1434 1. Removed 'modifiedsince' attribute as there is currently no use 1435 for it. 1436 2. Added content-language attribute. 1437 3. Changed access to allow .priv and .shared on any mailbox returned 1438 by LIST/LSUB. 1439 4. Added IANA registrations for items defined in this document. 1440 5. Added latest IPR statement. 1441 6. Updated references. 1443 Changes from -04 to -05: 1444 1. Fix for valid IMAP state of commands. 1445 2. Fix formatting, ID nits etc. 1447 Changes from -03 to -04: 1448 1. Allow retrieval of shared annotations for READ-ONLY mailbox. 1449 2. Clarification of annotation loss on implicit removal of \Noselect 1450 mailboxes. 1451 3. Now requires roll-back of all changes to matching mailboxes if 1452 there is a partial failure in SETANNOTATION. 1454 Changes from -02 to -03: 1455 1. Reworked entry naming scheme to split out mailbox name and use 1456 empty string for server items. 1458 Changes from -01 to -02: 1459 1. SETANNOTATION lists use (..). 1460 2. Explicitly state behavior of unsolicited responses. 1461 3. Adding SHOULD behavior for rename/delete of mailboxes. 1462 4. Added statement about supporting annotations on \Noselect 1463 mailboxes. 1464 5. Cleaned up formal syntax to use IMAP string type for entry and 1465 attributes, with requirements on how the string is formatted. 1466 6. Use of ACAP vendor subtree registry for vendor tokens. 1468 Changes from -00 to -01: 1469 1. Multiple entry-att responses are now simply delimited by spaces 1470 in line with ANNOTATE spec. Adjusted examples to match. 1471 2. Fixed entry-list formal syntax item to account for unsolicited 1472 parenthesized list of entries. 1474 3. Removed setentries formal syntax item for simplicity since its 1475 only used once. 1476 4. Removed reference to 'message annotation' in section 5.1. 1477 5. Changed formal syntax to restrict top level entries to /server 1478 and /mailbox/{...} only. Re-arranged entry names section to 1479 account for this change. 1480 6. Added comment and example for ANNOTATION response to allow 1481 servers to return separate responses for each entry if desired. 1483 Author's Address 1485 Cyrus Daboo 1486 Apple Inc. 1487 1 Infinite Loop 1488 Cupertino, CA 95014 1489 USA 1491 Email: cyrus@daboo.name 1492 URI: http://www.apple.com/ 1494 Full Copyright Statement 1496 Copyright (C) The IETF Trust (2007). 1498 This document is subject to the rights, licenses and restrictions 1499 contained in BCP 78, and except as set forth therein, the authors 1500 retain all their rights. 1502 This document and the information contained herein are provided on an 1503 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1504 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1505 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1506 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1507 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1508 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1510 Intellectual Property 1512 The IETF takes no position regarding the validity or scope of any 1513 Intellectual Property Rights or other rights that might be claimed to 1514 pertain to the implementation or use of the technology described in 1515 this document or the extent to which any license under such rights 1516 might or might not be available; nor does it represent that it has 1517 made any independent effort to identify any such rights. Information 1518 on the procedures with respect to rights in RFC documents can be 1519 found in BCP 78 and BCP 79. 1521 Copies of IPR disclosures made to the IETF Secretariat and any 1522 assurances of licenses to be made available, or the result of an 1523 attempt made to obtain a general license or permission for the use of 1524 such proprietary rights by implementers or users of this 1525 specification can be obtained from the IETF on-line IPR repository at 1526 http://www.ietf.org/ipr. 1528 The IETF invites any interested party to bring to its attention any 1529 copyrights, patents or patent applications, or other proprietary 1530 rights that may cover technology that may be required to implement 1531 this standard. Please address the information to the IETF at 1532 ietf-ipr@ietf.org. 1534 Acknowledgment 1536 Funding for the RFC Editor function is provided by the IETF 1537 Administrative Support Activity (IASA).