Network Working Group C. Daboo Internet-Draft Apple Intended status: Standards Track April 21, 2008 Expires: October 23, 2008 IMAP METADATA Extension draft-daboo-imap-annotatemore-13 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 23, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "meta data" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. Daboo Expires October 23, 2008 [Page 1] Internet-Draft IMAP METADATA Extension April 2008 Table of Contents 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Namespace of entries . . . . . . . . . . . . . . . . . . . 4 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5 3.3. Private versus Public and Access Control . . . . . . . . . 6 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6 4.1. General Considerations . . . . . . . . . . . . . . . . . . 6 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 7 4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 9 4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 10 4.4.1. METADATA response with values . . . . . . . . . . . . 11 4.4.2. Unsolicited METADATA response without values . . . . . 11 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. Entry and Attribute Registration Template . . . . . . . . 14 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 14 6.2.1. /public/comment . . . . . . . . . . . . . . . . . . . 15 6.2.2. /public/admin . . . . . . . . . . . . . . . . . . . . 15 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 15 6.3.1. /public/comment . . . . . . . . . . . . . . . . . . . 16 6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change History (to be removed prior to publication as an RFC) . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Daboo Expires October 23, 2008 [Page 2] Internet-Draft IMAP METADATA Extension April 2008 1. Introduction and Overview The goal of the METADATA extension is to provide a means for clients to set and retrieve "annotations" or "meta data" on an IMAP server. The annotations can be associated with specific mailboxes or the server as a whole. The server can choose to support only server annotations or both server and mailbox annotations. A server that supports both server and mailbox annotations indicates the presence of this extension by returning "METADATA" as one of the supported capabilities in the CAPABILITY command response. The "ENABLE" [RFC5161] extensions MUST also be present. A server that supports only server annotations indicates the presence of this extension by returning "METADATA-SERVER" as one of the supported capabilities in the CAPABILITY command response. The "ENABLE" [RFC5161] extension MUST also be present. The METADATA extension adds two new commands and one new untagged response to the IMAP base protocol. This extension makes the following changes to the IMAP protocol: o adds a new SETMETADATA command o adds a new GETMETADATA command o adds a new METADATA untagged response o adds a new METADATA response code Text comparisons may be done as part of the GETMETADATA command. If the COMPARATOR [I-D.ietf-imapext-i18n] extension is present, then comparisons are done using the comparator in effect at the time. If the COMPARATOR extension is not present, then comparisons MUST use the i;unicode-casemap comparator, as defined in [RFC5051]. The rest of this document describes the data model and protocol changes more rigorously. 2. Conventions Used in This Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Daboo Expires October 23, 2008 [Page 3] Internet-Draft IMAP METADATA Extension April 2008 Whitespace and line breaks have been added to the examples in this document to promote readability. 3. Data Model 3.1. Overview Mailboxes or the server as a whole may have zero or more annotations associated with them. An annotation contains a uniquely named entry each of which has a value. Annotations can be added to mailboxes when a mailbox name is provided as the first argument to the SETMETADATA command, or to the server as a whole when the empty string is provided as the first argument to the command. For example, a general comment being added to a mailbox may have an entry name of "/comment" and a value "Really useful mailbox". The protocol changes to IMAP described below allow a client to access or change the values of any annotation entry, assuming it has sufficient access rights to do so. 3.2. Namespace of entries Each annotation is an entry that has a hierarchical name, with each component of the name separated by a slash ("/"). An entry name MUST NOT contain two consecutive "/" characters and MUST NOT end with a "/" character. The value of an entry is NIL (has no value), or a string or binary data of zero or more octets. Entry names MUST NOT contain asterisk ("*") or percent ("%") characters and MUST NOT contain non-ASCII characters or the NUL octet. Invalid entry names result in a BAD response in any IMAP commands where they are used. Entry names are case-insensitive. Use of control or punctuation characters in entry names is strongly discouraged. This specification defines an initial set of entry available for use with mailbox and server annotations. In addition an extension mechanism is described to allow additional names to be added for extensibility. The first component in entry names defines the scope of the Daboo Expires October 23, 2008 [Page 4] Internet-Draft IMAP METADATA Extension April 2008 annotation. Currently only the prefixes "/private" or "/public" are defined. These prefixes are used to indicate whether an annotation is stored on a per-user basis ("/private") and not visible to other users, or whether and annotations is shared between all users ("/public") with a single value that can be read and changed by all users with appropriate access. See Section 3.3 for details. 3.2.1. Entry Names Entry names MUST be specified in a standards track or IESG approved experimental RFC, or fall under the vendor namespace. See Section 6.1 for the registration template. 3.2.1.1. Server Entries These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETATDATA commands is the empty string. /public/comment Defines a comment or note associated with the server shared with all users of the server. /public/admin Indicates a method for contacting the server administrator. The value MUST be a URI (e.g., a mailto: or tel: URL). This entry is always read-only - clients cannot change it. It is visible to all users of the system. /public/vendor/ Defines the top-level of public entries associated with the server as created by a particular product of some vendor. This entry can be used by vendors to provide server or client specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry. /private/vendor/ Defines the top-level of private entries associated with the server as created by a particular product of some vendor. This entry can be used by vendors to provide server or client specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry. 3.2.1.2. Mailbox Entries These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETADATA commands is not the empty string. /public/comment Daboo Expires October 23, 2008 [Page 5] Internet-Draft IMAP METADATA Extension April 2008 Defines a public comment or note associated with a mailbox. /private/comment Defines a private (per-user) comment or note associated with a mailbox. /public/vendor/ Defines the top-level of public entries associated with a specific mailbox as created by a particular product of some vendor. This entry can be used by vendors to provide client specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry. /private/vendor/ Defines the top-level of private entries associated with a specific mailbox as created by a particular product of some vendor. This entry can be used by vendors to provide client specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry. 3.3. Private versus Public and Access Control A user can only set and retrieve private or public annotations on a mailbox which exists and is returned to them via a LIST or LSUB command, irrespective of whether they have read or write access to the actual message content of the mailbox. If the client attempts to set or retrieve annotations on other mailboxes, the server MUST respond with a NO response. If the METADATA extension is present, support for public annotations is REQUIRED, whilst support for private annotations is OPTIONAL. This recognizes the fact that support for private annotations may introduce significantly more complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations etc. 4. IMAP Protocol Changes 4.1. General Considerations The new SETMETADATA command and the METADATA response each have a mailbox name argument. An empty string is used for the mailbox name to signify server annotations. A non-empty string is used to signify mailbox annotations attached to the corresponding mailbox. Servers SHOULD ensure that mailbox annotations are automatically moved when the mailbox they refer to is renamed, i.e. the annotations Daboo Expires October 23, 2008 [Page 6] Internet-Draft IMAP METADATA Extension April 2008 follow the mailbox. This applies to a rename of the INBOX, with the additional behavior that the annotations are copied from the original INBOX to the renamed mailbox. i.e. mailbox annotations are preserved on the INBOX when it is renamed. Servers SHOULD delete annotations for a mailbox when the mailbox is deleted, so that a mailbox created with the same name as a previously existing mailbox does not inherit the old mailbox annotations. Servers SHOULD allow annotations on all 'types' of mailbox, including ones reporting \Noselect for their LIST response. Servers can implicitly remove \Noselect mailboxes when all child mailboxes are removed, and as such any annotations associated with the \Noselect mailbox SHOULD be removed. The server is allowed to impose limitations on the size of any one annotation or the total number of annotations for a single mailbox or for the server as a whole. However, the server MUST accept a minimum annotation data size of at least 1024 bytes, and a minimum annotation count per server or mailbox of at least 10. Some annotations may be "read-only" - i.e. they are set by the server and cannot be changed by the client. Also, such annotations may be "computed" - i.e. the value changes based on underlying properties of the mailbox or server. For example, an annotation reporting the total size of all messages in the mailbox would change as messages are added or removed. Or, an annotation containing an IMAP URL for the mailbox would change if the mailbox was renamed. This extension defines some unsolicited responses for use when annotations are changed by some "third-party" (see Section 4.4). The server MUST only send these unsolicited responses if the client used the ENABLE command [RFC5161] extension with the capability string "METADATA" earlier in the session. 4.2. GETMETADATA Command This extension adds the GETMETADATA command. This allows clients to retrieve server or mailbox annotations. This command is only available in authenticated or selected state [RFC3501]. Daboo Expires October 23, 2008 [Page 7] Internet-Draft IMAP METADATA Extension April 2008 Arguments: mailbox-name entry-specifier Responses: required METADATA response Result: OK - command completed NO - command failure: can't access annotations on the server BAD - command unknown or arguments invalid When the mailbox name is the empty string, this command retrieves server annotations. When the mailbox name is not empty, this command retrieves annotations on the specified mailbox. Example: C: a GETMETADATA "" /public/comment S: * METADATA "" (/public/comment "Shared comment") S: a OK GETMETADATA complete In the above example, the contents of the value of the "/public/ comment" server entry is requested by the client and returned by the server. Example: C: a GETMETADATA "INBOX" /private/comment S: * METADATA "INBOX" (/private/comment "My own comment") S: a OK GETMETADATA complete In the above example, the contents of the value of the "/private/ comment" mailbox entry for the mailbox "INBOX" is requested by the client and returned by the server. Entry specifiers can be lists of atomic specifiers, so that multiple annotations may be returned in a single GETMETADATA command. Example: C: a GETMETADATA "INBOX" (/public/comment /private/comment) S: * METADATA "INBOX" (/public/comment "Shared comment" /private/comment "My own comment") S: a OK GETMETADATA complete In the above example, the values of the two server entries "/public/comment" and "/private/comment" on the mailbox "inbox" are requested by the client and returned by the server. Daboo Expires October 23, 2008 [Page 8] Internet-Draft IMAP METADATA Extension April 2008 4.3. SETMETADATA Command This extension adds the SETMETADATA command. This allows clients to set annotations. This command is only available in authenticated or selected state [RFC3501]. Arguments: mailbox-name entry value list of entry, values Responses: no specific responses for this command Result: OK - command completed NO - command failure: can't set annotations, or annotation too big or too many BAD - command unknown or arguments invalid This command sets the specified list of entries by adding or replacing the specified values provided, on the specified existing mailboxes or on the server (if the mailbox argument is the empty string). Clients can use NIL for the value of entries it wants to remove. The server SHOULD NOT return a METADATA response containing the updated annotation data. Clients MUST NOT assume that a METADATA response will be sent, and MUST assume that if the command succeeds then the annotation has been changed. If the server is unable to set an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[METADATA MAXSIZE NNN]" response code when NNN is the maximum octet count that it is willingly to accept. If the server is unable to set a new annotation because the maximum number of allowed annotations has already been reached, the server MUST return a tagged NO response with a "[METADATA TOOMANY]" response code. If the server is unable to set a new annotation because it does not support private annotations on one of the specified mailboxes, the server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" response code. Example: C: a SETMETADATA INBOX (/private/comment "My new comment") S: a OK SETMETADATA complete Daboo Expires October 23, 2008 [Page 9] Internet-Draft IMAP METADATA Extension April 2008 In the above example, the entry "/private/comment" for the mailbox "INBOX" is created (if not already present) and the value set to "My new comment". Example: C: a SETMETADATA INBOX (/private/comment NIL) S: a OK SETMETADATA complete In the above example, the entry "/private/comment" is removed from the mailbox "INBOX". Multiple entries can be set in a single SETMETADATA command by listing entry-value pairs in the list. Example: C: a SETMETADATA INBOX (/private/comment "My new comment" /public/comment "This one is for you!") S: a OK SETMETADATA complete In the above example, the entries "/private/comment" and "/public/ comment" for the mailbox "INBOX" are created (if not already present) and the values set as specified. Example: C: a SETMETADATA INBOX (/private/comment "My new comment") S: a NO [METADATA TOOMANY] SETMETADATA failed In the above example, the server is unable to set the requested (new) annotation as it has reached the limit on the number of annotations it can support on the specified mailbox. 4.4. METADATA Response The METADATA response displays results of a GETMETADATA command, or can be returned as an unsolicited response at anytime by the server in response to a change in a server or mailbox annotation. Subject to unsolicited responses being activated by the ENABLE [RFC5161] command for this extension, servers SHOULD send unsolicited METADATA responses if server or mailbox annotations are changed by a third-party, allowing servers to keep clients updated with changes. Unsolicited METADATA responses MUST only contain entry names, not the values. If the client wants to update any cached values it must explicitly retrieve those using a GETMETADATA command. Daboo Expires October 23, 2008 [Page 10] Internet-Draft IMAP METADATA Extension April 2008 The METADATA response can contain multiple entries in a single response, but the server is free to return multiple responses for each entry or group of entries if it desires. This response is only available in authenticated or selected state [RFC3501]. 4.4.1. METADATA response with values The response consists of a list of entry-value pairs. Example: C: a GETMETADATA "" /public/comment S: * METADATA "" (/public/comment "My comment") S: a OK GETMETADATA complete In the above example, a single entry with its value is returned by the server. Example: C: a GETMETADATA "INBOX" /private/comment /public/comment S: * METADATA "INBOX" (/private/comment "My comment" /public/comment "Its sunny outside!") S: a OK GETMETADATA complete In the above example, two entries and their values are returned by the server. Example: C: a GETMETADATA "INBOX" /private/comment /public/comment S: * METADATA "INBOX" (/private/comment "My comment") S: * METADATA "INBOX" (/public/comment "Its sunny outside!") S: a OK GETMETADATA complete In the above example, the server returns two separate responses for each of the two entries requested. 4.4.2. Unsolicited METADATA response without values The response consists of a list of entries, each of which have changed on the server or mailbox. Example: Daboo Expires October 23, 2008 [Page 11] Internet-Draft IMAP METADATA Extension April 2008 C: a NOOP S: * METADATA "" /public/comment S: a OK NOOP complete In the above example, the server indicates that the "/public/ comment" server entry has been changed. Example: C: a NOOP S: * METADATA "INBOX" /public/comment /private/comment S: a OK NOOP complete In the above example, the server indicates a change to two mailbox entries. 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. Non-terminals referenced but not defined below are as defined by [RFC3501] with the new definitions in [RFC4466] superseding those in [RFC3501]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. Daboo Expires October 23, 2008 [Page 12] Internet-Draft IMAP METADATA Extension April 2008 capability =/ "METADATA" / "METADATA-SERVER" ; defines the capabilities for this extension command-auth =/ setmetadata / getmetadata ; adds to original IMAP command entries = entry / "(" entry *(SP entry) ")" ; entry specifiers entry = astring ; slash-separated path to entry ; MUST NOT contain "*" or "%" entry-value = entry SP value entry-values = "(" entry-value *(SP entry-value) ")" entry-list = entry *(SP entry) ; list of entries used in unsolicited ; METADATA response getmetadata = "GETMETADATA" SP mailbox SP entries ; empty string for mailbox implies ; server annotation. metadata-resp = "METADATA" SP mailbox SP (entry-values / entry-list) ; empty string for mailbox implies ; server annotation. response-payload =/ metadata-resp ; adds to original IMAP data responses resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number / "TOOMANY" / "NOPRIVATE") ; new response codes for SETMETADATA ; failures setmetadata = "SETMETADATA" SP mailbox SP entry-values ; empty string for mailbox implies ; server annotation. value = nstring / literal8 Daboo Expires October 23, 2008 [Page 13] Internet-Draft IMAP METADATA Extension April 2008 6. IANA Considerations Entry names MUST be specified in a standards track or IESG approved experimental RFC, or fall under the vendor namespace. All entries MUST have either "/public" or "/private" as a prefix. Each entry registration MUST include a content-type that is used to indicate the nature of the annotation value. Where applicable a charset parameter MUST be included with the content-type. 6.1. Entry and Attribute Registration Template To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: [Either "Mailbox" or "Server"] Name: [the name of the entry] Description: [a description of what the entry is for] Content-type: [MIME Content-Type and charset for the entry value] RFC Number: [for entries published as RFCs] Contact: [email and/or physical address to contact for additional information] 6.2. Server Entry Registrations The following templates specify the IANA registrations of annotation entries specified in this document. Daboo Expires October 23, 2008 [Page 14] Internet-Draft IMAP METADATA Extension April 2008 6.2.1. /public/comment To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Server Name: /public/comment Description: Defines a comment or note associated with the server shared with all users of the server. Content-type: text/plain; charset=utf-8 RFC Number: This RFC. Contact: IMAP Extensions 6.2.2. /public/admin To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Server Name: /public/admin Description: Indicates a method for contacting the server administrator. The value MUST be a URI (e.g., a mailto: or tel: URL). This entry is always read-only - clients cannot change it. It is visible to all users of the system. Content-type: text/plain; charset=utf-8 RFC Number: This RFC. Contact: IMAP Extensions 6.3. Mailbox Entry Registrations The following templates specify the IANA registrations of annotation entries specified in this document. Daboo Expires October 23, 2008 [Page 15] Internet-Draft IMAP METADATA Extension April 2008 6.3.1. /public/comment To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Mailbox Name: /public/comment Description: Defines a public comment or note associated with a mailbox. Content-type: text/plain; charset=utf-8 RFC Number: This RFC. Contact: IMAP Extensions 6.3.2. /private/comment To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Mailbox Name: /private/comment Description: Defines a public comment or note associated with a mailbox. Content-type: text/plain; charset=utf-8 RFC Number: This RFC. Contact: IMAP Extensions 7. Security Considerations Annotations whose values are intended to remain private MUST be stored only in entries that have the "/private" prefix on the entry name. Annotations can contain arbitrary sized data. As such servers MUST ensure that size limits are enforced to prevent a user from using up all available space on a server and preventing use by others. Excluding the above issues the METADATA extension does not raise any Daboo Expires October 23, 2008 [Page 16] Internet-Draft IMAP METADATA Extension April 2008 security considerations that are not present in the base IMAP protocol, and these issues are discussed in [RFC3501]. 8. Normative References [I-D.ietf-imapext-i18n] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", draft-ietf-imapext-i18n-15 (work in progress), February 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006. [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007. [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Appendix A. Acknowledgments The ideas expressed in this document are based on the message annotation document that was co-authored by Randall Gellens. The participants of the IMAPext working group made significant contributions to this work. Appendix B. Change History (to be removed prior to publication as an RFC) Changes from -12 to -13: Daboo Expires October 23, 2008 [Page 17] Internet-Draft IMAP METADATA Extension April 2008 1. Major changes to simplify things. 2. Removed dependency on LISTEXT - GETMETADATA now used to get annotations on mailboxes. 3. Changed data model to remove attributes - annotations are now only entry-value pairs. 4. Removed all wildcard behavior on entry names. 5. Cut down the registered annotations to only a few essential ones. Changes from -11 to -12: 1. Allow server annotations to be used without mailbox annotations. 2. Require i;unicode-casemap when COMPARATOR is not present. 3. Use ENABLE to turn on unsolicited responses. 4. Use formal syntax elements from SORT/THREAD extensions to define the values for /sort and /thread entries. 5. Added a comment that use of IDLE is preferred even when /check is true. 6. Use formal syntax element from base spec for the /size value. 7. Removed IANA registration for attributes as we don't expect any more to be defined. 8. Tweaked IANA registration template to be more compact and add RFC Number reference. 9. Some minor re-phrasing was done. 10. Added text about handling of annotations on INBOX when it is renamed. 11. Require a BAD response when an unknown collation is used in LISTEXT selection option. Changes from -10 to -11: 1. Added new paragraph to indicate that values may be read-only or computed. 2. /admin server annotation value now must be a URI. 3. Clarified that SORT and THREAD extensions are not required. 4. Fixed use of undefined entries in some examples. 5. Fixed many examples. 6. Added IANA registration for LIST-EXTENDED items. 7. Added match type and collation identifier to the LIST-EXTENDED selection option. 8. Made support for IMAP-I18N a requirement. 9. Minor text clarifications applied. 10. Remove mailbox list set atomicity requirement. 11. Clarified that annotations can only be set on mailboxes that actually exist. Changes from -09 to -10: 1. Updated to rfc 4466 reference. 2. Reworded data model description. Daboo Expires October 23, 2008 [Page 18] Internet-Draft IMAP METADATA Extension April 2008 3. Reworked LIST-EXTENDED so that responses have metadata items after the mailbox info. 4. Various spelling fixes. Changes from -08 to -09: 1. Remove content-language attribute and reference. 2. Changed capability and command names. 3. Revised abstract. Changes from -07 to -08: 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' for entry/attribute names. 2. Updated examples to match new astring syntax. 3. Changed CAPABILITY name due to incompatible syntax change. 4. Removed content-type attribute. 5. Added Content-type to IANA registration for entries. 6. Removed vendor attributes. 7. Fixed examples in section 3.3 for multi-mailbox and multi-entry cases. 8. Removed wildcards for attributes. 9. Entry/attributes can now only be ASCII. 10. Tied up text wrt storing/fetching. 11. Added Conventions section 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or '.'. 13. Changed to use IMAP ABNF extensions document for some formal syntax items. Changes from -06 to -07: 1. Reworded /checkperiod item. 2. Clarified unsolicited response behavior. Changes from -05 to -06: 1. Removed 'modifiedsince' attribute as there is currently no use for it. 2. Added content-language attribute. 3. Changed access to allow .priv and .shared on any mailbox returned by LIST/LSUB. 4. Added IANA registrations for items defined in this document. 5. Added latest IPR statement. 6. Updated references. Changes from -04 to -05: 1. Fix for valid IMAP state of commands. 2. Fix formatting, ID nits etc. Changes from -03 to -04: Daboo Expires October 23, 2008 [Page 19] Internet-Draft IMAP METADATA Extension April 2008 1. Allow retrieval of shared annotations for READ-ONLY mailbox. 2. Clarification of annotation loss on implicit removal of \Noselect mailboxes. 3. Now requires roll-back of all changes to matching mailboxes if there is a partial failure in SETANNOTATION. Changes from -02 to -03: 1. Reworked entry naming scheme to split out mailbox name and use empty string for server items. Changes from -01 to -02: 1. SETANNOTATION lists use (..). 2. Explicitly state behavior of unsolicited responses. 3. Adding SHOULD behavior for rename/delete of mailboxes. 4. Added statement about supporting annotations on \Noselect mailboxes. 5. Cleaned up formal syntax to use IMAP string type for entry and attributes, with requirements on how the string is formatted. 6. Use of ACAP vendor subtree registry for vendor tokens. Changes from -00 to -01: 1. Multiple entry-att responses are now simply delimited by spaces in line with ANNOTATE spec. Adjusted examples to match. 2. Fixed entry-list formal syntax item to account for unsolicited parenthesized list of entries. 3. Removed setentries formal syntax item for simplicity since its only used once. 4. Removed reference to 'message annotation' in section 5.1. 5. Changed formal syntax to restrict top level entries to /server and /mailbox/{...} only. Re-arranged entry names section to account for this change. 6. Added comment and example for ANNOTATION response to allow servers to return separate responses for each entry if desired. Author's Address Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Email: cyrus@daboo.name URI: http://www.apple.com/ Daboo Expires October 23, 2008 [Page 20] Internet-Draft IMAP METADATA Extension April 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Daboo Expires October 23, 2008 [Page 21]