Subject: [Gen-art] Genart review: draft-ietf-imapext-annotate-16.txt

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Nov 2006 23:02:01 -0500

I am the assigned Gen-ART reviewer for draft-ietf-imapext- 
annotate-16.txt

For background on Gen-ART, please see the FAQ at <http:// 
www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please wait for direction from your document shepherd or AD before  
posting a new version of the draft.

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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 16 Nov 2006 12:36:25 -0500

Hi Robert,
Thanks for your review.

--On November 14, 2006 11:02:01 PM -0500 Robert Sparks 
<[email-masked]> wrote:

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

Yes - its been around the block many times! The good news is there are now 
a few people implementing it.

> someone has done so recently?)

Alexey Melnikov did do a thorough review recently. I can ping him to do 
another check.

> If there is uptake of the extension using ANNOTATE-EXPERIMENT-1 and we
> later want to deploy this as ANNOTATE, its clear what

There has not been any explicit discussion on an experimental->proposed 
transition. I think any future proposed standard would define how one might 
upgrade depending on what exactly was changed. Obviously trying to preserve 
existing data would be a key requirement.

> 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"?)

If like 'instead of being limited to the base behavior' and propose making 
that wording change.

> 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

I propose adding the following paragraph at the start of IANA 
Considerations:

The specification requires two main actions on the part of IANA: 
registration of the extension capability, and setting up of a registry for 
annotation entry and attribute names.

I will then have two subsections. The first will be a single paragraph to 
do the extension registration (which is missing right now). The second will 
be the new registry. The text for that will be more explicit about setting 
it up and will also reference the 2244 registry for vendor names.

> 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

Yes, that second paragraph can be removed. I'm not sure whether there ought 
to be a forward reference to the next section there though.

-- 
Cyrus Daboo