draft-ietf-imapext-annotate-14.txt   draft-ietf-imapext-annotate-15.txt 
IMAP Extensions Working Group C. Daboo IMAP Extensions Working Group C. Daboo
Internet-Draft Internet-Draft
Expires: May 25, 2006 R. Gellens Expires: September 29, 2006 R. Gellens
QUALCOMM Incorporated QUALCOMM Incorporated
November 21, 2005 March 28, 2006
IMAP ANNOTATE Extension IMAP ANNOTATE Extension
draft-ietf-imapext-annotate-14 draft-ietf-imapext-annotate-15
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 25, 2006. This Internet-Draft will expire on September 29, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The ANNOTATE extension to the Internet Message Access Protocol The ANNOTATE extension to the Internet Message Access Protocol
permits clients and servers to maintain "meta data" for messages, or permits clients and servers to maintain "meta data" for messages, or
individual message parts, stored in a mailbox on the server. individual message parts, stored in a mailbox on the server. For
example, this can be used to attach comments and other useful
information to a message. It is also possible to attach annotations
to specific parts of a message, so that, for example, they could be
marked as seen or important, or a comment added.
Change History (to be removed prior to publication as an RFC) Change History (to be removed prior to publication as an RFC)
Changes from -13 to -14: Changes from -14 to -15:
1. Updated to rfc 4314 reference.
2. Removed Content-Language value and reference.
3. Added statement about experimental status.
4. Changed to experimental capability name.
5. Removed ability to sort on size attribute.
6. Expanded abstract.
Changes from -13 to -14:
1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring'
for entry/attribute names. for entry/attribute names.
2. Updated examples to match new astring syntax. 2. Updated examples to match new astring syntax.
3. Now requires explicit use of .priv or .shared in SORT. 3. Now requires explicit use of .priv or .shared in SORT.
4. Removed requirement that 'n' right only be present if 'r' right 4. Removed requirement that 'n' right only be present if 'r' right
is also present. is also present.
5. Changed ANNOTATESIZE response to ANNOTATIONS response. 5. Changed ANNOTATESIZE response to ANNOTATIONS response.
6. Allow servers to indicate that they do not support private 6. Allow servers to indicate that they do not support private
annotations. annotations.
7. Added example for extended SELECT including ANNOTATIONS response 7. Added example for extended SELECT including ANNOTATIONS response
skipping to change at page 5, line 40 skipping to change at page 6, line 4
until the client uses it first. (Open issue as to if needed). until the client uses it first. (Open issue as to if needed).
6. Examples now only use valid entries and attributes. 6. Examples now only use valid entries and attributes.
7. Updated Security Considerations. 7. Updated Security Considerations.
8. Content-Type now defaults to text/plain. 8. Content-Type now defaults to text/plain.
9. Open Issue: Shared vs. private annotations. 9. Open Issue: Shared vs. private annotations.
10. Open issue: Annotation Modtime untagged response or VALIDTIME 10. Open issue: Annotation Modtime untagged response or VALIDTIME
FETCH data. FETCH data.
11. Open issue: Conditional annotation STORE. 11. Open issue: Conditional annotation STORE.
12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in 12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in
CAPABILITY command response. CAPABILITY command response.
13. Prohibition on annotations in lieu of base spec functionality. 13. Prohibition on annotations in lieu of base spec functionality.
14. Specified required ACL rights. 14. Specified required ACL rights.
15. ANNOTATION message data item in APPEND. 15. ANNOTATION message data item in APPEND.
16. ANNOTATION-MODTIME message data item in STATUS. 16. ANNOTATION-MODTIME message data item in STATUS.
17. Replaced ATOM_CHAR with utf8-char. 17. Replaced ATOM_CHAR with utf8-char.
18. Updated other ABNF entries. 18. Updated other ABNF entries.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 7 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 8
2. Conventions Used in This Document . . . . . . . . . . . . . . 7 2. Working Group Note on Status . . . . . . . . . . . . . . . . . 8
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Conventions Used in This Document . . . . . . . . . . . . . . 9
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Namespace of entries and attributes . . . . . . . . . . . 8 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 9 4.2. Namespace of entries and attributes . . . . . . . . . . . 9
3.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 10 4.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 10
3.3. Private versus Shared . . . . . . . . . . . . . . . . . . 11 4.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 12
3.4. Access Control . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Private versus Shared . . . . . . . . . . . . . . . . . . 12
3.5. Access to Standard IMAP Flags and Keywords . . . . . . . . 15 4.4. Access Control . . . . . . . . . . . . . . . . . . . . . . 13
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 15 4.5. Access to Standard IMAP Flags and Keywords . . . . . . . . 16
4.1. General Considerations . . . . . . . . . . . . . . . . . . 15 5. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 16
4.2. ANNOTATE parameter with the SELECT/EXAMINE commands . . . 16 5.1. General Considerations . . . . . . . . . . . . . . . . . . 16
4.3. ANNOTATION Message Data Item in FETCH Command . . . . . . 16 5.2. ANNOTATE parameter with the SELECT/EXAMINE commands . . . 17
4.4. ANNOTATION Message Data Item in FETCH Response . . . . . . 18 5.3. ANNOTATION Message Data Item in FETCH Command . . . . . . 17
4.5. ANNOTATION Message Data Item in STORE . . . . . . . . . . 20 5.4. ANNOTATION Message Data Item in FETCH Response . . . . . . 19
4.6. ANNOTATION interaction with COPY . . . . . . . . . . . . . 21 5.5. ANNOTATION Message Data Item in STORE . . . . . . . . . . 21
4.7. ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22 5.6. ANNOTATION interaction with COPY . . . . . . . . . . . . . 22
4.8. ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 22 5.7. ANNOTATION Message Data Item in APPEND . . . . . . . . . . 23
4.9. ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 23 5.8. ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 23
4.10. New ACL Rights . . . . . . . . . . . . . . . . . . . . . . 24 5.9. ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 24
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 24 5.10. New ACL Rights . . . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Entry and Attribute Registration Template . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.2. Entry Registrations . . . . . . . . . . . . . . . . . . . 27 7.1. Entry and Attribute Registration Template . . . . . . . . 27
6.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 27 7.2. Entry Registrations . . . . . . . . . . . . . . . . . . . 28
6.2.2. /flags . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.3. /altsubject . . . . . . . . . . . . . . . . . . . . . 28 7.2.2. /flags . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4. /<section-part>/comment . . . . . . . . . . . . . . . 28 7.2.3. /altsubject . . . . . . . . . . . . . . . . . . . . . 29
6.2.5. /<section-part>/flags/seen . . . . . . . . . . . . . . 29 7.2.4. /<section-part>/comment . . . . . . . . . . . . . . . 29
6.2.6. /<section-part>/flags/answered . . . . . . . . . . . . 29 7.2.5. /<section-part>/flags/seen . . . . . . . . . . . . . . 30
6.2.7. /<section-part>/flags/flagged . . . . . . . . . . . . 30 7.2.6. /<section-part>/flags/answered . . . . . . . . . . . . 30
6.2.8. /<section-part>/flags/forwarded . . . . . . . . . . . 30 7.2.7. /<section-part>/flags/flagged . . . . . . . . . . . . 31
6.3. Attribute Registrations . . . . . . . . . . . . . . . . . 30 7.2.8. /<section-part>/flags/forwarded . . . . . . . . . . . 31
6.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 31 7.3. Attribute Registrations . . . . . . . . . . . . . . . . . 31
6.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3.3. content-language . . . . . . . . . . . . . . . . . . . 32 7.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. Internationalization Considerations . . . . . . . . . . . . . 32 8. Internationalization Considerations . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction and Overview 1. Introduction and Overview
The ANNOTATE extension is present in any IMAP [RFC3501] The ANNOTATE extension is present in any IMAP [RFC3501]
implementation which returns "ANNOTATE" as one of the supported implementation which returns "ANNOTATE-EXPERIMENT-1" as one of the
capabilities in the CAPABILITY response. supported capabilities in the CAPABILITY response.
This extension makes the following changes to the IMAP protocol: This extension makes the following changes to the IMAP protocol:
a. adds a new ANNOTATION message data item for use in FETCH a. adds a new ANNOTATION message data item for use in FETCH
b. adds a new ANNOTATION message data item for use in STORE b. adds a new ANNOTATION message data item for use in STORE
c. adds a new ANNOTATION search criterion for use in SEARCH c. adds a new ANNOTATION search criterion for use in SEARCH
d. adds a new ANNOTATION sort key for use in SORT extension d. adds a new ANNOTATION sort key for use in SORT extension
e. adds a new ANNOTATION data item for use in APPEND e. adds a new ANNOTATION data item for use in APPEND
f. adds a new requirement on the COPY command f. adds a new requirement on the COPY command
g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE
commands commands
h. adds two new response codes to indicate store failures of h. adds two new response codes to indicate store failures of
annotations. annotations.
i. adds a new untagged response code for the SELECT or EXAMINE i. adds a new untagged response code for the SELECT or EXAMINE
commands to indicate the maximum size. commands to indicate the maximum size.
j. adds a new ACL "bit" for use with the ACL extensions [RFC2086] j. adds a new ACL "bit" for use with the ACL extensions [RFC2086]
and [I-D.ietf-imapext-2086upd] . and [RFC4314] .
The data model used for the storage of annotations is based on that The data model used for the storage of annotations is based on that
of the Application Configuration Access Protocol [RFC2244]. Note of the Application Configuration Access Protocol [RFC2244]. Note
that there is no inheritance in annotations. that there is no inheritance in annotations.
If a server supports annotations, then it MUST store all annotation If a server supports annotations, then it MUST store all annotation
data permanently, i.e. there is no concept of "session only" data permanently, i.e. there is no concept of "session only"
annotations that would correspond to the behaviour of "session" flags annotations that would correspond to the behaviour of "session" flags
as defined in the IMAP base specification. as defined in the IMAP base specification.
In order to provide optimum support for a disconnected client (one In order to provide optimum support for a disconnected client (one
that needs to synchronise annotations for use when offline), servers that needs to synchronise annotations for use when offline), servers
SHOULD also support the Conditional STORE [I-D.ietf-imapext- SHOULD also support the Conditional STORE [I-D.ietf-imapext-
condstore] extension. condstore] extension.
The rest of this document describes the data model and protocol The rest of this document describes the data model and protocol
changes more rigorously. changes more rigorously.
2. Conventions Used in This Document 2. Working Group Note on Status
The IMAP Extensions Working Group, which produced this specification,
has felt it important to first gain implementation experience with
this specification before submitting it as a 'proposed standard' for
more general deployment, and therefore suggests that it be published
as Experimental. As such the Working Group strongly encourages
implementers to implement this specification as-is and provide their
valuable feedback on any problems or issues found when doing that or
when attempting to interoperate with other products.
Implementers should be aware that this specification may change in an
incompatible manner when going to 'proposed standard' status.
However, any incompatible changes will result in a new capability
name being used to prevent problems with any deployments of the
experimental extension.
3. Conventions Used in This Document
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Data Model 4. Data Model
3.1. Overview 4.1. Overview
The data model used in ANNOTATE is that of a uniquely named entry The data model used in ANNOTATE is that of a uniquely named entry
which contains a set of standard attributes. A single coherent unit which contains a set of standard attributes. A single coherent unit
of "meta data" for a message is stored as a single entry, made up of of "meta data" for a message is stored as a single entry, made up of
several attributes. several attributes.
For example, a comment annotation added to a message has an entry For example, a comment annotation added to a message has an entry
name of "/comment". This entry is composed of several attributes name of "/comment". This entry is composed of several attributes
such as "value", "size", etc. which contain the properties and data such as "value", "size", etc. which contain the properties and data
of the entry. of the entry.
The protocol changes to IMAP described below allow a client to access The protocol changes to IMAP described below allow a client to access
or change the values of any attributes in any entries in a message or change the values of any attributes in any entries in a message
annotation, assuming it has sufficient access rights to do so (see annotation, assuming it has sufficient access rights to do so (see
Section 3.4 for specifics). Section 4.4 for specifics).
3.2. Namespace of entries and attributes 4.2. Namespace of entries and attributes
Each message annotation is made up of a set of entries. Each entry Each message annotation is made up of a set of entries. Each entry
has a hierarchical name, with each component of the name separated by has a hierarchical name, with each component of the name separated by
a slash ("/"). An entry name MUST NOT contain two consecutive "/" a slash ("/"). An entry name MUST NOT contain two consecutive "/"
characters and MUST NOT end with a "/" character. characters and MUST NOT end with a "/" character.
Each entry is made up of a set of attributes. Each attribute has a Each entry is made up of a set of attributes. Each attribute has a
hierarchical name, with each component of the name separated by a hierarchical name, with each component of the name separated by a
period ("."). An attribute name MUST NOT contain two consecutive "." period ("."). An attribute name MUST NOT contain two consecutive "."
characters and MUST NOT end with a "." character. characters and MUST NOT end with a "." character.
skipping to change at page 8, line 47 skipping to change at page 10, line 18
The value of an attribute is "NIL" (has no value), or is a string of The value of an attribute is "NIL" (has no value), or is a string of
zero or more octets. zero or more octets.
Entry and attribute names MUST NOT contain asterisk ("*") or percent Entry and attribute names MUST NOT contain asterisk ("*") or percent
("%") characters and MUST NOT contain non-ASCII characters or the ("%") characters and MUST NOT contain non-ASCII characters or the
NULL octet. Invalid entry or attribute names result in a BAD NULL octet. Invalid entry or attribute names result in a BAD
response in any IMAP commands where they are used. response in any IMAP commands where they are used.
Attribute names MUST NOT contain any hierarchical components with the Attribute names MUST NOT contain any hierarchical components with the
names "priv" or "shared" as those have special meaning (see names "priv" or "shared" as those have special meaning (see
Section 3.3. Section 4.3).
Entry and attribute names are case-sensitive. Entry and attribute names are case-sensitive.
Use of control or punctuation characters in entry and attribute names Use of control or punctuation characters in entry and attribute names
is strongly discouraged. is strongly discouraged.
This specification defines an initial set of entry and attribute This specification defines an initial set of entry and attribute
names available for use in message annotations. In addition, an names available for use in message annotations. In addition, an
extension mechanism is described to allow additional names to be extension mechanism is described to allow additional names to be
added as needed. added as needed.
3.2.1. Entry Names 4.2.1. Entry Names
Entry names MUST be specified in a standards track or IESG approved Entry names MUST be specified in a standards track or IESG approved
experimental RFC, or fall under the vendor namespace. See experimental RFC, or fall under the vendor namespace. See
Section 6.1 for the registration template. Section 7.1 for the registration template.
/ /
Defines the top-level of entries associated with an entire Defines the top-level of entries associated with an entire
message. This entry itself does not contain any attributes. All message. This entry itself does not contain any attributes. All
entries that start with a numeric character ("0" - "9") refer to entries that start with a numeric character ("0" - "9") refer to
an annotation on a specific body part. All other entries are for an annotation on a specific body part. All other entries are for
annotations on the entire message. annotations on the entire message.
/comment /comment
Defines a comment or note associated with an entire message. Defines a comment or note associated with an entire message.
skipping to change at page 10, line 31 skipping to change at page 12, line 5
attribute of each of the entries described above must be either attribute of each of the entries described above must be either
"1", "0" or "NIL". "1" corresponds to the flag being set. "1", "0" or "NIL". "1" corresponds to the flag being set.
/<section-part>/vendor/<vendor-token> /<section-part>/vendor/<vendor-token>
Defines the top-level of entries associated with a specific body Defines the top-level of entries associated with a specific body
part of a message as created by a particular product of some part of a message as created by a particular product of some
vendor. This entry can be used by vendors to provide client vendor. This entry can be used by vendors to provide client
specific annotations. The vendor-token MUST be registered with specific annotations. The vendor-token MUST be registered with
IANA. IANA.
3.2.2. Attribute Names 4.2.2. Attribute Names
Attribute names MUST be specified in a standards track or IESG Attribute names MUST be specified in a standards track or IESG
approved experimental RFC. See Section 6.1 for the registration approved experimental RFC. See Section 7.1 for the registration
template. template.
All attribute names implicitly have a ".priv" and a ".shared" suffix All attribute names implicitly have a ".priv" and a ".shared" suffix
which maps to private and shared versions of the entry. Searching or which maps to private and shared versions of the entry. Searching or
fetching without using either suffix includes both. The client MUST fetching without using either suffix includes both. The client MUST
specify either a ".priv" or ".shared" suffix when storing an specify either a ".priv" or ".shared" suffix when storing an
annotation. annotation or sorting on annotations.
value value
A string or binary data representing the value of the annotation. A string or binary data representing the value of the annotation.
To delete an annotation, the client can store "NIL" into the To delete an annotation, the client can store "NIL" into the
value. The content represented by the string is determined by the value. The content represented by the string is determined by the
Content-type used to register the entry (see Section 6.1 for entry content-type used to register the entry (see Section 7.1 for entry
registration templates). Where applicable, the registered registration templates). Where applicable, the registered
content-type MUST include a charset parameter. Text values SHOULD content-type MUST include a charset parameter. Text values SHOULD
use the utf-8 [RFC3629] character set. use the utf-8 [RFC3629] character set.
Note that binary data (data which may contain the NULL octet) is Note that binary data (data which may contain the NULL octet) is
allowed (e.g. for storing images etc), and this extension uses the allowed (e.g. for storing images etc), and this extension uses the
"literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow "literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow
such data to be written to or read from the server. such data to be written to or read from the server.
size size
The size of the value, in octets. Set automatically by the The size of the value, in octets. Set automatically by the
server, read-only to clients. server, read-only to clients.
content-language 4.3. Private versus Shared
Indicates the language used for the value. This follows the
format described in [RFC3282]. Clients SHOULD set this value when
storing an annotation that uses text that can be presented to the
user. It is not required for enumerated or numeric values such as
flags etc. If a value is being set, clients MUST ensure that it
accurately reflects the content stored in the value attribute.
Servers MUST ensure that the "content-language" attribute value is
kept in synchronization with the "value" attribute. To ensure
that, the server MUST remove any "content-language" attribute
value when the client STOREs a "value" attribute without also
including a "content-language" attribute in the same STORE
command.
3.3. Private versus Shared
Some IMAP mailboxes are private, accessible only to the owning user. Some IMAP mailboxes are private, accessible only to the owning user.
Other mailboxes are not, either because the owner has set an ACL Other mailboxes are not, either because the owner has set an ACL
[I-D.ietf-imapext-2086upd] which permits access by other users, or [RFC4314] which permits access by other users, or because it is a
because it is a shared mailbox. shared mailbox.
This raises the issue of shared versus private annotations. This raises the issue of shared versus private annotations.
If all annotations are private, it is impossible to set annotations If all annotations are private, it is impossible to set annotations
in a shared or otherwise non-private mailbox that are visible to in a shared or otherwise non-private mailbox that are visible to
other users. This eliminates what could be a useful aspect of other users. This eliminates what could be a useful aspect of
annotations in a shared environment. An example of such use is a annotations in a shared environment. An example of such use is a
shared IMAP folder containing bug reports. Engineers may want to use shared IMAP folder containing bug reports. Engineers may want to use
annotations to add information to existing messages, indicate annotations to add information to existing messages, indicate
assignments, status, etc. This use requires shared annotations. assignments, status, etc. This use requires shared annotations.
skipping to change at page 12, line 26 skipping to change at page 13, line 32
If the ANNOTATE extension is present, support for shared annotations If the ANNOTATE extension is present, support for shared annotations
in servers is REQUIRED, whilst support for private annotations in in servers is REQUIRED, whilst support for private annotations in
servers is OPTIONAL. This recognises the fact that support for servers is OPTIONAL. This recognises the fact that support for
private annotations may introduce significantly more complexity to a private annotations may introduce significantly more complexity to a
server in terms of tracking ownership of the annotations, how quota server in terms of tracking ownership of the annotations, how quota
is determined for users based on their own annotations etc. Clients is determined for users based on their own annotations etc. Clients
that support the ANNOTATE extension MUST handle both shared and that support the ANNOTATE extension MUST handle both shared and
private annotations. private annotations.
3.4. Access Control 4.4. Access Control
A user needs to have appropriate rights in order to read or write A user needs to have appropriate rights in order to read or write
".priv" or ".shared" annotation values. How those rights are ".priv" or ".shared" annotation values. How those rights are
calculated depends on whether the ACL [RFC2086] extension or its calculated depends on whether the ACL [RFC2086] extension or its
update [I-D.ietf-imapext-2086upd] is present or not. If a client update [RFC4314] is present or not. If a client attempts to store or
attempts to store or fetch an annotation to which they do not have fetch an annotation to which they do not have the appropriate rights,
the appropriate rights, the server MUST respond with a NO response. the server MUST respond with a NO response.
When the ACL extension is not present, access to annotation values is When the ACL extension is not present, access to annotation values is
governed by the nature of the selected state. In particular whether governed by the nature of the selected state. In particular whether
the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE
mode. mode.
When the ACL extension is present, the server MUST recognise the new When the ACL extension is present, the server MUST recognise the new
ACL right "n", in addition to the ones defined by the ACL extension ACL right "n", in addition to the ones defined by the ACL extension
itself. itself.
skipping to change at page 13, line 9 skipping to change at page 14, line 14
allowed, when it is off, access to ".priv" annotations is disallowed. allowed, when it is off, access to ".priv" annotations is disallowed.
The "r" right controls only the read access for ".shared" annotation The "r" right controls only the read access for ".shared" annotation
values. When it is on, ".shared" annotations can be read, when it is values. When it is on, ".shared" annotations can be read, when it is
off, ".shared" annotations cannot be read. off, ".shared" annotations cannot be read.
The "n" right controls only the write access for ".shared" annotation The "n" right controls only the write access for ".shared" annotation
values. When it is on, ".shared" annotations can be changed or values. When it is on, ".shared" annotations can be changed or
created through either a STORE or APPEND command, when it is off, created through either a STORE or APPEND command, when it is off,
".shared" annotations cannot be changed or created. The "n" right ".shared" annotations cannot be changed or created. The "n" right
constitutes a "shared flag right" as defined in [I-D.ietf-imapext- constitutes a "shared flag right" as defined in [RFC4314] Section
2086upd] Section 6.2. 6.2.
A summary of all the access control restrictions is tabulated below A summary of all the access control restrictions is tabulated below
+---------------+---------------+-----------------------------------+ +---------------+---------------+-----------------------------------+
| Server Type | Action on | Type of mailbox | | Server Type | Action on | Type of mailbox |
| | annotation | | | | annotation | |
+===============+===============+===================================+ +===============+===============+===================================+
| | | | | | | |
| | read .priv | Any mailbox that can be SELECTED | | | read .priv | Any mailbox that can be SELECTED |
| | values | or EXAMINED. | | | values | or EXAMINED. |
| | | | | | | |
skipping to change at page 15, line 5 skipping to change at page 16, line 5
| | read .shared | Any mailbox with the "r" | | | read .shared | Any mailbox with the "r" |
| | values | ACL right. | | | values | ACL right. |
| | | | | | | |
| +---------------+-----------------------------------+ | +---------------+-----------------------------------+
| | | | | | | |
| | write .shared | Any mailbox with the "n" | | | write .shared | Any mailbox with the "n" |
| | values | ACL right. | | | values | ACL right. |
| | | | | | | |
+---------------+---------------+-----------------------------------+ +---------------+---------------+-----------------------------------+
3.5. Access to Standard IMAP Flags and Keywords 4.5. Access to Standard IMAP Flags and Keywords
Due to ambiguity of how private and shared values would map to the Due to ambiguity of how private and shared values would map to the
base IMAP flag and keyword values, the ANNOTATE extension does not base IMAP flag and keyword values, the ANNOTATE extension does not
expose IMAP flags or keywords as entries. However, the /flags expose IMAP flags or keywords as entries. However, the /flags
annotation entry is reserved for future use and MUST NOT be used by annotation entry is reserved for future use and MUST NOT be used by
clients or servers supporting this extension. clients or servers supporting this extension.
Clients that need to implement shared and private "flags" can create Clients that need to implement shared and private "flags" can create
their own annotation entries for those, completely bypassing the base their own annotation entries for those, completely bypassing the base
IMAP flag/keyword behaviour. IMAP flag/keyword behaviour.
4. IMAP Protocol Changes 5. IMAP Protocol Changes
4.1. General Considerations 5.1. General Considerations
Servers may be able to offer only a limited level of support for Servers may be able to offer only a limited level of support for
annotations in mailboxes, and it is useful for clients to be able to annotations in mailboxes, and it is useful for clients to be able to
know what level of support is available. Servers MUST return an know what level of support is available. Servers MUST return an
ANNOTATIONS response during the SELECT or EXAMINE command for a ANNOTATIONS response during the SELECT or EXAMINE command for a
mailbox to indicate the level of support. Possible response codes mailbox to indicate the level of support. Possible response codes
used with the ANNOTATIONS response are: used with the ANNOTATIONS response are:
"NONE" - this indicates that the mailbox being selected does not "NONE" - this indicates that the mailbox being selected does not
support annotations at all. Clients MUST NOT attempt to use support annotations at all. Clients MUST NOT attempt to use
skipping to change at page 16, line 10 skipping to change at page 17, line 10
server MUST indicate the maximum size for an annotation value by server MUST indicate the maximum size for an annotation value by
providing the maximum size value in the response code. Clients providing the maximum size value in the response code. Clients
MUST NOT store annotation values of a size greater than the amount MUST NOT store annotation values of a size greater than the amount
indicated by the server. Servers MUST accept a minimum annotation indicated by the server. Servers MUST accept a minimum annotation
data size of at least 1024 bytes if annotations can be written. data size of at least 1024 bytes if annotations can be written.
In addition the server MAY limit the total number of annotations for In addition the server MAY limit the total number of annotations for
a single message. However, the server MUST provide a minimum a single message. However, the server MUST provide a minimum
annotation count per message of at least 10. annotation count per message of at least 10.
4.2. ANNOTATE parameter with the SELECT/EXAMINE commands 5.2. ANNOTATE parameter with the SELECT/EXAMINE commands
The ANNOTATE extension defines a single optional SELECT parameter The ANNOTATE extension defines a single optional SELECT parameter
[I-D.melnikov-imap-ext-abnf] "ANNOTATE", which is used to turn on [I-D.melnikov-imap-ext-abnf] "ANNOTATE", which is used to turn on
unsolicited responses for annotations as described in Section 4.4. unsolicited responses for annotations as described in Section 5.4.
This optional parameter results in a per-mailbox state change, i.e. This optional parameter results in a per-mailbox state change, i.e.
it must be used in each SELECT/EXAMINE command in order to be it must be used in each SELECT/EXAMINE command in order to be
effective, irrespective of whether it was used in a previous SELECT/ effective, irrespective of whether it was used in a previous SELECT/
EXAMINE during the same session. EXAMINE during the same session.
Example: Example:
C: a SELECT INBOX ANNOTATE C: a SELECT INBOX (ANNOTATE)
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] \Deleted \Seen \*)]
S: * 10268 EXISTS S: * 10268 EXISTS
S: * 1 RECENT S: * 1 RECENT
S: * OK [UNSEEN 10268] S: * OK [UNSEEN 10268]
S: * OK [UIDVALIDITY 890061587] S: * OK [UIDVALIDITY 890061587]
S: * OK [UIDNEXT 34643] S: * OK [UIDNEXT 34643]
S: * OK [ANNOTATIONS 20480 NOPRIVATE] S: * OK [ANNOTATIONS 20480 NOPRIVATE]
S: a OK [READ-WRITE] Completed S: a OK [READ-WRITE] Completed
In the above example, a SELECT command with the ANNOTATE parameter In the above example, a SELECT command with the ANNOTATE parameter
is issued. The response from the server includes the required is issued. The response from the server includes the required
ANNOTATIONS response that indicates that the server supports ANNOTATIONS response that indicates that the server supports
annotations up to a maximum size of 20480 bytes and does not annotations up to a maximum size of 20480 bytes and does not
support private annotations (only shared). support private annotations (only shared).
4.3. ANNOTATION Message Data Item in FETCH Command 5.3. ANNOTATION Message Data Item in FETCH Command
This extension adds an ANNOTATION message data item to the FETCH This extension adds an ANNOTATION message data item to the FETCH
command. This allows clients to retrieve annotations for a range of command. This allows clients to retrieve annotations for a range of
messages in the currently selected mailbox. messages in the currently selected mailbox.
ANNOTATION <entry-specifier> <attribute-specifier> ANNOTATION <entry-specifier> <attribute-specifier>
The ANNOTATION message data item, when used by the client in the The ANNOTATION message data item, when used by the client in the
FETCH command, takes an entry specifier and an attribute FETCH command, takes an entry specifier and an attribute
specifier. specifier.
skipping to change at page 18, line 25 skipping to change at page 19, line 25
((/comment /altsubject) value.priv)) ((/comment /altsubject) value.priv))
S: * 1 FETCH (ANNOTATION S: * 1 FETCH (ANNOTATION
(/comment (value.priv "What a chowder-head") (/comment (value.priv "What a chowder-head")
/altsubject (value.priv "How to crush beer cans"))) /altsubject (value.priv "How to crush beer cans")))
S: a OK Fetch complete S: a OK Fetch complete
In the above example, the contents of the private "value" In the above example, the contents of the private "value"
attributes for the two entries "/comment" and "/altsubject" are attributes for the two entries "/comment" and "/altsubject" are
requested by the client and returned by the server. requested by the client and returned by the server.
4.4. ANNOTATION Message Data Item in FETCH Response 5.4. ANNOTATION Message Data Item in FETCH Response
The ANNOTATION message data item in the FETCH response displays The ANNOTATION message data item in the FETCH response displays
information about annotations in a message. information about annotations in a message.
ANNOTATION parenthesised list ANNOTATION parenthesised list
The response consists of a list of entries, each of which has a The response consists of a list of entries, each of which has a
list of attribute-value pairs. list of attribute-value pairs.
Example: Example:
skipping to change at page 20, line 9 skipping to change at page 21, line 9
C: a STORE 1 +FLAGS (\Seen) C: a STORE 1 +FLAGS (\Seen)
S: * 1 FETCH (FLAGS (\Seen)) S: * 1 FETCH (FLAGS (\Seen))
ANNOTATION (/comment)) ANNOTATION (/comment))
S: a OK STORE complete S: a OK STORE complete
In the above example, an unsolicited ANNOTATION response is In the above example, an unsolicited ANNOTATION response is
returned during a STORE command. The unsolicited response returned during a STORE command. The unsolicited response
contains only the entry name of the annotation that changed, and contains only the entry name of the annotation that changed, and
not its value. not its value.
4.5. ANNOTATION Message Data Item in STORE 5.5. ANNOTATION Message Data Item in STORE
ANNOTATION <parenthesised entry-attribute-value list> ANNOTATION <parenthesised entry-attribute-value list>
Sets the specified list of entries by adding or replacing the Sets the specified list of entries by adding or replacing the
specified attributes with the values provided. Clients can use specified attributes with the values provided. Clients can use
"NIL" for values of attributes it wants to remove from entries. "NIL" for values of attributes it wants to remove from entries.
The ANNOTATION message data item used with the STORE command has an The ANNOTATION message data item used with the STORE command has an
implicit ".SILENT" behaviour. This means the server does not implicit ".SILENT" behaviour. This means the server does not
generate an untagged FETCH in response to the STORE command and generate an untagged FETCH in response to the STORE command and
skipping to change at page 21, line 35 skipping to change at page 22, line 35
C: a STORE 1 ANNOTATION (/comment C: a STORE 1 ANNOTATION (/comment
(value.priv "My new comment" (value.priv "My new comment"
value.shared "foo's bar")) value.shared "foo's bar"))
S: a OK Store complete S: a OK Store complete
In the above example, the entry "/comment" is created (if not already In the above example, the entry "/comment" is created (if not already
present) and the private and shared "value" attributes are created if present) and the private and shared "value" attributes are created if
not already present, or replaced if they exist. not already present, or replaced if they exist.
4.6. ANNOTATION interaction with COPY 5.6. ANNOTATION interaction with COPY
The COPY command can be used to move messages from one mailbox to The COPY command can be used to move messages from one mailbox to
another on the same server. Servers that support the ANNOTATION another on the same server. Servers that support the ANNOTATION
extension MUST, for each message being copied, copy all ".priv" extension MUST, for each message being copied, copy all ".priv"
annotation data for the current user only, and all ".shared" annotation data for the current user only, and all ".shared"
annotation data along with the message to the new mailbox. The only annotation data along with the message to the new mailbox. The only
exceptions to this are if the destination mailbox permissions are exceptions to this are if the destination mailbox permissions are
such that either the ".priv" or ".shared" annotations are not such that either the ".priv" or ".shared" annotations are not
allowed, or if the destination mailbox is of a type that does not allowed, or if the destination mailbox is of a type that does not
support annotations or does not support storing of annotations (a support annotations or does not support storing of annotations (a
mailbox that returns a "NONE" or "READ-ONLY" response code in its mailbox that returns a "NONE" or "READ-ONLY" response code in its
ANNOTATIONS response), or if the destination mailbox cannot support ANNOTATIONS response), or if the destination mailbox cannot support
the size of a annotation because it exceeds the ANNOTATIONS value. the size of a annotation because it exceeds the ANNOTATIONS value.
Servers MUST NOT copy ".priv" annotation data for users other than Servers MUST NOT copy ".priv" annotation data for users other than
the current user. the current user.
4.7. ANNOTATION Message Data Item in APPEND 5.7. ANNOTATION Message Data Item in APPEND
ANNOTATION <parenthesised entry-attribute-value list> ANNOTATION <parenthesised entry-attribute-value list>
Sets the specified list of entries and attributes in the resulting Sets the specified list of entries and attributes in the resulting
message. message.
The APPEND command can include annotations for the message being The APPEND command can include annotations for the message being
appended via the addition of a new append data item [I-D.melnikov- appended via the addition of a new append data item [I-D.melnikov-
imap-ext-abnf]. The new data item can also be used with the multi- imap-ext-abnf]. The new data item can also be used with the multi-
append [RFC3502] extension that allows multiple messages to be append [RFC3502] extension that allows multiple messages to be
skipping to change at page 22, line 32 skipping to change at page 23, line 32
S: + Ready for literal data S: + Ready for literal data
C: MIME-Version: 1.0 C: MIME-Version: 1.0
... ...
C: C:
S: a OK APPEND completed S: a OK APPEND completed
In the above example, a comment with a private value is added to a In the above example, a comment with a private value is added to a
new message appended to the mailbox. The ellipsis represents the new message appended to the mailbox. The ellipsis represents the
bulk of the message. bulk of the message.
4.8. ANNOTATION Criterion in SEARCH 5.8. ANNOTATION Criterion in SEARCH
ANNOTATION <entry-name> <attribute-name> <value> ANNOTATION <entry-name> <attribute-name> <value>
The ANNOTATION criterion for the SEARCH command allows a client to The ANNOTATION criterion for the SEARCH command allows a client to
search for a specified string in the value of an annotation entry of search for a specified string in the value of an annotation entry of
a message. a message.
Messages that have annotations with entries matching <entry-name> and Messages that have annotations with entries matching <entry-name> and
attributes matching <attribute-name> and the specified string <value> attributes matching <attribute-name> and the specified string <value>
in their values are returned in the SEARCH results. The "*" in their values are returned in the SEARCH results. The "*"
skipping to change at page 23, line 24 skipping to change at page 24, line 24
Example: Example:
C: a SEARCH ANNOTATION * value.priv "IMAP4" C: a SEARCH ANNOTATION * value.priv "IMAP4"
S: * SEARCH 1 2 3 5 8 13 21 34 S: * SEARCH 1 2 3 5 8 13 21 34
S: a OK Search complete S: a OK Search complete
In the above example, the message numbers of any messages In the above example, the message numbers of any messages
containing the string "IMAP4" in the private "value" attribute of containing the string "IMAP4" in the private "value" attribute of
any entry are returned in the search results. any entry are returned in the search results.
4.9. ANNOTATION Key in SORT 5.9. ANNOTATION Key in SORT
ANNOTATION <entry-name> <attribute-name> ANNOTATION <entry-name> <attribute-name>
The ANNOTATION criterion for the SORT command [I-D.ietf-imapext-sort] The ANNOTATION criterion for the SORT command [I-D.ietf-imapext-sort]
instructs the server to return the message numbers or UIDs of a instructs the server to return the message numbers or UIDs of a
mailbox, sorted using the values of the specified annotations. The mailbox, sorted using the values of the specified annotations. The
ANNOTATION criterion is available if the server returns both ANNOTATE ANNOTATION criterion is available if the server returns both
and SORT as supported capabilities in the CAPABILITY command ANNOTATE-EXPERIMENT-1 and SORT as supported capabilities in the
response. CAPABILITY command response.
Messages are sorted using the values of the <attribute-name> Messages are sorted using the values of the <attribute-name>
attributes in the <entry-name> entries. attributes in the <entry-name> entries.
Clients MUST provide either the ".priv" or ".shared" suffix to the Clients MUST provide either the ".priv" or ".shared" suffix to the
attribute name to ensure that the server knows which specific value attribute name to ensure that the server knows which specific value
to sort on. to sort on.
Only the "value.priv", "value.shared", "size.priv" and "size.shared" Only the "value.priv" and "value.shared" attributes can be used for
attributes can be used for sorting. Clients MUST NOT specify an sorting. Clients MUST NOT specify an attribute other than either
attribute other than either "value.priv", "value.shared", "size.priv" "value.priv" or "value.shared". Servers MUST return a BAD response
or "size.shared". Servers MUST return a BAD response if the client if the client tries to search any other attribute.
tries to search any other attribute.
When either "value.priv" or "value.shared" is being sorted, the When either "value.priv" or "value.shared" is being sorted, the
server MUST use the character set value specified in the SORT command server MUST use the character set value specified in the SORT command
to determine the appropriate sort order. to determine the appropriate sort order.
When either "size.priv" or "size.shared" is being sorted, the server
sorts using the numeric values of those attributes, as it would when
the "SIZE" sort key is used.
Example: Example:
C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL
S: * SORT 2 3 4 5 1 11 10 6 7 9 8 S: * SORT 2 3 4 5 1 11 10 6 7 9 8
S: a OK Sort complete S: a OK Sort complete
In the above example, the message numbers of all messages are In the above example, the message numbers of all messages are
returned, sorted according to the shared "value" attribute of the returned, sorted according to the shared "value" attribute of the
"/altsubject" entry. "/altsubject" entry.
Note that the ANNOTATION sort key must include a fully specified Note that the ANNOTATION sort key must include a fully specified
entry - wild cards are not allowed. entry - wild cards are not allowed.
4.10. New ACL Rights 5.10. New ACL Rights
As discussed in Section 3.4 this extension adds a new "n" right to As discussed in Section 4.4 this extension adds a new "n" right to
the list of rights provided by the ACL extensions [RFC2086] and the list of rights provided by the ACL extensions [RFC2086] and
[I-D.ietf-imapext-2086upd]. [RFC4314].
5. Formal Syntax 6. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC2234]. Form (ABNF) notation as specified in [RFC2234].
Non-terminals referenced but not defined below are as defined by Non-terminals referenced but not defined below are as defined by
[RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf] [RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf]
superseding those in [RFC3501]. superseding those in [RFC3501].
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
skipping to change at page 25, line 4 skipping to change at page 25, line 47
(("READ-ONLY" / nz-size) (("READ-ONLY" / nz-size)
[SP "NOPRIVATE"]) [SP "NOPRIVATE"])
; response codes indicating the level of ; response codes indicating the level of
; support for annotations in a mailbox ; support for annotations in a mailbox
append-ext =/ att-annotate append-ext =/ att-annotate
; modifies [RFC3501] extension behaviour ; modifies [RFC3501] extension behaviour
att-annotate = "ANNOTATION" SP att-annotate = "ANNOTATION" SP
"(" entry-att *(SP entry-att) ")" "(" entry-att *(SP entry-att) ")"
att-search = "value" / "value.priv" / "value.shared" att-search = "value" / "value.priv" / "value.shared"
; the only attributes that can be searched ; the only attributes that can be searched
att-sort = "value.priv" / "value.shared" / att-sort = "value.priv" / "value.shared"
"size.priv" / "size.shared"
; the only attributes that can be sorted ; the only attributes that can be sorted
att-value = attrib SP value att-value = attrib SP value
attrib = astring attrib = astring
; dot-separated attribute name ; dot-separated attribute name
; MUST NOT contain "*" or "%" ; MUST NOT contain "*" or "%"
attribs = attrib / "(" attrib *(SP attrib) ")" attribs = attrib / "(" attrib *(SP attrib) ")"
; one or more attribute specifiers ; one or more attribute specifiers
capability =/ "ANNOTATE" capability =/ "ANNOTATE-EXPERIMENT-1"
; defines the capability for this extension ; defines the capability for this extension
entries = entry-match / entries = entry-match /
"(" entry-match *(SP entry-match) ")" "(" entry-match *(SP entry-match) ")"
entry = astring entry = astring
; slash-separated path to entry ; slash-separated path to entry
; MUST NOT contain "*" or "%" ; MUST NOT contain "*" or "%"
entry-att = entry SP "(" att-value *(SP att-value) ")" entry-att = entry SP "(" att-value *(SP att-value) ")"
skipping to change at page 26, line 4 skipping to change at page 26, line 47
; extends FETCH response with annotation data ; extends FETCH response with annotation data
resp-text-code =/ "ANNOTATE" SP "TOOBIG" / resp-text-code =/ "ANNOTATE" SP "TOOBIG" /
"ANNOTATE" SP "TOOMANY" / "ANNOTATE" SP "TOOMANY" /
"ANNOTATIONS" SP ann-size "ANNOTATIONS" SP ann-size
; new response codes ; new response codes
search-key =/ "ANNOTATION" SP entry-match SP att-search search-key =/ "ANNOTATION" SP entry-match SP att-search
SP value SP value
; modifies original IMAP search-key ; modifies original IMAP search-key
select-param =/ "ANNOTATE" select-param =/ "ANNOTATE"
; defines the select parameter used with ; defines the select parameter used with
; ANNOTATE extension ; ANNOTATE extension
sort-key =/ "ANNOTATION" SP entry SP att-sort sort-key =/ "ANNOTATION" SP entry SP att-sort
; modifies original sort-key ; modifies original sort-key
store-att-flags =/ att-annotate store-att-flags =/ att-annotate
; modifies original IMAP STORE command ; modifies original IMAP STORE command
value = nstring / literal8 value = nstring / literal8
6. IANA Considerations 7. IANA Considerations
Entry names MUST be specified in a standards track or IESG approved Entry names MUST be specified in a standards track or IESG approved
experimental RFC, or fall under the vendor namespace. Vendor names experimental RFC, or fall under the vendor namespace. Vendor names
MUST be registered. MUST be registered.
Attribute names MUST be specified in a standards track or IESG Attribute names MUST be specified in a standards track or IESG
approved experimental RFC. approved experimental RFC.
Each entry registration MUST include a content-type that is used to Each entry registration MUST include a content-type that is used to
indicate the nature of the annotation value. Where applicable a indicate the nature of the annotation value. Where applicable a
charset parameter MUST be included with the content-type. charset parameter MUST be included with the content-type.
6.1. Entry and Attribute Registration Template 7.1. Entry and Attribute Registration Template
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[] Entry [] Attribute [] Entry [] Attribute
Name: ______________________________ Name: ______________________________
skipping to change at page 27, line 4 skipping to change at page 27, line 45
Description: _______________________ Description: _______________________
____________________________________ ____________________________________
____________________________________ ____________________________________
Content-Type:_______________________ Content-Type:_______________________
Contact person: ____________________ Contact person: ____________________
email: ____________________ email: ____________________
6.2. Entry Registrations 7.2. Entry Registrations
The following templates specify the IANA registrations of annotation The following templates specify the IANA registrations of annotation
entries specified in this document. entries specified in this document.
6.2.1. /comment 7.2.1. /comment
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /comment Name: /comment
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.2.2. /flags 7.2.2. /flags
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /flags Name: /flags
Description: Reserved entry hierarchy. Description: Reserved entry hierarchy.
Content-Type: - Content-Type: -
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.2.3. /altsubject 7.2.3. /altsubject
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /altsubject Name: /altsubject
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.2.4. /<section-part>/comment 7.2.4. /<section-part>/comment
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /<section-part>/comment Name: /<section-part>/comment
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.2.5. /<section-part>/flags/seen 7.2.5. /<section-part>/flags/seen
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /<section-part>/flags/seen Name: /<section-part>/flags/seen
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.2.6. /<section-part>/flags/answered 7.2.6. /<section-part>/flags/answered
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /<section-part>/flags/answered Name: /<section-part>/flags/answered
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.2.7. /<section-part>/flags/flagged 7.2.7. /<section-part>/flags/flagged
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /<section-part>/flags/flagged Name: /<section-part>/flags/flagged
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.2.8. /<section-part>/flags/forwarded 7.2.8. /<section-part>/flags/forwarded
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[X] Entry [] Attribute [X] Entry [] Attribute
Name: /<section-part>/flags/forwarded Name: /<section-part>/flags/forwarded
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.3. Attribute Registrations 7.3. Attribute Registrations
The following templates specify the IANA registrations of annotation The following templates specify the IANA registrations of annotation
attributes specified in this document. attributes specified in this document.
6.3.1. value 7.3.1. value
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[] Entry [X] Attribute [] Entry [X] Attribute
Name: value Name: value
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.3.2. size 7.3.2. size
To: iana@iana.org To: iana@iana.org
Subject: IMAP Annotate Registration Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item: Please register the following IMAP Annotate item:
[] Entry [X] Attribute [] Entry [X] Attribute
Name: size Name: size
Description: Defined in IMAP ANNOTATE extension document. Description: Defined in IMAP ANNOTATE extension document.
Contact person: Cyrus Daboo Contact person: Cyrus Daboo
email: cyrus@daboo.name email: cyrus@daboo.name
6.3.3. content-language 8. Internationalization Considerations
To: iana@iana.org
Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item:
[] Entry [X] Attribute
Name: content-language
Description: Defined in IMAP ANNOTATE extension document.
Contact person: Cyrus Daboo
email: cyrus@daboo.name
7. Internationalization Considerations
Annotations may contain values that include text strings, and both Annotations may contain values that include text strings, and both
searching and sorting are possible with annotations. Servers MUST searching and sorting are possible with annotations. Servers MUST
follow standard IMAP text normalization, character set conversion and follow standard IMAP text normalization, character set conversion and
collation rules when such operations are acarried out, as they would collation rules when such operations are acarried out, as they would
for other textual fields being searched or sorted on. for other textual fields being searched or sorted on.
8. Security Considerations 9. Security Considerations
Annotations whose values are intended to remain private MUST be Annotations whose values are intended to remain private MUST be
stored in ".priv" values, and not ".shared" values which may be stored in ".priv" values, and not ".shared" values which may be
accessible to other users. accessible to other users.
Excluding the above issues the ANNOTATE extension does not raise any Excluding the above issues the ANNOTATE extension does not raise any
security considerations that are not present in the base IMAP security considerations that are not present in the base IMAP
protocol, and these issues are discussed in [RFC3501]. protocol, and these issues are discussed in [RFC3501].
9. References 10. References
9.1. Normative References
[I-D.ietf-imapext-2086upd] 10.1. Normative References
Melnikov, A., "IMAP4 ACL extension",
draft-ietf-imapext-2086upd-08 (work in progress),
June 2005.
[I-D.ietf-imapext-sort] [I-D.ietf-imapext-sort]
Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS
PROTOCOL - SORT AND THREAD EXTENSION", PROTOCOL - SORT AND THREAD EXTENSION",
draft-ietf-imapext-sort-17 (work in progress), May 2004. draft-ietf-imapext-sort-17 (work in progress), May 2004.
[I-D.melnikov-imap-ext-abnf] [I-D.melnikov-imap-ext-abnf]
Daboo, C. and A. Melnikov, "Collected extensions to IMAP4 Daboo, C. and A. Melnikov, "Collected extensions to IMAP4
ABNF", draft-melnikov-imap-ext-abnf-05 (work in progress), ABNF", draft-melnikov-imap-ext-abnf-08 (work in progress),
October 2005. January 2006.
[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003. MULTIAPPEND Extension", RFC 3502, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
9.2. Informative References [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
10.2. Informative References
[I-D.ietf-imapext-condstore] [I-D.ietf-imapext-condstore]
Melnikov, A. and S. Hole, "IMAP Extension for Conditional Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE operation", draft-ietf-imapext-condstore-06 (work in STORE operation", draft-ietf-imapext-condstore-09 (work in
progress), October 2005. progress), February 2006.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Many thanks to Chris Newman for his detailed comments on the first Many thanks to Chris Newman for his detailed comments on the first
draft of this document, and to the participants at the ACAP working draft of this document, and to the participants at the ACAP working
dinner in Pittsburgh. The participants of the IMAPext working group dinner in Pittsburgh. The participants of the IMAPext working group
made significant contributions to this work. made significant contributions to this work.
Authors' Addresses Authors' Addresses
skipping to change at page 35, line 41 skipping to change at page 36, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 79 change blocks. 
173 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/