Internet Message Access Protocol - ANNOTATE Extension
RFC 5257

Received changes through RFC Editor sync (changed abstract to 'The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or 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.

Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.

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. This memo defines an Experimental Protocol for the Internet community.')

IANA Comments:

Upon approval of this document, the IANA will complete two actions.

[1] Creation of a new registry to contain the annotation
entries and annotation attributes associated with the IMAP
ANNOTATE Extension. Inside that registry will be two
subregistries:

[1.1] IANA will create a new subregistry for annotation
entries. Entry names must be specified in a standards
track or IESG approved experimental RFC, or fall under
the vendor namespace. Each entry registration must include a
content-type that is used to indicate the nature of the
annotation value.

The initial values in this new sub registry will be:

Name: /comment
Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: /flags
Description: Reserved entry hierarchy.
Content-Type: -
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: /altsubject
Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: //comment
Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: //flags/seen
Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: //flags/answered
Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: //flags/flagged
Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: //flags/forwarded
Description: Defined in IMAP ANNOTATE extension document.
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
email: cyrus@daboo.name

[1.2] IANA will create a new registry for annotation attributes. Attribute
names MUST be specified in a standards track or IESG approved experimental
RFC.The initial values for this subregistry will be:

Name: value
Description: Defined in IMAP ANNOTATE extension document.
Contact person: Cyrus Daboo
email: cyrus@daboo.name

Name: size
Description: Defined in IMAP ANNOTATE extension document.
Contact person: Cyrus Daboo
email: cyrus@daboo.name

[2] The registration of attribute names and entry names is
done using a template provided by section 7.1 of the approved
document. IANA will include a copy of the template in the
registry created in step [1] of these actions.

IANA understands that these are the only actions required
upon approval of this document.

[Ballot comment]
From Gen-ART review by Robert Sparks.

1: Has there been any explicit discussion about what a  future transition from experimental to PS would look like? If there is uptake of the extension using ANNOTATE-EXPERIMENT-1 and  we later want to deploy this as ANNOTATE, its clear what the path is if everything worked, but if experience showed that some  component or semantic needed to change in a non-backward compatible way, is it an expectation/requirement that mailboxes with  EXPERIMENT-1 annotations be preservable?

2: The last sentence of section 4.5 speaks of  "completely bypassing the base IMAP flag/keyword behavior". To me this implies that the client can forget the base mechanisms  exist and ignore/not use them. I don't think that was the intent of the sentence (I'm guessing it means "instead of relying on  the base behavior" or "instead of being limited to the base behavior"?)

3: Section 4.2.2 confused me on first read. I wonder if  the second paragraph is vestigal and now out of place (the idea is captured more clearly in 4.3). A sentence noting that  the definition blocks here  are the attribute names defined in this draft would also help avoid the confusion I ran into.

[Ballot comment]
From Gen-ART review by Robert Sparks.

1: Has there been any explicit discussion about what a  future transition from experimental to PS would look like? If there is uptake of the extension using ANNOTATE-EXPERIMENT-1 and  we later want to deploy this as ANNOTATE, its clear what the path is if everything worked, but if experience showed that some  component or semantic needed to change in a non-backward compatible way, is it an expectation/requirement that mailboxes with  EXPERIMENT-1 annotations be preservable?

2: The last sentence of section 4.5 speaks of  "completely bypassing the base IMAP flag/keyword behavior". To me this implies that the client can forget the base mechanisms  exist and ignore/not use them. I don't think that was the intent of the sentence (I'm guessing it means "instead of relying on  the base behavior" or "instead of being limited to the base
behavior"?)

3: Section 4.2.2 confused me on first read. I wonder if  the second paragraph is vestigal and now out of place (the idea is captured more clearly in 4.3). A sentence noting that  the definition blocks here  are the attribute names defined in this draft would also help avoid the confusion I ran into.

[Ballot discuss]
From Gen-ART review by Robert Sparks.

Looking at this from IANA's point of view, it's not  clear what the draft is asking them to do. If I read it correctly, it's asking for (at least one) new registry. If that's correct, there  are more explicit instructions needed [to create the registry]. It would probably be helpful to reiterate the pointer to 2244 for the vendor name registry. And  I'm curious whether this draft should register this capability in http://www.iana.org/assignments/imap4-capabilities?