Hi Robert,
Thanks for your review.
--On November 14, 2006 11:02:01 PM -0500 Robert Sparks
<[EMAIL PROTECTED]> wrote:
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.
Yes - its been around the block many times! The good news is there are now
a few people implementing it.
I have not verified the ABNF in this draft (Is there a record that
someone has done so recently?)
Alexey Melnikov did do a thorough review recently. I can ping him to do
another check.
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?
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
capability in http://www.iana.org/assignments/imap4-capabilities?
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
in this draft would also help avoid the confusion I ran into.
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
