The IMAP ENABLE Extension
RFC 5161

Note: This ballot was opened for revision 05 and is now closed.

(Chris Newman) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2008-01-23)
No email
send info
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/

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was No Record, No Objection) No Objection

Comment (2008-01-24)
No email
send info
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.

(Dan Romascanu) No Objection

Comment (2008-01-24)
No email
send info
> The five characters [...] means that
    something has been elided.

I did not see this used in the document.

(David Ward) No Objection

Magnus Westerlund No Objection