Internet Message Access Protocol - ANNOTATE Extension
draft-ietf-imapext-annotate-16
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
(Lisa Dusseault; former steering group member) Yes
(Brian Carpenter; former steering group member) (was Discuss) No Objection
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.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection