Document: draft-ietf-imapext-annotate-16.txt
Reviewer: Robert Sparks [rjsparks@estacado.net]
Review Date: Tuesday 11/14/2006 10:02 PM CST
IESG telechat Date: November 16, 2006

Summary: This draft is basically ready for publication as an  
Experimental RFC, but has nits that should be addressed before  
publication.

Comments:

This draft shows it age and long history of forging, but it is  
essentially clear.

I have not verified the ABNF in this draft (Is there a record that  
someone has done so recently?)

Nit/Question 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?

Nit/Question 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"?)

Nit 3 (major) : 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,
its asking for (at least one) new registry. If that's correct, there  
are more explicit instructions needed. 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?

Nit 4 (trivial): 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.