Skip to main content

Internet Message Access Protocol - ANNOTATE Extension
draft-ietf-imapext-annotate-16

Revision differences

Document history

Date Rev. By Action
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2007-06-20
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-06-19
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-06-19
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-06-06
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-05-20
16 (System) IANA Action state changed to In Progress
2007-05-15
16 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-05-14
16 Amy Vezza IESG state changed to Approved-announcement sent
2007-05-14
16 Amy Vezza IESG has approved the document
2007-05-14
16 Amy Vezza Closed "Approve" ballot
2007-05-02
16 Lisa Dusseault Changed RFC Ed note to add missing IANA registration for capability.
2007-05-02
16 Lisa Dusseault State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Lisa Dusseault
2006-11-17
16 (System) Removed from agenda for telechat - 2006-11-16
2006-11-16
16 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2006-11-16
16 Amy Vezza [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Amy Vezza
2006-11-16
16 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-11-16
16 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-11-15
16 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2006-11-15
16 Yoshiko Fong
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 …
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.
2006-11-15
16 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2006-11-15
16 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2006-11-15
16 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2006-11-15
16 Brian Carpenter
[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 …
[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.
2006-11-15
16 Brian Carpenter
[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 …
[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.
2006-11-15
16 Brian Carpenter
[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 …
[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?
2006-11-15
16 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded by Brian Carpenter
2006-11-14
16 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-11-14
16 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2006-11-13
16 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-11-08
16 (System) Requested Telechat review by SECDIR
2006-11-02
16 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault
2006-11-02
16 Lisa Dusseault Ballot has been issued by Lisa Dusseault
2006-11-02
16 Lisa Dusseault Created "Approve" ballot
2006-11-02
16 Lisa Dusseault Placed on agenda for telechat - 2006-11-16 by Lisa Dusseault
2006-11-02
16 Lisa Dusseault State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Lisa Dusseault
2006-10-19
16 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-10-19
16 (System) New version available: draft-ietf-imapext-annotate-16.txt
2006-08-10
16 Lisa Dusseault Note field has been cleared by Lisa Dusseault
2006-08-10
16 Lisa Dusseault State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Lisa Dusseault
2006-08-10
16 Lisa Dusseault State Change Notice email list have been change to <presnick@qualcomm.com>, cyrus@daboo.name from <presnick@qualcomm.com>
2006-08-07
16 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-07-31
16 Lisa Dusseault [Note]: 'Next state will be Revised ID needed according to Cyrus.' added by Lisa Dusseault
2006-07-24
16 Amy Vezza Last call sent
2006-07-24
16 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-07-24
16 Lisa Dusseault Last Call was requested by Lisa Dusseault
2006-07-24
16 Lisa Dusseault State Changes to Last Call Requested from Publication Requested by Lisa Dusseault
2006-07-24
16 (System) Ballot writeup text was added
2006-07-24
16 (System) Last call text was added
2006-07-24
16 (System) Ballot approval text was added
2006-07-24
16 Lisa Dusseault State Changes to Publication Requested from AD is watching by Lisa Dusseault
2006-07-20
16 Lisa Dusseault Intended Status has been changed to Experimental from Proposed Standard
2006-04-02
16 Scott Hollenbeck Shepherding AD has been changed to Lisa Dusseault from Scott Hollenbeck
2006-03-29
15 (System) New version available: draft-ietf-imapext-annotate-15.txt
2006-01-11
16 Scott Hollenbeck State Changes to AD is watching from Dead by Scott Hollenbeck
2005-11-28
14 (System) New version available: draft-ietf-imapext-annotate-14.txt
2005-11-07
16 (System) State Changes to Dead from AD is watching by system
2005-11-07
16 (System) Document has expired
2005-04-01
13 (System) New version available: draft-ietf-imapext-annotate-13.txt
2005-02-03
12 (System) New version available: draft-ietf-imapext-annotate-12.txt
2004-10-25
11 (System) New version available: draft-ietf-imapext-annotate-11.txt
2004-07-20
10 (System) New version available: draft-ietf-imapext-annotate-10.txt
2004-04-20
09 (System) New version available: draft-ietf-imapext-annotate-09.txt
2004-03-10
16 Scott Hollenbeck Shepherding AD has been changed to Scott Hollenbeck from Ned Freed
2003-10-21
08 (System) New version available: draft-ietf-imapext-annotate-08.txt
2003-05-20
07 (System) New version available: draft-ietf-imapext-annotate-07.txt
2003-03-06
06 (System) New version available: draft-ietf-imapext-annotate-06.txt
2002-11-21
16 Ned Freed Draft Added by Freed, Ned
2002-11-05
05 (System) New version available: draft-ietf-imapext-annotate-05.txt
2002-03-06
04 (System) New version available: draft-ietf-imapext-annotate-04.txt
2002-01-22
03 (System) New version available: draft-ietf-imapext-annotate-03.txt
2001-11-30
02 (System) New version available: draft-ietf-imapext-annotate-02.txt
2001-03-02
01 (System) New version available: draft-ietf-imapext-annotate-01.txt
2000-07-18
00 (System) New version available: draft-ietf-imapext-annotate-00.txt