idnits 2.17.1 draft-daboo-imap-annotatemore-14.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 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 963. 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 (July 13, 2008) is 5759 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'METADATA TOOMANY' is mentioned on line 450, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 July 13, 2008 5 Expires: January 14, 2009 7 IMAP METADATA Extension 8 draft-daboo-imap-annotatemore-14 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 January 14, 2009. 35 Abstract 37 The METADATA extension to the Internet Message Access Protocol 38 permits clients and servers to maintain "annotations" or "meta data" 39 on IMAP servers. It is possible to have annotations on a per-mailbox 40 basis or on the server as a whole. For example, this would allow 41 comments about the purpose of a particular mailbox to be "attached" 42 to that mailbox, or a "message of the day" containing server status 43 information to be made available to anyone logging in to the server. 45 Table of Contents 47 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 49 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.2. Namespace of entries . . . . . . . . . . . . . . . . . . . 4 52 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5 53 3.3. Private versus Public and Access Control . . . . . . . . . 6 54 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6 55 4.1. General Considerations . . . . . . . . . . . . . . . . . . 7 56 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 8 57 4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 9 58 4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 11 59 4.4.1. METADATA response with values . . . . . . . . . . . . 11 60 4.4.2. Unsolicited METADATA response without values . . . . . 12 61 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 63 6.1. Entry and Attribute Registration Template . . . . . . . . 14 64 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 14 65 6.2.1. /public/comment . . . . . . . . . . . . . . . . . . . 15 66 6.2.2. /public/admin . . . . . . . . . . . . . . . . . . . . 15 67 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 15 68 6.3.1. /public/comment . . . . . . . . . . . . . . . . . . . 16 69 6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 16 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 8. Normative References . . . . . . . . . . . . . . . . . . . . . 17 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 73 Appendix B. Change History (to be removed prior to 74 publication as an RFC) . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 Intellectual Property and Copyright Statements . . . . . . . . . . 22 78 1. Introduction and Overview 80 The goal of the METADATA extension is to provide a means for clients 81 to set and retrieve "annotations" or "meta data" on an IMAP server. 82 The annotations can be associated with specific mailboxes or the 83 server as a whole. The server can choose to support only server 84 annotations or both server and mailbox annotations. 86 A server that supports both server and mailbox annotations indicates 87 the presence of this extension by returning "METADATA" as one of the 88 supported capabilities in the CAPABILITY command response. 90 A server that supports only server annotations indicates the presence 91 of this extension by returning "METADATA-SERVER" as one of the 92 supported capabilities in the CAPABILITY command response. 94 A server that supports unsolicited annotation change responses 95 indicates the presence of that feature by returning "METADATA- 96 UNSOLICITED" as one of the supported capabilities in the CAPABILITY 97 command response. The "ENABLE" [RFC5161] extension MUST also be 98 present if the "METADATA-UNSOLICITED" capability is advertised. 100 The METADATA extension adds two new commands and one new untagged 101 response to the IMAP base protocol. 103 This extension makes the following changes to the IMAP protocol: 105 o adds a new SETMETADATA command 106 o adds a new GETMETADATA command 107 o adds a new METADATA untagged response 108 o adds a new METADATA response code 110 Text comparisons may be done as part of the GETMETADATA command. If 111 the COMPARATOR [I-D.ietf-imapext-i18n] extension is present, then 112 comparisons are done using the comparator in effect at the time. If 113 the COMPARATOR extension is not present, then comparisons MUST use 114 the i;unicode-casemap comparator, as defined in [RFC5051]. 116 The rest of this document describes the data model and protocol 117 changes more rigorously. 119 2. Conventions Used in This Document 121 In examples, "C:" and "S:" indicate lines sent by the client and 122 server respectively. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 Whitespace and line breaks have been added to the examples in this 129 document to promote readability. 131 3. Data Model 133 3.1. Overview 135 Mailboxes or the server as a whole may have zero or more annotations 136 associated with them. An annotation contains a uniquely named entry 137 each of which has a value. Annotations can be added to mailboxes 138 when a mailbox name is provided as the first argument to the 139 SETMETADATA command, or to the server as a whole when the empty 140 string is provided as the first argument to the command. 142 For example, a general comment being added to a mailbox may have an 143 entry name of "/comment" and a value "Really useful mailbox". 145 The protocol changes to IMAP described below allow a client to access 146 or change the values of any annotation entry, assuming it has 147 sufficient access rights to do so. 149 3.2. Namespace of entries 151 Each annotation is an entry that has a hierarchical name, with each 152 component of the name separated by a slash ("/"). An entry name MUST 153 NOT contain two consecutive "/" characters and MUST NOT end with a 154 "/" character. 156 The value of an entry is NIL (has no value), or a string or binary 157 data of zero or more octets. A string MAY contain multiple lines of 158 text. Clients MUST use the CRLF (0x0D 0x0A) character octet sequence 159 to represent line ends in a multi-line string value. 161 Entry names MUST NOT contain asterisk ("*") or percent ("%") 162 characters and MUST NOT contain non-ASCII characters or the NUL 163 octet. Invalid entry names result in a BAD response in any IMAP 164 commands where they are used. 166 Entry names are case-insensitive. 168 Use of control or punctuation characters in entry names is strongly 169 discouraged. 171 This specification defines an initial set of entry available for use 172 with mailbox and server annotations. In addition an extension 173 mechanism is described to allow additional names to be added for 174 extensibility. 176 The first component in entry names defines the scope of the 177 annotation. Currently only the prefixes "/private" or "/public" are 178 defined. These prefixes are used to indicate whether an annotation 179 is stored on a per-user basis ("/private") and not visible to other 180 users, or whether an annotation is shared between authorized users 181 ("/public") with a single value that can be read and changed by 182 authorized users with appropriate access. See Section 3.3 for 183 details. 185 3.2.1. Entry Names 187 Entry names MUST be specified in a standards track or IESG approved 188 experimental RFC, or fall under the vendor namespace. See 189 Section 6.1 for the registration template. 191 3.2.1.1. Server Entries 193 These entries are set or retrieved when the mailbox name argument to 194 the new SETMETADATA or GETMETATDATA commands is the empty string. 196 /public/comment 197 Defines a comment or note associated with the server shared with 198 authorized users of the server. 200 /public/admin 201 Indicates a method for contacting the server administrator. The 202 value MUST be a URI (e.g., a mailto: or tel: URL). This entry is 203 always read-only - clients cannot change it. It is visible to 204 authorized users of the system. 206 /public/vendor/ 207 Defines the top-level of public entries associated with the server 208 as created by a particular product of some vendor. This entry can 209 be used by vendors to provide server or client specific 210 annotations. The vendor-token MUST be registered with IANA, using 211 the ACAP [RFC2244] vendor subtree registry. 213 /private/vendor/ 214 Defines the top-level of private entries associated with the 215 server as created by a particular product of some vendor. This 216 entry can be used by vendors to provide server or client specific 217 annotations. The vendor-token MUST be registered with IANA, using 218 the ACAP [RFC2244] vendor subtree registry. 220 3.2.1.2. Mailbox Entries 222 These entries are set or retrieved when the mailbox name argument to 223 the new SETMETADATA or GETMETADATA commands is not the empty string. 225 /public/comment 226 Defines a public comment or note associated with a mailbox. 228 /private/comment 229 Defines a private (per-user) comment or note associated with a 230 mailbox. 232 /public/vendor/ 233 Defines the top-level of public entries associated with a specific 234 mailbox as created by a particular product of some vendor. This 235 entry can be used by vendors to provide client specific 236 annotations. The vendor-token MUST be registered with IANA, using 237 the ACAP [RFC2244] vendor subtree registry. 239 /private/vendor/ 240 Defines the top-level of private entries associated with a 241 specific mailbox as created by a particular product of some 242 vendor. This entry can be used by vendors to provide client 243 specific annotations. The vendor-token MUST be registered with 244 IANA, using the ACAP [RFC2244] vendor subtree registry. 246 3.3. Private versus Public and Access Control 248 A user can only set and retrieve private or public annotations on a 249 mailbox which exists and is returned to them via a LIST or LSUB 250 command, irrespective of whether they have read or write access to 251 the actual message content of the mailbox. If the client attempts to 252 set or retrieve annotations on other mailboxes, the server MUST 253 respond with a NO response. 255 If the METADATA extension is present, support for public annotations 256 is REQUIRED, whilst support for private annotations is OPTIONAL. 257 This recognizes the fact that support for private annotations may 258 introduce significantly more complexity to a server in terms of 259 tracking ownership of the annotations, how quota is determined for 260 users based on their own annotations etc. 262 4. IMAP Protocol Changes 263 4.1. General Considerations 265 The new SETMETADATA command and the METADATA response each have a 266 mailbox name argument. An empty string is used for the mailbox name 267 to signify server annotations. A non-empty string is used to signify 268 mailbox annotations attached to the corresponding mailbox. 270 Servers SHOULD ensure that mailbox annotations are automatically 271 moved when the mailbox they refer to is renamed, i.e. the annotations 272 follow the mailbox. This applies to a rename of the INBOX, with the 273 additional behavior that the annotations are copied from the original 274 INBOX to the renamed mailbox. i.e. mailbox annotations are preserved 275 on the INBOX when it is renamed. 277 Servers SHOULD delete annotations for a mailbox when the mailbox is 278 deleted, so that a mailbox created with the same name as a previously 279 existing mailbox does not inherit the old mailbox annotations. 281 Servers SHOULD allow annotations on all 'types' of mailbox, including 282 ones reporting \Noselect for their LIST response. Servers can 283 implicitly remove \Noselect mailboxes when all child mailboxes are 284 removed, and as such any annotations associated with the \Noselect 285 mailbox SHOULD be removed. 287 The server is allowed to impose limitations on the size of any one 288 annotation or the total number of annotations for a single mailbox or 289 for the server as a whole. However, the server MUST accept a minimum 290 annotation data size of at least 1024 bytes, and a minimum annotation 291 count per server or mailbox of at least 10. 293 Some annotations may be "read-only" - i.e. they are set by the server 294 and cannot be changed by the client. Also, such annotations may be 295 "computed" - i.e. the value changes based on underlying properties of 296 the mailbox or server. For example, an annotation reporting the 297 total size of all messages in the mailbox would change as messages 298 are added or removed. Or, an annotation containing an IMAP URL for 299 the mailbox would change if the mailbox was renamed. 301 Servers MAY support sending unsolicited responses for use when 302 annotations are changed by some "third-party" (see Section 4.4). 303 Servers indicate their ability to do that by advertising the 304 "METADATA-UNSOLICITED" capability and supporting the ENABLE command. 305 Servers MUST only send unsolicited responses if the client used the 306 ENABLE command [RFC5161] extension with the capability string 307 "METADATA-UNSOLICITED" earlier in the session. 309 4.2. GETMETADATA Command 311 This extension adds the GETMETADATA command. This allows clients to 312 retrieve server or mailbox annotations. 314 This command is only available in authenticated or selected state 315 [RFC3501]. 317 Arguments: mailbox-name 318 entry-specifier 320 Responses: required METADATA response 322 Result: OK - command completed 323 NO - command failure: can't access annotations on 324 the server 325 BAD - command unknown or arguments invalid 327 When the mailbox name is the empty string, this command retrieves 328 server annotations. When the mailbox name is not empty, this command 329 retrieves annotations on the specified mailbox. 331 Example: 333 C: a GETMETADATA "" /public/comment 334 S: * METADATA "" (/public/comment "Shared comment") 335 S: a OK GETMETADATA complete 337 In the above example, the contents of the value of the "/public/ 338 comment" server entry is requested by the client and returned by 339 the server. 341 Example: 343 C: a GETMETADATA "INBOX" /private/comment 344 S: * METADATA "INBOX" (/private/comment "My own comment") 345 S: a OK GETMETADATA complete 347 In the above example, the contents of the value of the "/private/ 348 comment" mailbox entry for the mailbox "INBOX" is requested by the 349 client and returned by the server. 351 Entry specifiers can be lists of atomic specifiers, so that multiple 352 annotations may be returned in a single GETMETADATA command. 354 Example: 356 C: a GETMETADATA "INBOX" (/public/comment /private/comment) 357 S: * METADATA "INBOX" (/public/comment "Shared comment" 358 /private/comment "My own comment") 359 S: a OK GETMETADATA complete 361 In the above example, the values of the two server entries 362 "/public/comment" and "/private/comment" on the mailbox "inbox" 363 are requested by the client and returned by the server. 365 4.3. SETMETADATA Command 367 This extension adds the SETMETADATA command. This allows clients to 368 set annotations. 370 This command is only available in authenticated or selected state 371 [RFC3501]. 373 Arguments: mailbox-name 374 entry 375 value 376 list of entry, values 378 Responses: no specific responses for this command 380 Result: OK - command completed 381 NO - command failure: can't set annotations, 382 or annotation too big or too many 383 BAD - command unknown or arguments invalid 385 This command sets the specified list of entries by adding or 386 replacing the specified values provided, on the specified existing 387 mailboxes or on the server (if the mailbox argument is the empty 388 string). Clients can use NIL for the value of entries it wants to 389 remove. The server SHOULD NOT return a METADATA response containing 390 the updated annotation data. Clients MUST NOT assume that a METADATA 391 response will be sent, and MUST assume that if the command succeeds 392 then the annotation has been changed. 394 If the server is unable to set an annotation because the size of its 395 value is too large, the server MUST return a tagged NO response with 396 a "[METADATA MAXSIZE NNN]" response code when NNN is the maximum 397 octet count that it is willingly to accept. 399 If the server is unable to set a new annotation because the maximum 400 number of allowed annotations has already been reached, the server 401 MUST return a tagged NO response with a "[METADATA TOOMANY]" response 402 code. 404 If the server is unable to set a new annotation because it does not 405 support private annotations on one of the specified mailboxes, the 406 server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" 407 response code. 409 When any one annotation fails to be set, resulting in a tagged NO 410 response from the server, then the server MUST NOT change the values 411 for other annotations specified in the SETMETADATA command. 413 Example: 415 C: a SETMETADATA INBOX (/private/comment {33} 416 S: + ready for data 417 My new comment across 418 two lines. 419 ) 420 S: a OK SETMETADATA complete 422 In the above example, the entry "/private/comment" for the mailbox 423 "INBOX" is created (if not already present) and the value set to a 424 multi-line string. 426 Example: 428 C: a SETMETADATA INBOX (/private/comment NIL) 429 S: a OK SETMETADATA complete 431 In the above example, the entry "/private/comment" is removed from 432 the mailbox "INBOX". 434 Multiple entries can be set in a single SETMETADATA command by 435 listing entry-value pairs in the list. 437 Example: 439 C: a SETMETADATA INBOX (/private/comment "My new comment" 440 /public/comment "This one is for you!") 441 S: a OK SETMETADATA complete 443 In the above example, the entries "/private/comment" and "/public/ 444 comment" for the mailbox "INBOX" are created (if not already 445 present) and the values set as specified. 447 Example: 449 C: a SETMETADATA INBOX (/private/comment "My new comment") 450 S: a NO [METADATA TOOMANY] SETMETADATA failed 452 In the above example, the server is unable to set the requested 453 (new) annotation as it has reached the limit on the number of 454 annotations it can support on the specified mailbox. 456 4.4. METADATA Response 458 The METADATA response displays results of a GETMETADATA command, or 459 can be returned as an unsolicited response at anytime by the server 460 in response to a change in a server or mailbox annotation. 462 When unsolicited responses are activated by the ENABLE [RFC5161] 463 command for this extension, servers MUST send unsolicited METADATA 464 responses if server or mailbox annotations are changed by a third- 465 party, allowing servers to keep clients updated with changes. 467 Unsolicited METADATA responses MUST only contain entry names, not the 468 values. If the client wants to update any cached values it must 469 explicitly retrieve those using a GETMETADATA command. 471 The METADATA response can contain multiple entries in a single 472 response, but the server is free to return multiple responses for 473 each entry or group of entries if it desires. 475 This response is only available in authenticated or selected state 476 [RFC3501]. 478 4.4.1. METADATA response with values 480 The response consists of a list of entry-value pairs. 482 Example: 484 C: a GETMETADATA "" /public/comment 485 S: * METADATA "" (/public/comment "My comment") 486 S: a OK GETMETADATA complete 488 In the above example, a single entry with its value is returned by 489 the server. 491 Example: 493 C: a GETMETADATA "INBOX" /private/comment /public/comment 494 S: * METADATA "INBOX" (/private/comment "My comment" 495 /public/comment "Its sunny outside!") 496 S: a OK GETMETADATA complete 498 In the above example, two entries and their values are returned by 499 the server. 501 Example: 503 C: a GETMETADATA "INBOX" /private/comment /public/comment 504 S: * METADATA "INBOX" (/private/comment "My comment") 505 S: * METADATA "INBOX" (/public/comment "Its sunny outside!") 506 S: a OK GETMETADATA complete 508 In the above example, the server returns two separate responses 509 for each of the two entries requested. 511 4.4.2. Unsolicited METADATA response without values 513 The response consists of a list of entries, each of which have 514 changed on the server or mailbox. 516 Example: 518 C: a NOOP 519 S: * METADATA "" /public/comment 520 S: a OK NOOP complete 522 In the above example, the server indicates that the "/public/ 523 comment" server entry has been changed. 525 Example: 527 C: a NOOP 528 S: * METADATA "INBOX" /public/comment /private/comment 529 S: a OK NOOP complete 531 In the above example, the server indicates a change to two mailbox 532 entries. 534 5. Formal Syntax 536 The following syntax specification uses the Augmented Backus-Naur 537 Form (ABNF) notation as specified in [RFC5234]. 539 Non-terminals referenced but not defined below are as defined by 540 [RFC3501] with the new definitions in [RFC4466] superseding those in 541 [RFC3501]. 543 Except as noted otherwise, all alphabetic characters are case- 544 insensitive. The use of upper or lower case characters to define 545 token strings is for editorial clarity only. Implementations MUST 546 accept these strings in a case-insensitive fashion. 548 capability =/ "METADATA" / "METADATA-SERVER" / 549 "METADATA-UNSOLICITED" 550 ; defines the capabilities for this extension 552 command-auth =/ setmetadata / getmetadata 553 ; adds to original IMAP command 555 entries = entry / 556 "(" entry *(SP entry) ")" 557 ; entry specifiers 559 entry = astring 560 ; slash-separated path to entry 561 ; MUST NOT contain "*" or "%" 563 entry-value = entry SP value 565 entry-values = "(" entry-value *(SP entry-value) ")" 567 entry-list = entry *(SP entry) 568 ; list of entries used in unsolicited 569 ; METADATA response 571 getmetadata = "GETMETADATA" SP mailbox SP entries 572 ; empty string for mailbox implies 573 ; server annotation. 575 metadata-resp = "METADATA" SP mailbox SP 576 (entry-values / entry-list) 577 ; empty string for mailbox implies 578 ; server annotation. 580 response-payload =/ metadata-resp 581 ; adds to original IMAP data responses 583 resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number / 584 "TOOMANY" / "NOPRIVATE") 585 ; new response codes for SETMETADATA 586 ; failures 588 setmetadata = "SETMETADATA" SP mailbox 589 SP entry-values 590 ; empty string for mailbox implies 591 ; server annotation. 593 value = nstring / literal8 595 6. IANA Considerations 597 Entry names MUST be specified in a standards track or IESG approved 598 experimental RFC, or fall under the vendor namespace. All entries 599 MUST have either "/public" or "/private" as a prefix. 601 Each entry registration MUST include a content-type that is used to 602 indicate the nature of the annotation value. Where applicable a 603 charset parameter MUST be included with the content-type. 605 6.1. Entry and Attribute Registration Template 607 To: iana@iana.org 608 Subject: IMAP METADATA Entry Registration 610 Type: [Either "Mailbox" or "Server"] 612 Name: [the name of the entry] 614 Description: [a description of what the entry is for] 616 Content-type: [MIME Content-Type and charset for the entry value] 618 RFC Number: [for entries published as RFCs] 620 Contact: [email and/or physical address to contact for 621 additional information] 623 6.2. Server Entry Registrations 625 The following templates specify the IANA registrations of annotation 626 entries specified in this document. 628 6.2.1. /public/comment 630 To: iana@iana.org 631 Subject: IMAP METADATA Entry Registration 633 Type: Server 635 Name: /public/comment 637 Description: Defines a comment or note associated with the server 638 shared with authorized users of the server. 640 Content-type: text/plain; charset=utf-8 642 RFC Number: This RFC. 644 Contact: IMAP Extensions 646 6.2.2. /public/admin 648 To: iana@iana.org 649 Subject: IMAP METADATA Entry Registration 651 Type: Server 653 Name: /public/admin 655 Description: Indicates a method for contacting the server 656 administrator. The value MUST be a URI (e.g., a 657 mailto: or tel: URL). This entry is always 658 read-only - clients cannot change it. It is visible 659 to authorized users of the system. 661 Content-type: text/plain; charset=utf-8 663 RFC Number: This RFC. 665 Contact: IMAP Extensions 667 6.3. Mailbox Entry Registrations 669 The following templates specify the IANA registrations of annotation 670 entries specified in this document. 672 6.3.1. /public/comment 674 To: iana@iana.org 675 Subject: IMAP METADATA Entry Registration 677 Type: Mailbox 679 Name: /public/comment 681 Description: Defines a public comment or note associated with a 682 mailbox. 684 Content-type: text/plain; charset=utf-8 686 RFC Number: This RFC. 688 Contact: IMAP Extensions 690 6.3.2. /private/comment 692 To: iana@iana.org 693 Subject: IMAP METADATA Entry Registration 695 Type: Mailbox 697 Name: /private/comment 699 Description: Defines a private comment or note associated with a 700 mailbox. 702 Content-type: text/plain; charset=utf-8 704 RFC Number: This RFC. 706 Contact: IMAP Extensions 708 7. Security Considerations 710 Annotations can contain arbitrary data of varying size. As such 711 servers MUST ensure that size limits are enforced to prevent a user 712 from using up all available space on a server and preventing use by 713 others. Clients MUST treat annotation data values as an "untrusted" 714 source of data as it is possible for it to contain malicious content. 716 Annotations whose values are intended to remain private MUST be 717 stored only in entries that have the "/private" prefix on the entry 718 name. Servers MUST ensure that /private annotations are only visible 719 to the user that created them. 721 Excluding the above issues the METADATA extension does not raise any 722 security considerations that are not present in the base IMAP 723 protocol, and these issues are discussed in [RFC3501]. 725 8. Normative References 727 [I-D.ietf-imapext-i18n] 728 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 729 Message Access Protocol Internationalization", 730 draft-ietf-imapext-i18n-15 (work in progress), 731 February 2008. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 737 Configuration Access Protocol", RFC 2244, November 1997. 739 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 740 4rev1", RFC 3501, March 2003. 742 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 743 ABNF", RFC 4466, April 2006. 745 [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation 746 Algorithm", RFC 5051, October 2007. 748 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 749 Extension", RFC 5161, March 2008. 751 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 752 Specifications: ABNF", STD 68, RFC 5234, January 2008. 754 Appendix A. Acknowledgments 756 The ideas expressed in this document are based on the message 757 annotation document that was co-authored by Randall Gellens. The 758 participants of the IMAPext working group made significant 759 contributions to this work. 761 Appendix B. Change History (to be removed prior to publication as an 762 RFC) 764 Changes from -13 to -14: 765 1. Add statement that no annotations are set when any one fails in a 766 single SETMETADATA command. 767 2. Make unsolicited responses a MUST when ENABLE is used, but make 768 support for ENABLE METADATA optional so servers aren't required 769 to do unsolicited responses. This required a new capbility for 770 the unsolicited behavior. 771 3. Re-ordered Security considerations paragraphs and added 772 additional text about the possibility of malicious content in 773 data values. [SECDIR suggestion] 774 4. Reworded "all users" to "authorized users" in appropriate places. 775 [SECDIR suggestion] 776 5. Added addition text to Security considerations about the need for 777 servers to keep /private annotations private to the user that 778 created them. [SECDIR suggestion] 779 6. Added comment that string values can be multi-line and that CRLF 780 must be the line end indicator. Also changes one example to be 781 multi-line. [SECDIR suggestion] 783 Changes from -12 to -13: 784 1. Major changes to simplify things. 785 2. Removed dependency on LISTEXT - GETMETADATA now used to get 786 annotations on mailboxes. 787 3. Changed data model to remove attributes - annotations are now 788 only entry-value pairs. 789 4. Removed all wildcard behavior on entry names. 790 5. Cut down the registered annotations to only a few essential ones. 792 Changes from -11 to -12: 793 1. Allow server annotations to be used without mailbox annotations. 794 2. Require i;unicode-casemap when COMPARATOR is not present. 795 3. Use ENABLE to turn on unsolicited responses. 796 4. Use formal syntax elements from SORT/THREAD extensions to define 797 the values for /sort and /thread entries. 798 5. Added a comment that use of IDLE is preferred even when /check 799 is true. 800 6. Use formal syntax element from base spec for the /size value. 801 7. Removed IANA registration for attributes as we don't expect any 802 more to be defined. 803 8. Tweaked IANA registration template to be more compact and add 804 RFC Number reference. 805 9. Some minor re-phrasing was done. 806 10. Added text about handling of annotations on INBOX when it is 807 renamed. 808 11. Require a BAD response when an unknown collation is used in 809 LISTEXT selection option. 811 Changes from -10 to -11: 813 1. Added new paragraph to indicate that values may be read-only or 814 computed. 815 2. /admin server annotation value now must be a URI. 816 3. Clarified that SORT and THREAD extensions are not required. 817 4. Fixed use of undefined entries in some examples. 818 5. Fixed many examples. 819 6. Added IANA registration for LIST-EXTENDED items. 820 7. Added match type and collation identifier to the LIST-EXTENDED 821 selection option. 822 8. Made support for IMAP-I18N a requirement. 823 9. Minor text clarifications applied. 824 10. Remove mailbox list set atomicity requirement. 825 11. Clarified that annotations can only be set on mailboxes that 826 actually exist. 828 Changes from -09 to -10: 829 1. Updated to rfc 4466 reference. 830 2. Reworded data model description. 831 3. Reworked LIST-EXTENDED so that responses have metadata items 832 after the mailbox info. 833 4. Various spelling fixes. 835 Changes from -08 to -09: 836 1. Remove content-language attribute and reference. 837 2. Changed capability and command names. 838 3. Revised abstract. 840 Changes from -07 to -08: 841 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 842 for entry/attribute names. 843 2. Updated examples to match new astring syntax. 844 3. Changed CAPABILITY name due to incompatible syntax change. 845 4. Removed content-type attribute. 846 5. Added Content-type to IANA registration for entries. 847 6. Removed vendor attributes. 848 7. Fixed examples in section 3.3 for multi-mailbox and multi-entry 849 cases. 850 8. Removed wildcards for attributes. 851 9. Entry/attributes can now only be ASCII. 852 10. Tied up text wrt storing/fetching. 853 11. Added Conventions section 854 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 855 '.'. 856 13. Changed to use IMAP ABNF extensions document for some formal 857 syntax items. 859 Changes from -06 to -07: 861 1. Reworded /checkperiod item. 862 2. Clarified unsolicited response behavior. 864 Changes from -05 to -06: 865 1. Removed 'modifiedsince' attribute as there is currently no use 866 for it. 867 2. Added content-language attribute. 868 3. Changed access to allow .priv and .shared on any mailbox returned 869 by LIST/LSUB. 870 4. Added IANA registrations for items defined in this document. 871 5. Added latest IPR statement. 872 6. Updated references. 874 Changes from -04 to -05: 875 1. Fix for valid IMAP state of commands. 876 2. Fix formatting, ID nits etc. 878 Changes from -03 to -04: 879 1. Allow retrieval of shared annotations for READ-ONLY mailbox. 880 2. Clarification of annotation loss on implicit removal of \Noselect 881 mailboxes. 882 3. Now requires roll-back of all changes to matching mailboxes if 883 there is a partial failure in SETANNOTATION. 885 Changes from -02 to -03: 886 1. Reworked entry naming scheme to split out mailbox name and use 887 empty string for server items. 889 Changes from -01 to -02: 890 1. SETANNOTATION lists use (..). 891 2. Explicitly state behavior of unsolicited responses. 892 3. Adding SHOULD behavior for rename/delete of mailboxes. 893 4. Added statement about supporting annotations on \Noselect 894 mailboxes. 895 5. Cleaned up formal syntax to use IMAP string type for entry and 896 attributes, with requirements on how the string is formatted. 897 6. Use of ACAP vendor subtree registry for vendor tokens. 899 Changes from -00 to -01: 900 1. Multiple entry-att responses are now simply delimited by spaces 901 in line with ANNOTATE spec. Adjusted examples to match. 902 2. Fixed entry-list formal syntax item to account for unsolicited 903 parenthesized list of entries. 904 3. Removed setentries formal syntax item for simplicity since its 905 only used once. 906 4. Removed reference to 'message annotation' in section 5.1. 908 5. Changed formal syntax to restrict top level entries to /server 909 and /mailbox/{...} only. Re-arranged entry names section to 910 account for this change. 911 6. Added comment and example for ANNOTATION response to allow 912 servers to return separate responses for each entry if desired. 914 Author's Address 916 Cyrus Daboo 917 Apple Inc. 918 1 Infinite Loop 919 Cupertino, CA 95014 920 USA 922 Email: cyrus@daboo.name 923 URI: http://www.apple.com/ 925 Full Copyright Statement 927 Copyright (C) The IETF Trust (2008). 929 This document is subject to the rights, licenses and restrictions 930 contained in BCP 78, and except as set forth therein, the authors 931 retain all their rights. 933 This document and the information contained herein are provided on an 934 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 935 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 936 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 937 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 938 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 939 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 941 Intellectual Property 943 The IETF takes no position regarding the validity or scope of any 944 Intellectual Property Rights or other rights that might be claimed to 945 pertain to the implementation or use of the technology described in 946 this document or the extent to which any license under such rights 947 might or might not be available; nor does it represent that it has 948 made any independent effort to identify any such rights. Information 949 on the procedures with respect to rights in RFC documents can be 950 found in BCP 78 and BCP 79. 952 Copies of IPR disclosures made to the IETF Secretariat and any 953 assurances of licenses to be made available, or the result of an 954 attempt made to obtain a general license or permission for the use of 955 such proprietary rights by implementers or users of this 956 specification can be obtained from the IETF on-line IPR repository at 957 http://www.ietf.org/ipr. 959 The IETF invites any interested party to bring to its attention any 960 copyrights, patents or patent applications, or other proprietary 961 rights that may cover technology that may be required to implement 962 this standard. Please address the information to the IETF at 963 ietf-ipr@ietf.org.