The IMAP ENABLE Extension
draft-gulbrandsen-imap-enable-05

[Ballot comment]
While I agree that this command does not create any new security considerations (with respect
to RFC 3501, which is referenced), it might be helpful to reiterate that this command is only
valid in Authentiocated state.  Accepting this command before authentication might allow a mitm
to direct unsolicited responses to clients that don't supoport those IMAP extensions.

[Ballot comment]
Section 3.1, paragraph 9:
> Clients SHOULD only include extensions that need to be enabled by
> the server. At the time this RFC is published CONDSTORE is the only
> such extension (ie. ENABLE CONDSTORE is an additional "Condstore
> enabling command" as defined in [RFC4551]). Future RFCs may add to
> this list. [Note to the RFC Editor: If the IMAP ANNOTATE document
> has been published already, ANNOTATE should be mentioned as well as
> CONDSTORE.]

  If it is considered important to also mention ANNOTATE, you could add
  a sentence here and normatively cite [ANNOTATE], so that the RFC
  Editor will wait with publishing this document until [ANNOTATE] has
  been published. (In case you don't do this, you probably want to give
  the RFC Editor more specific instructions on how to "mention"
  ANNOTATE.)


Section 2., paragraph 2:
> the client is aware of the extension). CONSTORE ([RFC4551]),

  Nit: s/CONSTORE/CONDSTORE/

[Ballot comment]
Section 3.1, paragraph 9:
> Clients SHOULD only include extensions that need to be enabled by
> the server. At the time this RFC is published CONDSTORE is the only
> such extension (ie. ENABLE CONDSTORE is an additional "Condstore
> enabling command" as defined in [RFC4551]). Future RFCs may add to
> this list. [Note to the RFC Editor: If the IMAP ANNOTATE document
> has been published already, ANNOTATE should be mentioned as well as
> CONDSTORE.]

  If it is considered important to also mention ANNOTATE, you could add
  a sentence here and normatively cite [ANNOTATE], so that the RFC
  Editor will aiwt with publishing this document until [ANNOTATE] has
  been published. (In case you don't do this, you probably want to give
  the RFC Editor more specific instructions on how to "mention"
  ANNOTATE.)


Section 2., paragraph 2:
> the client is aware of the extension). CONSTORE ([RFC4551]),

  Nit: s/CONSTORE/CONDSTORE/

IANA Last Call comments:

Upon approval of this document, the IANA will make the following assignments
in the "IMAP4 Capabilities Registry" registry located at
http://www.iana.org/assignments/imap4-capabilities

Capability Name | Reference
-------------------------- + ------------------
ENABLE | [RFC-gulbrandsen-imap-enable-05]

We understand the above to be the only IANA Action for this document.

  (1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Alexey Melnikov  is the document shepherd for
this document. The document is ready for publication.

  (1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?  Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

This is an individual submission. The document was adequately reviewed and there are no concerns about the depth of the reviews.

  (1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns.

  (1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the  document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.  Has an IPR disclosure related to this  document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No IPR disclosure was filed for this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

This document is an individual submission. There are at least 5 existing implementations and even more reviews of the document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated  extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

One IMAP server implementor was opposed to the idea, but there is very strong consensus to publish the document anyway.
The implementor didn't threaten to appeal.

  (1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
        not enough; this check needs to be thorough.  Has the  document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

IDnits 2.04.12 was used to verify the document. No issues were found.

  (1.h)  Has the document split its references into normative and
        informative?  Are there normative references to documents  that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion?  Are there normative  references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes, references are properly split. There are no downward normative
references. The document has 1 informative reference to a draft which is already in RFC editor's queue.

  (1.i)  Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?  If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?  If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

IANA considerations section exists and is clearly defined.
It requires registration of a new IMAP extension in an existing registry.

  (1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

ABNF from the document verifies with Bill Fenner's ABNF parser.

  (1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up?  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

Most IMAP extensions are used by the client when the client wants to and the
server supports the extension. However, a few extensions require the server to
know whether a client supports that extension.  The ENABLE extension
allows an IMAP client to say which extensions it supports.

  This document is targeted to become a Proposed Standard.

        Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

This is an individual submission.

The idea of client side IMAP capabilities was discussed on and off for many years.
(I think for at least 8 years)

There were some discussions about server behavior in response to client enabling
a capability that doesn't need any enabling. The current text represents rough
consensus among IMAP experts and implementors.

        Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive  issues?  If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)?  In the case of a Media  Type
            review, on what date was the request posted?

At least 7 people have reviewed the document. Posted comments were addressed in the latest revision.
There are at least 5 existing implementations (3 servers and 2 clients).

        Personnel
            Who is the Document Shepherd for this document?  Who is  the
            Responsible Area Director?

Alexey Melnikov  is the document shepherd for
this document. Chris Newman is the responsible Area Director.