idnits 2.17.1 draft-daboo-imap-annotatemore-13.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 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 928. 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 (April 21, 2008) is 5848 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 438, 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 April 21, 2008 5 Expires: October 23, 2008 7 IMAP METADATA Extension 8 draft-daboo-imap-annotatemore-13 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 October 23, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 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 . . . . . . . . . . . . . . 3 53 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Namespace of entries . . . . . . . . . . . . . . . . . . . 4 56 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Private versus Public and Access Control . . . . . . . . . 6 58 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6 59 4.1. General Considerations . . . . . . . . . . . . . . . . . . 6 60 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 7 61 4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 9 62 4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 10 63 4.4.1. METADATA response with values . . . . . . . . . . . . 11 64 4.4.2. Unsolicited METADATA response without values . . . . . 11 65 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 6.1. Entry and Attribute Registration Template . . . . . . . . 14 68 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 14 69 6.2.1. /public/comment . . . . . . . . . . . . . . . . . . . 15 70 6.2.2. /public/admin . . . . . . . . . . . . . . . . . . . . 15 71 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 15 72 6.3.1. /public/comment . . . . . . . . . . . . . . . . . . . 16 73 6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 16 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 8. Normative References . . . . . . . . . . . . . . . . . . . . . 17 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 77 Appendix B. Change History (to be removed prior to 78 publication as an RFC) . . . . . . . . . . . . . . . 17 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 Intellectual Property and Copyright Statements . . . . . . . . . . 21 82 1. Introduction and Overview 84 The goal of the METADATA extension is to provide a means for clients 85 to set and retrieve "annotations" or "meta data" on an IMAP server. 86 The annotations can be associated with specific mailboxes or the 87 server as a whole. The server can choose to support only server 88 annotations or both server and mailbox annotations. 90 A server that supports both server and mailbox annotations indicates 91 the presence of this extension by returning "METADATA" as one of the 92 supported capabilities in the CAPABILITY command response. The 93 "ENABLE" [RFC5161] extensions MUST also be present. 95 A server that supports only server annotations indicates the presence 96 of this extension by returning "METADATA-SERVER" as one of the 97 supported capabilities in the CAPABILITY command response. The 98 "ENABLE" [RFC5161] extension MUST also be present. 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. 159 Entry names MUST NOT contain asterisk ("*") or percent ("%") 160 characters and MUST NOT contain non-ASCII characters or the NUL 161 octet. Invalid entry names result in a BAD response in any IMAP 162 commands where they are used. 164 Entry names are case-insensitive. 166 Use of control or punctuation characters in entry names is strongly 167 discouraged. 169 This specification defines an initial set of entry available for use 170 with mailbox and server annotations. In addition an extension 171 mechanism is described to allow additional names to be added for 172 extensibility. 174 The first component in entry names defines the scope of the 175 annotation. Currently only the prefixes "/private" or "/public" are 176 defined. These prefixes are used to indicate whether an annotation 177 is stored on a per-user basis ("/private") and not visible to other 178 users, or whether and annotations is shared between all users 179 ("/public") with a single value that can be read and changed by all 180 users with appropriate access. See Section 3.3 for details. 182 3.2.1. Entry Names 184 Entry names MUST be specified in a standards track or IESG approved 185 experimental RFC, or fall under the vendor namespace. See 186 Section 6.1 for the registration template. 188 3.2.1.1. Server Entries 190 These entries are set or retrieved when the mailbox name argument to 191 the new SETMETADATA or GETMETATDATA commands is the empty string. 193 /public/comment 194 Defines a comment or note associated with the server shared with 195 all users of the server. 197 /public/admin 198 Indicates a method for contacting the server administrator. The 199 value MUST be a URI (e.g., a mailto: or tel: URL). This entry is 200 always read-only - clients cannot change it. It is visible to all 201 users of the system. 203 /public/vendor/ 204 Defines the top-level of public entries associated with the server 205 as created by a particular product of some vendor. This entry can 206 be used by vendors to provide server or client specific 207 annotations. The vendor-token MUST be registered with IANA, using 208 the ACAP [RFC2244] vendor subtree registry. 210 /private/vendor/ 211 Defines the top-level of private entries associated with the 212 server as created by a particular product of some vendor. This 213 entry can be used by vendors to provide server or client specific 214 annotations. The vendor-token MUST be registered with IANA, using 215 the ACAP [RFC2244] vendor subtree registry. 217 3.2.1.2. Mailbox Entries 219 These entries are set or retrieved when the mailbox name argument to 220 the new SETMETADATA or GETMETADATA commands is not the empty string. 222 /public/comment 223 Defines a public comment or note associated with a mailbox. 225 /private/comment 226 Defines a private (per-user) comment or note associated with a 227 mailbox. 229 /public/vendor/ 230 Defines the top-level of public entries associated with a specific 231 mailbox as created by a particular product of some vendor. This 232 entry can be used by vendors to provide client specific 233 annotations. The vendor-token MUST be registered with IANA, using 234 the ACAP [RFC2244] vendor subtree registry. 236 /private/vendor/ 237 Defines the top-level of private entries associated with a 238 specific mailbox as created by a particular product of some 239 vendor. This entry can be used by vendors to provide client 240 specific annotations. The vendor-token MUST be registered with 241 IANA, using the ACAP [RFC2244] vendor subtree registry. 243 3.3. Private versus Public and Access Control 245 A user can only set and retrieve private or public annotations on a 246 mailbox which exists and is returned to them via a LIST or LSUB 247 command, irrespective of whether they have read or write access to 248 the actual message content of the mailbox. If the client attempts to 249 set or retrieve annotations on other mailboxes, the server MUST 250 respond with a NO response. 252 If the METADATA extension is present, support for public annotations 253 is REQUIRED, whilst support for private annotations is OPTIONAL. 254 This recognizes the fact that support for private annotations may 255 introduce significantly more complexity to a server in terms of 256 tracking ownership of the annotations, how quota is determined for 257 users based on their own annotations etc. 259 4. IMAP Protocol Changes 261 4.1. General Considerations 263 The new SETMETADATA command and the METADATA response each have a 264 mailbox name argument. An empty string is used for the mailbox name 265 to signify server annotations. A non-empty string is used to signify 266 mailbox annotations attached to the corresponding mailbox. 268 Servers SHOULD ensure that mailbox annotations are automatically 269 moved when the mailbox they refer to is renamed, i.e. the annotations 270 follow the mailbox. This applies to a rename of the INBOX, with the 271 additional behavior that the annotations are copied from the original 272 INBOX to the renamed mailbox. i.e. mailbox annotations are preserved 273 on the INBOX when it is renamed. 275 Servers SHOULD delete annotations for a mailbox when the mailbox is 276 deleted, so that a mailbox created with the same name as a previously 277 existing mailbox does not inherit the old mailbox annotations. 279 Servers SHOULD allow annotations on all 'types' of mailbox, including 280 ones reporting \Noselect for their LIST response. Servers can 281 implicitly remove \Noselect mailboxes when all child mailboxes are 282 removed, and as such any annotations associated with the \Noselect 283 mailbox SHOULD be removed. 285 The server is allowed to impose limitations on the size of any one 286 annotation or the total number of annotations for a single mailbox or 287 for the server as a whole. However, the server MUST accept a minimum 288 annotation data size of at least 1024 bytes, and a minimum annotation 289 count per server or mailbox of at least 10. 291 Some annotations may be "read-only" - i.e. they are set by the server 292 and cannot be changed by the client. Also, such annotations may be 293 "computed" - i.e. the value changes based on underlying properties of 294 the mailbox or server. For example, an annotation reporting the 295 total size of all messages in the mailbox would change as messages 296 are added or removed. Or, an annotation containing an IMAP URL for 297 the mailbox would change if the mailbox was renamed. 299 This extension defines some unsolicited responses for use when 300 annotations are changed by some "third-party" (see Section 4.4). The 301 server MUST only send these unsolicited responses if the client used 302 the ENABLE command [RFC5161] extension with the capability string 303 "METADATA" earlier in the session. 305 4.2. GETMETADATA Command 307 This extension adds the GETMETADATA command. This allows clients to 308 retrieve server or mailbox annotations. 310 This command is only available in authenticated or selected state 311 [RFC3501]. 313 Arguments: mailbox-name 314 entry-specifier 316 Responses: required METADATA response 318 Result: OK - command completed 319 NO - command failure: can't access annotations on 320 the server 321 BAD - command unknown or arguments invalid 323 When the mailbox name is the empty string, this command retrieves 324 server annotations. When the mailbox name is not empty, this command 325 retrieves annotations on the specified mailbox. 327 Example: 329 C: a GETMETADATA "" /public/comment 330 S: * METADATA "" (/public/comment "Shared comment") 331 S: a OK GETMETADATA complete 333 In the above example, the contents of the value of the "/public/ 334 comment" server entry is requested by the client and returned by 335 the server. 337 Example: 339 C: a GETMETADATA "INBOX" /private/comment 340 S: * METADATA "INBOX" (/private/comment "My own comment") 341 S: a OK GETMETADATA complete 343 In the above example, the contents of the value of the "/private/ 344 comment" mailbox entry for the mailbox "INBOX" is requested by the 345 client and returned by the server. 347 Entry specifiers can be lists of atomic specifiers, so that multiple 348 annotations may be returned in a single GETMETADATA command. 350 Example: 352 C: a GETMETADATA "INBOX" (/public/comment /private/comment) 353 S: * METADATA "INBOX" (/public/comment "Shared comment" 354 /private/comment "My own comment") 355 S: a OK GETMETADATA complete 357 In the above example, the values of the two server entries 358 "/public/comment" and "/private/comment" on the mailbox "inbox" 359 are requested by the client and returned by the server. 361 4.3. SETMETADATA Command 363 This extension adds the SETMETADATA command. This allows clients to 364 set annotations. 366 This command is only available in authenticated or selected state 367 [RFC3501]. 369 Arguments: mailbox-name 370 entry 371 value 372 list of entry, values 374 Responses: no specific responses for this command 376 Result: OK - command completed 377 NO - command failure: can't set annotations, 378 or annotation too big or too many 379 BAD - command unknown or arguments invalid 381 This command sets the specified list of entries by adding or 382 replacing the specified values provided, on the specified existing 383 mailboxes or on the server (if the mailbox argument is the empty 384 string). Clients can use NIL for the value of entries it wants to 385 remove. The server SHOULD NOT return a METADATA response containing 386 the updated annotation data. Clients MUST NOT assume that a METADATA 387 response will be sent, and MUST assume that if the command succeeds 388 then the annotation has been changed. 390 If the server is unable to set an annotation because the size of its 391 value is too large, the server MUST return a tagged NO response with 392 a "[METADATA MAXSIZE NNN]" response code when NNN is the maximum 393 octet count that it is willingly to accept. 395 If the server is unable to set a new annotation because the maximum 396 number of allowed annotations has already been reached, the server 397 MUST return a tagged NO response with a "[METADATA TOOMANY]" response 398 code. 400 If the server is unable to set a new annotation because it does not 401 support private annotations on one of the specified mailboxes, the 402 server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" 403 response code. 405 Example: 407 C: a SETMETADATA INBOX (/private/comment "My new comment") 408 S: a OK SETMETADATA complete 410 In the above example, the entry "/private/comment" for the mailbox 411 "INBOX" is created (if not already present) and the value set to 412 "My new comment". 414 Example: 416 C: a SETMETADATA INBOX (/private/comment NIL) 417 S: a OK SETMETADATA complete 419 In the above example, the entry "/private/comment" is removed from 420 the mailbox "INBOX". 422 Multiple entries can be set in a single SETMETADATA command by 423 listing entry-value pairs in the list. 425 Example: 427 C: a SETMETADATA INBOX (/private/comment "My new comment" 428 /public/comment "This one is for you!") 429 S: a OK SETMETADATA complete 431 In the above example, the entries "/private/comment" and "/public/ 432 comment" for the mailbox "INBOX" are created (if not already 433 present) and the values set as specified. 435 Example: 437 C: a SETMETADATA INBOX (/private/comment "My new comment") 438 S: a NO [METADATA TOOMANY] SETMETADATA failed 440 In the above example, the server is unable to set the requested 441 (new) annotation as it has reached the limit on the number of 442 annotations it can support on the specified mailbox. 444 4.4. METADATA Response 446 The METADATA response displays results of a GETMETADATA command, or 447 can be returned as an unsolicited response at anytime by the server 448 in response to a change in a server or mailbox annotation. 450 Subject to unsolicited responses being activated by the ENABLE 451 [RFC5161] command for this extension, servers SHOULD send unsolicited 452 METADATA responses if server or mailbox annotations are changed by a 453 third-party, allowing servers to keep clients updated with changes. 455 Unsolicited METADATA responses MUST only contain entry names, not the 456 values. If the client wants to update any cached values it must 457 explicitly retrieve those using a GETMETADATA command. 459 The METADATA response can contain multiple entries in a single 460 response, but the server is free to return multiple responses for 461 each entry or group of entries if it desires. 463 This response is only available in authenticated or selected state 464 [RFC3501]. 466 4.4.1. METADATA response with values 468 The response consists of a list of entry-value pairs. 470 Example: 472 C: a GETMETADATA "" /public/comment 473 S: * METADATA "" (/public/comment "My comment") 474 S: a OK GETMETADATA complete 476 In the above example, a single entry with its value is returned by 477 the server. 479 Example: 481 C: a GETMETADATA "INBOX" /private/comment /public/comment 482 S: * METADATA "INBOX" (/private/comment "My comment" 483 /public/comment "Its sunny outside!") 484 S: a OK GETMETADATA complete 486 In the above example, two entries and their values are returned by 487 the server. 489 Example: 491 C: a GETMETADATA "INBOX" /private/comment /public/comment 492 S: * METADATA "INBOX" (/private/comment "My comment") 493 S: * METADATA "INBOX" (/public/comment "Its sunny outside!") 494 S: a OK GETMETADATA complete 496 In the above example, the server returns two separate responses 497 for each of the two entries requested. 499 4.4.2. Unsolicited METADATA response without values 501 The response consists of a list of entries, each of which have 502 changed on the server or mailbox. 504 Example: 506 C: a NOOP 507 S: * METADATA "" /public/comment 508 S: a OK NOOP complete 510 In the above example, the server indicates that the "/public/ 511 comment" server entry has been changed. 513 Example: 515 C: a NOOP 516 S: * METADATA "INBOX" /public/comment /private/comment 517 S: a OK NOOP complete 519 In the above example, the server indicates a change to two mailbox 520 entries. 522 5. Formal Syntax 524 The following syntax specification uses the Augmented Backus-Naur 525 Form (ABNF) notation as specified in [RFC5234]. 527 Non-terminals referenced but not defined below are as defined by 528 [RFC3501] with the new definitions in [RFC4466] superseding those in 529 [RFC3501]. 531 Except as noted otherwise, all alphabetic characters are case- 532 insensitive. The use of upper or lower case characters to define 533 token strings is for editorial clarity only. Implementations MUST 534 accept these strings in a case-insensitive fashion. 536 capability =/ "METADATA" / "METADATA-SERVER" 537 ; defines the capabilities for this extension 539 command-auth =/ setmetadata / getmetadata 540 ; adds to original IMAP command 542 entries = entry / 543 "(" entry *(SP entry) ")" 544 ; entry specifiers 546 entry = astring 547 ; slash-separated path to entry 548 ; MUST NOT contain "*" or "%" 550 entry-value = entry SP value 552 entry-values = "(" entry-value *(SP entry-value) ")" 554 entry-list = entry *(SP entry) 555 ; list of entries used in unsolicited 556 ; METADATA response 558 getmetadata = "GETMETADATA" SP mailbox SP entries 559 ; empty string for mailbox implies 560 ; server annotation. 562 metadata-resp = "METADATA" SP mailbox SP 563 (entry-values / entry-list) 564 ; empty string for mailbox implies 565 ; server annotation. 567 response-payload =/ metadata-resp 568 ; adds to original IMAP data responses 570 resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number / 571 "TOOMANY" / "NOPRIVATE") 572 ; new response codes for SETMETADATA 573 ; failures 575 setmetadata = "SETMETADATA" SP mailbox 576 SP entry-values 577 ; empty string for mailbox implies 578 ; server annotation. 580 value = nstring / literal8 582 6. IANA Considerations 584 Entry names MUST be specified in a standards track or IESG approved 585 experimental RFC, or fall under the vendor namespace. All entries 586 MUST have either "/public" or "/private" as a prefix. 588 Each entry registration MUST include a content-type that is used to 589 indicate the nature of the annotation value. Where applicable a 590 charset parameter MUST be included with the content-type. 592 6.1. Entry and Attribute Registration Template 594 To: iana@iana.org 595 Subject: IMAP METADATA Entry Registration 597 Type: [Either "Mailbox" or "Server"] 599 Name: [the name of the entry] 601 Description: [a description of what the entry is for] 603 Content-type: [MIME Content-Type and charset for the entry value] 605 RFC Number: [for entries published as RFCs] 607 Contact: [email and/or physical address to contact for 608 additional information] 610 6.2. Server Entry Registrations 612 The following templates specify the IANA registrations of annotation 613 entries specified in this document. 615 6.2.1. /public/comment 617 To: iana@iana.org 618 Subject: IMAP METADATA Entry Registration 620 Type: Server 622 Name: /public/comment 624 Description: Defines a comment or note associated with the server 625 shared with all users of the server. 627 Content-type: text/plain; charset=utf-8 629 RFC Number: This RFC. 631 Contact: IMAP Extensions 633 6.2.2. /public/admin 635 To: iana@iana.org 636 Subject: IMAP METADATA Entry Registration 638 Type: Server 640 Name: /public/admin 642 Description: Indicates a method for contacting the server 643 administrator. The value MUST be a URI (e.g., a 644 mailto: or tel: URL). This entry is always 645 read-only - clients cannot change it. It is visible 646 to all users of the system. 648 Content-type: text/plain; charset=utf-8 650 RFC Number: This RFC. 652 Contact: IMAP Extensions 654 6.3. Mailbox Entry Registrations 656 The following templates specify the IANA registrations of annotation 657 entries specified in this document. 659 6.3.1. /public/comment 661 To: iana@iana.org 662 Subject: IMAP METADATA Entry Registration 664 Type: Mailbox 666 Name: /public/comment 668 Description: Defines a public comment or note associated with a 669 mailbox. 671 Content-type: text/plain; charset=utf-8 673 RFC Number: This RFC. 675 Contact: IMAP Extensions 677 6.3.2. /private/comment 679 To: iana@iana.org 680 Subject: IMAP METADATA Entry Registration 682 Type: Mailbox 684 Name: /private/comment 686 Description: Defines a public comment or note associated with a 687 mailbox. 689 Content-type: text/plain; charset=utf-8 691 RFC Number: This RFC. 693 Contact: IMAP Extensions 695 7. Security Considerations 697 Annotations whose values are intended to remain private MUST be 698 stored only in entries that have the "/private" prefix on the entry 699 name. 701 Annotations can contain arbitrary sized data. As such servers MUST 702 ensure that size limits are enforced to prevent a user from using up 703 all available space on a server and preventing use by others. 705 Excluding the above issues the METADATA extension does not raise any 706 security considerations that are not present in the base IMAP 707 protocol, and these issues are discussed in [RFC3501]. 709 8. Normative References 711 [I-D.ietf-imapext-i18n] 712 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 713 Message Access Protocol Internationalization", 714 draft-ietf-imapext-i18n-15 (work in progress), 715 February 2008. 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 720 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 721 Configuration Access Protocol", RFC 2244, November 1997. 723 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 724 4rev1", RFC 3501, March 2003. 726 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 727 ABNF", RFC 4466, April 2006. 729 [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation 730 Algorithm", RFC 5051, October 2007. 732 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 733 Extension", RFC 5161, March 2008. 735 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 736 Specifications: ABNF", STD 68, RFC 5234, January 2008. 738 Appendix A. Acknowledgments 740 The ideas expressed in this document are based on the message 741 annotation document that was co-authored by Randall Gellens. The 742 participants of the IMAPext working group made significant 743 contributions to this work. 745 Appendix B. Change History (to be removed prior to publication as an 746 RFC) 748 Changes from -12 to -13: 750 1. Major changes to simplify things. 751 2. Removed dependency on LISTEXT - GETMETADATA now used to get 752 annotations on mailboxes. 753 3. Changed data model to remove attributes - annotations are now 754 only entry-value pairs. 755 4. Removed all wildcard behavior on entry names. 756 5. Cut down the registered annotations to only a few essential ones. 758 Changes from -11 to -12: 759 1. Allow server annotations to be used without mailbox annotations. 760 2. Require i;unicode-casemap when COMPARATOR is not present. 761 3. Use ENABLE to turn on unsolicited responses. 762 4. Use formal syntax elements from SORT/THREAD extensions to define 763 the values for /sort and /thread entries. 764 5. Added a comment that use of IDLE is preferred even when /check 765 is true. 766 6. Use formal syntax element from base spec for the /size value. 767 7. Removed IANA registration for attributes as we don't expect any 768 more to be defined. 769 8. Tweaked IANA registration template to be more compact and add 770 RFC Number reference. 771 9. Some minor re-phrasing was done. 772 10. Added text about handling of annotations on INBOX when it is 773 renamed. 774 11. Require a BAD response when an unknown collation is used in 775 LISTEXT selection option. 777 Changes from -10 to -11: 778 1. Added new paragraph to indicate that values may be read-only or 779 computed. 780 2. /admin server annotation value now must be a URI. 781 3. Clarified that SORT and THREAD extensions are not required. 782 4. Fixed use of undefined entries in some examples. 783 5. Fixed many examples. 784 6. Added IANA registration for LIST-EXTENDED items. 785 7. Added match type and collation identifier to the LIST-EXTENDED 786 selection option. 787 8. Made support for IMAP-I18N a requirement. 788 9. Minor text clarifications applied. 789 10. Remove mailbox list set atomicity requirement. 790 11. Clarified that annotations can only be set on mailboxes that 791 actually exist. 793 Changes from -09 to -10: 794 1. Updated to rfc 4466 reference. 795 2. Reworded data model description. 797 3. Reworked LIST-EXTENDED so that responses have metadata items 798 after the mailbox info. 799 4. Various spelling fixes. 801 Changes from -08 to -09: 802 1. Remove content-language attribute and reference. 803 2. Changed capability and command names. 804 3. Revised abstract. 806 Changes from -07 to -08: 807 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 808 for entry/attribute names. 809 2. Updated examples to match new astring syntax. 810 3. Changed CAPABILITY name due to incompatible syntax change. 811 4. Removed content-type attribute. 812 5. Added Content-type to IANA registration for entries. 813 6. Removed vendor attributes. 814 7. Fixed examples in section 3.3 for multi-mailbox and multi-entry 815 cases. 816 8. Removed wildcards for attributes. 817 9. Entry/attributes can now only be ASCII. 818 10. Tied up text wrt storing/fetching. 819 11. Added Conventions section 820 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 821 '.'. 822 13. Changed to use IMAP ABNF extensions document for some formal 823 syntax items. 825 Changes from -06 to -07: 826 1. Reworded /checkperiod item. 827 2. Clarified unsolicited response behavior. 829 Changes from -05 to -06: 830 1. Removed 'modifiedsince' attribute as there is currently no use 831 for it. 832 2. Added content-language attribute. 833 3. Changed access to allow .priv and .shared on any mailbox returned 834 by LIST/LSUB. 835 4. Added IANA registrations for items defined in this document. 836 5. Added latest IPR statement. 837 6. Updated references. 839 Changes from -04 to -05: 840 1. Fix for valid IMAP state of commands. 841 2. Fix formatting, ID nits etc. 843 Changes from -03 to -04: 845 1. Allow retrieval of shared annotations for READ-ONLY mailbox. 846 2. Clarification of annotation loss on implicit removal of \Noselect 847 mailboxes. 848 3. Now requires roll-back of all changes to matching mailboxes if 849 there is a partial failure in SETANNOTATION. 851 Changes from -02 to -03: 852 1. Reworked entry naming scheme to split out mailbox name and use 853 empty string for server items. 855 Changes from -01 to -02: 856 1. SETANNOTATION lists use (..). 857 2. Explicitly state behavior of unsolicited responses. 858 3. Adding SHOULD behavior for rename/delete of mailboxes. 859 4. Added statement about supporting annotations on \Noselect 860 mailboxes. 861 5. Cleaned up formal syntax to use IMAP string type for entry and 862 attributes, with requirements on how the string is formatted. 863 6. Use of ACAP vendor subtree registry for vendor tokens. 865 Changes from -00 to -01: 866 1. Multiple entry-att responses are now simply delimited by spaces 867 in line with ANNOTATE spec. Adjusted examples to match. 868 2. Fixed entry-list formal syntax item to account for unsolicited 869 parenthesized list of entries. 870 3. Removed setentries formal syntax item for simplicity since its 871 only used once. 872 4. Removed reference to 'message annotation' in section 5.1. 873 5. Changed formal syntax to restrict top level entries to /server 874 and /mailbox/{...} only. Re-arranged entry names section to 875 account for this change. 876 6. Added comment and example for ANNOTATION response to allow 877 servers to return separate responses for each entry if desired. 879 Author's Address 881 Cyrus Daboo 882 Apple Inc. 883 1 Infinite Loop 884 Cupertino, CA 95014 885 USA 887 Email: cyrus@daboo.name 888 URI: http://www.apple.com/ 890 Full Copyright Statement 892 Copyright (C) The IETF Trust (2008). 894 This document is subject to the rights, licenses and restrictions 895 contained in BCP 78, and except as set forth therein, the authors 896 retain all their rights. 898 This document and the information contained herein are provided on an 899 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 900 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 901 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 902 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 903 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 904 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 906 Intellectual Property 908 The IETF takes no position regarding the validity or scope of any 909 Intellectual Property Rights or other rights that might be claimed to 910 pertain to the implementation or use of the technology described in 911 this document or the extent to which any license under such rights 912 might or might not be available; nor does it represent that it has 913 made any independent effort to identify any such rights. Information 914 on the procedures with respect to rights in RFC documents can be 915 found in BCP 78 and BCP 79. 917 Copies of IPR disclosures made to the IETF Secretariat and any 918 assurances of licenses to be made available, or the result of an 919 attempt made to obtain a general license or permission for the use of 920 such proprietary rights by implementers or users of this 921 specification can be obtained from the IETF on-line IPR repository at 922 http://www.ietf.org/ipr. 924 The IETF invites any interested party to bring to its attention any 925 copyrights, patents or patent applications, or other proprietary 926 rights that may cover technology that may be required to implement 927 this standard. Please address the information to the IETF at 928 ietf-ipr@ietf.org. 930 Acknowledgment 932 Funding for the RFC Editor function is provided by the IETF 933 Administrative Support Activity (IASA).