4Network Working Group C. Daboo
5Request for Comments: 5464 Apple, Inc.
6Category: Standards Track February 2009
9 The IMAP METADATA Extension
13 This document specifies an Internet standards track protocol for the
14 Internet community, and requests discussion and suggestions for
15 improvements. Please refer to the current edition of the "Internet
16 Official Protocol Standards" (STD 1) for the standardization state
17 and status of this protocol. Distribution of this memo is unlimited.
21 The METADATA extension to the Internet Message Access Protocol
22 permits clients and servers to maintain "annotations" or "metadata"
23 on IMAP servers. It is possible to have annotations on a per-mailbox
24 basis or on the server as a whole. For example, this would allow
25 comments about the purpose of a particular mailbox to be "attached"
26 to that mailbox, or a "message of the day" containing server status
27 information to be made available to anyone logging in to the server.
55Daboo Standards Track [Page 1]
57RFC 5464 The IMAP METADATA Extension February 2009
62 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
64 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
66 3.2. Namespace of Entries . . . . . . . . . . . . . . . . . . . 4
67 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5
68 3.3. Private versus Shared and Access Control . . . . . . . . . 6
69 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7
70 4.1. General Considerations . . . . . . . . . . . . . . . . . . 7
71 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 8
72 4.2.1. MAXSIZE GETMETADATA Command Option . . . . . . . . . . 9
73 4.2.2. DEPTH GETMETADATA Command Option . . . . . . . . . . . 10
74 4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 10
75 4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 12
76 4.4.1. METADATA Response with Values . . . . . . . . . . . . 13
77 4.4.2. Unsolicited METADATA Response without Values . . . . . 13
78 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
80 6.1. Entry and Attribute Registration Template . . . . . . . . 16
81 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 16
82 6.2.1. /shared/comment . . . . . . . . . . . . . . . . . . . 17
83 6.2.2. /shared/admin . . . . . . . . . . . . . . . . . . . . 17
84 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 17
85 6.3.1. /shared/comment . . . . . . . . . . . . . . . . . . . 18
86 6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 18
87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
88 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
89 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
111Daboo Standards Track [Page 2]
113RFC 5464 The IMAP METADATA Extension February 2009
1161. Introduction and Overview
118 The goal of the METADATA extension is to provide a means for clients
119 to set and retrieve "annotations" or "metadata" on an IMAP server.
120 The annotations can be associated with specific mailboxes or the
121 server as a whole. The server can choose to support only server
122 annotations or both server and mailbox annotations.
124 A server that supports both server and mailbox annotations indicates
125 the presence of this extension by returning "METADATA" as one of the
126 supported capabilities in the CAPABILITY command response.
128 A server that supports only server annotations indicates the presence
129 of this extension by returning "METADATA-SERVER" as one of the
130 supported capabilities in the CAPABILITY command response.
132 A server that supports unsolicited annotation change responses MUST
133 support the "ENABLE" [RFC5161] extension to allow clients to turn
136 The METADATA extension adds two new commands and one new untagged
137 response to the IMAP base protocol.
139 This extension makes the following changes to the IMAP protocol:
141 o adds a new SETMETADATA command
143 o adds a new GETMETADATA command
145 o adds a new METADATA untagged response
147 o adds a new METADATA response code
149 The rest of this document describes the data model and protocol
150 changes more rigorously.
1522. Conventions Used in This Document
154 In examples, "C:" and "S:" indicate lines sent by the client and
155 server, respectively.
157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
159 document are to be interpreted as described in [RFC2119].
161 Whitespace and line breaks have been added to the examples in this
162 document to promote readability.
167Daboo Standards Track [Page 3]
169RFC 5464 The IMAP METADATA Extension February 2009
176 Mailboxes or the server as a whole may have zero or more annotations
177 associated with them. An annotation contains a uniquely named entry,
178 which has a value. Annotations can be added to mailboxes when a
179 mailbox name is provided as the first argument to the SETMETADATA
180 command, or to the server as a whole when the empty string is
181 provided as the first argument to the command.
183 For example, a general comment being added to a mailbox may have an
184 entry name of "/comment" and a value of "Really useful mailbox".
186 The protocol changes to IMAP described below allow a client to access
187 or change the values of any annotation entry, assuming it has
188 sufficient access rights to do so.
1903.2. Namespace of Entries
192 Each annotation is an entry that has a hierarchical name, with each
193 component of the name separated by a slash ("/"). An entry name MUST
194 NOT contain two consecutive "/" characters and MUST NOT end with a
197 The value of an entry is NIL (has no value), or a string or binary
198 data of zero or more octets. A string MAY contain multiple lines of
199 text. Clients MUST use the CRLF (0x0D 0x0A) character octet sequence
200 to represent line ends in a multi-line string value.
202 Entry names MUST NOT contain asterisk ("*") or percent ("%")
203 characters and MUST NOT contain non-ASCII characters or characters
204 with octet values in the range 0x00 to 0x19. Invalid entry names
205 result in a BAD response in any IMAP command in which they are used.
207 Entry names are case-insensitive.
209 Use of control or punctuation characters in entry names is strongly
212 This specification defines an initial set of entry names available
213 for use with mailbox and server annotations. In addition, an
214 extension mechanism is described to allow additional names to be
215 added for extensibility.
217 The first component in entry names defines the scope of the
218 annotation. Currently, only the prefixes "/private" or "/shared" are
219 defined. These prefixes are used to indicate whether an annotation
223Daboo Standards Track [Page 4]
225RFC 5464 The IMAP METADATA Extension February 2009
228 is stored on a per-user basis ("/private") and not visible to other
229 users, or whether an annotation is shared between authorized users
230 ("/shared") with a single value that can be read and changed by
231 authorized users with appropriate access. See Section 3.3 for
234 Entry names can have any number of components starting at 2, unless
235 they fall under the vendor namespaces (i.e., have a /shared/vendor/
236 <vendor-token> or /private/vendor/<vendor-token> prefix as described
237 below), in which case they have at least 4 components.
241 Entry names MUST be specified in a Standards Track or IESG-approved
242 Experimental RFC, or fall under the vendor namespace. See
243 Section 6.1 for the registration template.
2453.2.1.1. Server Entries
247 These entries are set or retrieved when the mailbox name argument to
248 the new SETMETADATA or GETMETADATA command is the empty string.
252 Defines a comment or note that is associated with the server and
253 that is shared with authorized users of the server.
257 Indicates a method for contacting the server administrator. The
258 value MUST be a URI (e.g., a mailto: or tel: URL). This entry is
259 always read-only -- clients cannot change it. It is visible to
260 authorized users of the system.
262 /shared/vendor/<vendor-token>
264 Defines the top level of shared entries associated with the
265 server, as created by a particular product of some vendor. This
266 entry can be used by vendors to provide server- or client-specific
267 annotations. The vendor-token MUST be registered with IANA, using
268 the Application Configuration Access Protocol (ACAP) [RFC2244]
269 vendor subtree registry.
271 /private/vendor/<vendor-token>
273 Defines the top level of private entries associated with the
274 server, as created by a particular product of some vendor. This
275 entry can be used by vendors to provide server- or client-specific
279Daboo Standards Track [Page 5]
281RFC 5464 The IMAP METADATA Extension February 2009
284 annotations. The vendor-token MUST be registered with IANA, using
285 the ACAP [RFC2244] vendor subtree registry.
2873.2.1.2. Mailbox Entries
289 These entries are set or retrieved when the mailbox name argument to
290 the new SETMETADATA or GETMETADATA command is not the empty string.
294 Defines a shared comment or note associated with a mailbox.
298 Defines a private (per-user) comment or note associated with a
301 /shared/vendor/<vendor-token>
303 Defines the top level of shared entries associated with a specific
304 mailbox, as created by a particular product of some vendor. This
305 entry can be used by vendors to provide client-specific
306 annotations. The vendor-token MUST be registered with IANA, using
307 the ACAP [RFC2244] vendor subtree registry.
309 /private/vendor/<vendor-token>
311 Defines the top level of private entries associated with a
312 specific mailbox, as created by a particular product of some
313 vendor. This entry can be used by vendors to provide client-
314 specific annotations. The vendor-token MUST be registered with
315 IANA, using the ACAP [RFC2244] vendor subtree registry.
3173.3. Private versus Shared and Access Control
319 In the absence of the ACL (Access Control List) extension [RFC4314],
320 users can only set and retrieve private or shared mailbox annotations
321 on a mailbox that exists and is returned to them via a LIST or LSUB
322 command, and on which they have either read or write access to the
323 actual message content of the mailbox (as determined by the READ-ONLY
324 and READ-WRITE response codes as described in Section 5.2 of
327 When the ACL extension [RFC4314] is present, users can only set and
328 retrieve private or shared mailbox annotations on a mailbox on which
329 they have the "l" right and any one of the "r", "s", "w", "i", or "p"
335Daboo Standards Track [Page 6]
337RFC 5464 The IMAP METADATA Extension February 2009
340 If a client attempts to set or retrieve annotations on mailboxes that
341 do not satisfy the conditions above, the server MUST respond with a
344 Users can always retrieve private or shared server annotations if
345 they exist. Servers MAY restrict the creation of private or shared
346 server annotations as appropriate. When restricted, the server MUST
347 return a NO response when the SETMETADATA command is used to try to
348 create a server annotation.
350 If the METADATA extension is present, support for shared annotations
351 is REQUIRED, whilst support for private annotations is OPTIONAL.
352 This recognizes the fact that support for private annotations may
353 introduce significantly more complexity to a server in terms of
354 tracking ownership of the annotations, how quota is determined for
355 users based on their own annotations, etc.
3574. IMAP Protocol Changes
3594.1. General Considerations
361 The new SETMETADATA command and the METADATA response each have a
362 mailbox name argument. An empty string is used for the mailbox name
363 to signify server annotations. A non-empty string is used to signify
364 mailbox annotations attached to the corresponding mailbox.
366 Servers SHOULD ensure that mailbox annotations are automatically
367 moved when the mailbox they refer to is renamed, i.e., the
368 annotations follow the mailbox. This applies to a rename of the
369 INBOX, with the additional behavior that the annotations are copied
370 from the original INBOX to the renamed mailbox, i.e., mailbox
371 annotations are preserved on the INBOX when it is renamed.
373 Servers SHOULD delete annotations for a mailbox when the mailbox is
374 deleted, so that a mailbox created with the same name as a previously
375 existing mailbox does not inherit the old mailbox annotations.
377 Servers SHOULD allow annotations on all 'types' of mailboxes,
378 including ones reporting \Noselect for their LIST response. Servers
379 can implicitly remove \Noselect mailboxes when all child mailboxes
380 are removed, and, at that time any annotations associated with the
381 \Noselect mailbox SHOULD be removed.
383 The server is allowed to impose limitations on the size of any one
384 annotation or the total number of annotations for a single mailbox or
385 for the server as a whole. However, the server MUST accept an
386 annotation data size of at least 1024 bytes, and an annotation count
387 per server or mailbox of at least 10.
391Daboo Standards Track [Page 7]
393RFC 5464 The IMAP METADATA Extension February 2009
396 Some annotations may be "read-only" -- i.e., they are set by the
397 server and cannot be changed by the client. Also, such annotations
398 may be "computed" -- i.e., the value changes based on underlying
399 properties of the mailbox or server. For example, an annotation
400 reporting the total size of all messages in the mailbox would change
401 as messages are added or removed. Or, an annotation containing an
402 IMAP URL for the mailbox would change if the mailbox was renamed.
404 Servers MAY support sending unsolicited responses for use when
405 annotations are changed by some "third-party" (see Section 4.4). In
406 order to do so, servers MUST support the ENABLE command [RFC5161] and
407 MUST only send unsolicited responses if the client used the ENABLE
408 command [RFC5161] extension with the capability string "METADATA" or
409 "METADATA-SERVER" earlier in the session, depending on which of those
410 capabilities is supported by the server.
4124.2. GETMETADATA Command
414 This extension adds the GETMETADATA command. This allows clients to
415 retrieve server or mailbox annotations.
417 This command is only available in authenticated or selected state
420 Arguments: mailbox-name
424 Responses: required METADATA response
426 Result: OK - command completed
427 NO - command failure: can't access annotations on
429 BAD - command unknown or arguments invalid
431 When the mailbox name is the empty string, this command retrieves
432 server annotations. When the mailbox name is not empty, this command
433 retrieves annotations on the specified mailbox.
435 Options MAY be included with this command and are defined below.
439 C: a GETMETADATA "" /shared/comment
440 S: * METADATA "" (/shared/comment "Shared comment")
441 S: a OK GETMETADATA complete
447Daboo Standards Track [Page 8]
449RFC 5464 The IMAP METADATA Extension February 2009
452 In the above example, the contents of the value of the "/shared/
453 comment" server entry is requested by the client and returned by
458 C: a GETMETADATA "INBOX" /private/comment
459 S: * METADATA "INBOX" (/private/comment "My own comment")
460 S: a OK GETMETADATA complete
462 In the above example, the contents of the value of the "/private/
463 comment" mailbox entry for the mailbox "INBOX" is requested by the
464 client and returned by the server.
466 Entry specifiers can be lists of atomic specifiers, so that multiple
467 annotations may be returned in a single GETMETADATA command.
471 C: a GETMETADATA "INBOX" (/shared/comment /private/comment)
472 S: * METADATA "INBOX" (/shared/comment "Shared comment"
473 /private/comment "My own comment")
474 S: a OK GETMETADATA complete
476 In the above example, the values of the two server entries
477 "/shared/comment" and "/private/comment" on the mailbox "INBOX"
478 are requested by the client and returned by the server.
4804.2.1. MAXSIZE GETMETADATA Command Option
482 When the MAXSIZE option is specified with the GETMETADATA command, it
483 restricts which entry values are returned by the server. Only entry
484 values that are less than or equal in octet size to the specified
485 MAXSIZE limit are returned. If there are any entries with values
486 larger than the MAXSIZE limit, the server MUST include the METADATA
487 LONGENTRIES response code in the tagged OK response for the
488 GETMETADATA command. The METADATA LONGENTRIES response code returns
489 the size of the biggest entry value requested by the client that
490 exceeded the MAXSIZE limit.
494 C: a GETMETADATA "INBOX" (MAXSIZE 1024)
495 (/shared/comment /private/comment)
496 S: * METADATA "INBOX" (/private/comment "My own comment")
497 S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete
503Daboo Standards Track [Page 9]
505RFC 5464 The IMAP METADATA Extension February 2009
508 In the above example, the values of the two server entries
509 "/shared/comment" and "/private/comment" on the mailbox "INBOX"
510 are requested by the client, which wants to restrict the size of
511 returned values to 1024 octets. In this case, the "/shared/
512 comment" entry value is 2199 octets and is not returned.
5144.2.2. DEPTH GETMETADATA Command Option
516 When the DEPTH option is specified with the GETMETADATA command, it
517 extends the list of entry values returned by the server. For each
518 entry name specified in the GETMETADATA command, the server returns
519 the value of the specified entry name (if it exists), plus all
520 entries below the entry name up to the specified DEPTH. Three values
521 are allowed for DEPTH:
523 "0" - no entries below the specified entry are returned
524 "1" - only entries immediately below the specified entry are returned
525 "infinity" - all entries below the specified entry are returned
527 Thus, "depth 1" for an entry "/a" will match "/a" as well as its
528 children entries (e.g., "/a/b"), but will not match grandchildren
529 entries (e.g., "/a/b/c").
531 If the DEPTH option is not specified, this is the same as specifying
536 C: a GETMETADATA "INBOX" (DEPTH 1)
537 (/private/filters/values)
538 S: * METADATA "INBOX" (/private/filters/values/small
539 "SMALLER 5000" /private/filters/values/boss
540 "FROM \"boss@example.com\"")
541 S: a OK GETMETADATA complete
543 In the above example, 2 entries below the /private/filters/values
544 entry exist on the mailbox "INBOX": "/private/filters/values/
545 small" and "/private/filters/values/boss".
5474.3. SETMETADATA Command
549 This extension adds the SETMETADATA command. This allows clients to
552 This command is only available in authenticated or selected state
559Daboo Standards Track [Page 10]
561RFC 5464 The IMAP METADATA Extension February 2009
564 Arguments: mailbox-name
567 list of entry, values
569 Responses: no specific responses for this command
571 Result: OK - command completed
572 NO - command failure: can't set annotations,
573 or annotation too big or too many
574 BAD - command unknown or arguments invalid
576 This command sets the specified list of entries by adding or
577 replacing the specified values provided, on the specified existing
578 mailboxes or on the server (if the mailbox argument is the empty
579 string). Clients can use NIL for the value of entries it wants to
580 remove. The server SHOULD NOT return a METADATA response containing
581 the updated annotation data. Clients MUST NOT assume that a METADATA
582 response will be sent, and MUST assume that if the command succeeds,
583 then the annotation has been changed.
585 If the server is unable to set an annotation because the size of its
586 value is too large, the server MUST return a tagged NO response with
587 a "[METADATA MAXSIZE NNN]" response code when NNN is the maximum
588 octet count that it is willing to accept.
590 If the server is unable to set a new annotation because the maximum
591 number of allowed annotations has already been reached, the server
592 MUST return a tagged NO response with a "[METADATA TOOMANY]" response
595 If the server is unable to set a new annotation because it does not
596 support private annotations on one of the specified mailboxes, the
597 server MUST return a tagged NO response with a "[METADATA NOPRIVATE]"
600 When any one annotation fails to be set, resulting in a tagged NO
601 response from the server, then the server MUST NOT change the values
602 for other annotations specified in the SETMETADATA command.
606 C: a SETMETADATA INBOX (/private/comment {33}
608 My new comment across
611 S: a OK SETMETADATA complete
615Daboo Standards Track [Page 11]
617RFC 5464 The IMAP METADATA Extension February 2009
620 In the above example, the entry "/private/comment" for the mailbox
621 "INBOX" is created (if not already present) and the value set to a
626 C: a SETMETADATA INBOX (/private/comment NIL)
627 S: a OK SETMETADATA complete
629 In the above example, the entry "/private/comment" is removed from
632 Multiple entries can be set in a single SETMETADATA command by
633 listing entry-value pairs in the list.
637 C: a SETMETADATA INBOX (/private/comment "My new comment"
638 /shared/comment "This one is for you!")
639 S: a OK SETMETADATA complete
641 In the above example, the entries "/private/comment" and "/shared/
642 comment" for the mailbox "INBOX" are created (if not already
643 present) and the values set as specified.
647 C: a SETMETADATA INBOX (/private/comment "My new comment")
648 S: a NO [METADATA TOOMANY] SETMETADATA failed
650 In the above example, the server is unable to set the requested
651 (new) annotation as it has reached the limit on the number of
652 annotations it can support on the specified mailbox.
6544.4. METADATA Response
656 The METADATA response displays results of a GETMETADATA command, or
657 can be returned as an unsolicited response at any time by the server
658 in response to a change in a server or mailbox annotation.
660 When unsolicited responses are activated by the ENABLE [RFC5161]
661 command for this extension, servers MUST send unsolicited METADATA
662 responses if server or mailbox annotations are changed by a third-
663 party, allowing servers to keep clients updated with changes.
665 Unsolicited METADATA responses MUST only contain entry names, not the
666 values. If the client wants to update any cached values, it must
667 explicitly retrieve those using a GETMETADATA command.
671Daboo Standards Track [Page 12]
673RFC 5464 The IMAP METADATA Extension February 2009
676 The METADATA response can contain multiple entries in a single
677 response, but the server is free to return multiple responses for
678 each entry or group of entries, if it desires.
680 This response is only available in authenticated or selected state
6834.4.1. METADATA Response with Values
685 The response consists of a list of entry-value pairs.
689 C: a GETMETADATA "" /shared/comment
690 S: * METADATA "" (/shared/comment "My comment")
691 S: a OK GETMETADATA complete
693 In the above example, a single entry with its value is returned by
698 C: a GETMETADATA "INBOX" /private/comment /shared/comment
699 S: * METADATA "INBOX" (/private/comment "My comment"
700 /shared/comment "Its sunny outside!")
701 S: a OK GETMETADATA complete
703 In the above example, two entries and their values are returned by
708 C: a GETMETADATA "INBOX" /private/comment /shared/comment
709 S: * METADATA "INBOX" (/private/comment "My comment")
710 S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
711 S: a OK GETMETADATA complete
713 In the above example, the server returns two separate responses
714 for each of the two entries requested.
7164.4.2. Unsolicited METADATA Response without Values
718 The response consists of a list of entries, each of which have
719 changed on the server or mailbox.
727Daboo Standards Track [Page 13]
729RFC 5464 The IMAP METADATA Extension February 2009
733 S: * METADATA "" /shared/comment
734 S: a OK NOOP complete
736 In the above example, the server indicates that the "/shared/
737 comment" server entry has been changed.
742 S: * METADATA "INBOX" /shared/comment /private/comment
743 S: a OK NOOP complete
745 In the above example, the server indicates a change to two mailbox
750 The following syntax specification uses the Augmented Backus-Naur
751 Form (ABNF) notation as specified in [RFC5234].
753 Non-terminals referenced but not defined below are as defined by
754 [RFC3501], with the new definitions in [RFC4466] superseding those in
757 Except as noted otherwise, all alphabetic characters are case-
758 insensitive. The use of upper or lower case characters to define
759 token strings is for editorial clarity only. Implementations MUST
760 accept these strings in a case-insensitive fashion.
762 capability =/ "METADATA" / "METADATA-SERVER"
763 ; defines the capabilities for this extension.
765 command-auth =/ setmetadata / getmetadata
766 ; adds to original IMAP command
769 "(" entry *(SP entry) ")"
773 ; slash-separated path to entry
774 ; MUST NOT contain "*" or "%"
776 entry-value = entry SP value
778 entry-values = "(" entry-value *(SP entry-value) ")"
783Daboo Standards Track [Page 14]
785RFC 5464 The IMAP METADATA Extension February 2009
788 entry-list = entry *(SP entry)
789 ; list of entries used in unsolicited
792 getmetadata = "GETMETADATA" [SP getmetadata-options]
793 SP mailbox SP entries
794 ; empty string for mailbox implies
797 getmetadata-options = "(" getmetadata-option
798 *(SP getmetadata-option) ")"
800 getmetadata-option = tagged-ext-label [SP tagged-ext-val]
801 ; tagged-ext-label and tagged-ext-val
802 ; are defined in [RFC4466].
804 maxsize-opt = "MAXSIZE" SP number
805 ; Used as a getmetadata-option
807 metadata-resp = "METADATA" SP mailbox SP
808 (entry-values / entry-list)
809 ; empty string for mailbox implies
812 response-payload =/ metadata-resp
813 ; adds to original IMAP data responses
815 resp-text-code =/ "METADATA" SP "LONGENTRIES" SP number
816 ; new response codes for GETMETADATA
818 resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number /
819 "TOOMANY" / "NOPRIVATE")
820 ; new response codes for SETMETADATA
823 scope-opt = "DEPTH" SP ("0" / "1" / "infinity")
824 ; Used as a getmetadata-option
826 setmetadata = "SETMETADATA" SP mailbox
828 ; empty string for mailbox implies
831 value = nstring / literal8
839Daboo Standards Track [Page 15]
841RFC 5464 The IMAP METADATA Extension February 2009
8446. IANA Considerations
846 All entries MUST have either "/shared" or "/private" as a prefix.
847 Entry names MUST be specified in a Standards Track or IESG-approved
848 Experimental RFC, or fall under the vendor namespace (i.e., use
849 /shared/vendor/<vendor-token> or /private/vendor/<vendor-token> as
852 Each entry registration MUST include a content-type that is used to
853 indicate the nature of the annotation value. Where applicable, a
854 charset parameter MUST be included with the content-type.
8566.1. Entry and Attribute Registration Template
859 Subject: IMAP METADATA Entry Registration
861 Type: [Either "Mailbox" or "Server"]
863 Name: [the name of the entry]
865 Description: [a description of what the entry is for]
867 Content-type: [MIME Content-Type and charset for the entry value]
869 RFC Number: [for entries published as RFCs]
871 Contact: [email and/or physical address to contact for
872 additional information]
8746.2. Server Entry Registrations
876 The following templates specify the IANA registrations of annotation
877 entries specified in this document.
895Daboo Standards Track [Page 16]
897RFC 5464 The IMAP METADATA Extension February 2009
9006.2.1. /shared/comment
903 Subject: IMAP METADATA Entry Registration
907 Name: /shared/comment
909 Description: Defines a comment or note that is associated
910 with the server and that is shared with
911 authorized users of the server.
913 Content-type: text/plain; charset=utf-8
917 Contact: IMAP Extensions mailto:ietf-imapext@imc.org
922 Subject: IMAP METADATA Entry Registration
928 Description: Indicates a method for contacting the server
929 administrator. The value MUST be a URI (e.g., a
930 mailto: or tel: URL). This entry is always
931 read-only -- clients cannot change it. It is visible
932 to authorized users of the system.
934 Content-type: text/plain; charset=utf-8
938 Contact: IMAP Extensions mailto:ietf-imapext@imc.org
9406.3. Mailbox Entry Registrations
942 The following templates specify the IANA registrations of annotation
943 entries specified in this document.
951Daboo Standards Track [Page 17]
953RFC 5464 The IMAP METADATA Extension February 2009
9566.3.1. /shared/comment
959 Subject: IMAP METADATA Entry Registration
963 Name: /shared/comment
965 Description: Defines a shared comment or note associated with a
968 Content-type: text/plain; charset=utf-8
972 Contact: IMAP Extensions mailto:ietf-imapext@imc.org
9746.3.2. /private/comment
977 Subject: IMAP METADATA Entry Registration
981 Name: /private/comment
983 Description: Defines a private comment or note associated with a
986 Content-type: text/plain; charset=utf-8
990 Contact: IMAP Extensions mailto:ietf-imapext@imc.org
9927. Security Considerations
994 The security considerations in Section 11 of [RFC3501] apply here
995 with respect to protecting annotations from snooping. Servers MAY
996 choose to only support the METADATA and/or METADATA-SERVER extensions
997 after a privacy layer has been negotiated by the client.
999 Annotations can contain arbitrary data of varying size. As such,
1000 servers MUST ensure that size limits are enforced to prevent a user
1001 from using up all available space on a server and preventing use by
1002 others. Clients MUST treat annotation data values as an "untrusted"
1003 source of data as it is possible for it to contain malicious content.
1007Daboo Standards Track [Page 18]
1009RFC 5464 The IMAP METADATA Extension February 2009
1012 Annotations whose values are intended to remain private MUST be
1013 stored only in entries that have the "/private" prefix on the entry
1016 Excluding the above issues, the METADATA extension does not raise any
1017 security considerations that are not present in the base IMAP
1018 protocol, and these issues are discussed in [RFC3501].
10208. Normative References
1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1023 Requirement Levels", BCP 14, RFC 2119, March 1997.
1025 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
1026 Configuration Access Protocol", RFC 2244, November 1997.
1028 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1029 4rev1", RFC 3501, March 2003.
1031 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
1032 RFC 4314, December 2005.
1034 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
1035 ABNF", RFC 4466, April 2006.
1037 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
1038 Extension", RFC 5161, March 2008.
1040 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1041 Specifications: ABNF", STD 68, RFC 5234, January 2008.
1043Appendix A. Acknowledgments
1045 The ideas expressed in this document are based on the message
1046 annotation document that was co-authored by Randall Gellens. The
1047 author would like to thank the following individuals for contributing
1048 their ideas and support for writing this specification: Dave
1049 Cridland, Arnt Gulbrandsen, Dan Karp, Alexey Melnikov, Ken Murchison,
1050 Chris Newman, and Michael Wener.
1063Daboo Standards Track [Page 19]
1065RFC 5464 The IMAP METADATA Extension February 2009
1076 EMail: cyrus@daboo.name
1077 URI: http://www.apple.com/
1119Daboo Standards Track [Page 20]
1121RFC 5464 The IMAP METADATA Extension February 2009
1124Full Copyright Statement
1126 Copyright (C) The IETF Trust (2009).
1128 This document is subject to the rights, licenses and restrictions
1129 contained in BCP 78, and except as set forth therein, the authors
1130 retain all their rights.
1132 This document and the information contained herein are provided on an
1133 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1134 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1135 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1136 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1137 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1138 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1140Intellectual Property
1142 The IETF takes no position regarding the validity or scope of any
1143 Intellectual Property Rights or other rights that might be claimed to
1144 pertain to the implementation or use of the technology described in
1145 this document or the extent to which any license under such rights
1146 might or might not be available; nor does it represent that it has
1147 made any independent effort to identify any such rights. Information
1148 on the procedures with respect to rights in RFC documents can be
1149 found in BCP 78 and BCP 79.
1151 Copies of IPR disclosures made to the IETF Secretariat and any
1152 assurances of licenses to be made available, or the result of an
1153 attempt made to obtain a general license or permission for the use of
1154 such proprietary rights by implementers or users of this
1155 specification can be obtained from the IETF on-line IPR repository at
1156 http://www.ietf.org/ipr.
1158 The IETF invites any interested party to bring to its attention any
1159 copyrights, patents or patent applications, or other proprietary
1160 rights that may cover technology that may be required to implement
1161 this standard. Please address the information to the IETF at
1175Daboo Standards Track [Page 21]