IMAP4 Extensions for Quick Mailbox Resynchronization
draft-ietf-lemonade-reconnect-client-06

[Ballot comment]
I did not completely review the interactions when multiple clients are
manipulating a mailbox at the same time.  It looks complicated.  I'm
assuming that it has been thoroughly checked; if that is true, this
spec looks good.

[Ballot discuss]
From Gen-ART Review by Brian Carpenter.

  The reference to AUTH48 in the IANA Considerations should be removed.
  Normally such an update would be made by arrangement between IANA
  and the RFC Editor.  This document should not specify a later than
  usual assignment time.

[Ballot comment]
As a general rule, I am comfortable with security considerations by reference.  No
one should have to cut and paste the material out of an RFC you already reference.
However, I do believe it is unfair to readers to provide iterative referrals.

The Security Considerations section in this document is basically two pointers to the
security considerations in [CONDSTORE] and [RFC3501].  [CONDSTORE] (now RFC 4551)
is mentioned twice, so I really expected to find some content in the Security Considerations
section.  However, [CONDSTORE]'s Security Considerations section is only two sentences,
and one is a pointer to the security considerations in [RFC3501].

It might be better to replicate the content of CONDSTORE's security considerations
section in this document.

[Ballot comment]
The Security Considerations section is basically a pointer to the security considerations in
[CONDSTORE] and [RFC3501].  [CONDSTORE] is mentioned twice, so I really expected to
find some content in the Security Considerations section.  However, [CONDSTORE]'s Security
Considerations section is basically a pointer to the security considerations in [RFC3501].

This makes me worry that something important should have been documented in CONDSTORE
and has not been.  I am a bit less concerned about things falling through since Alexey Melnikov
is co-author of both documents, of course.

IANA Last Call Comments:

Upon approval of this document, the IANA will make
the following assignments in the "IMAP4 Capabilities
Registry [RFC3501]" registry located at

http://www.iana.org/assignments/imap4-capabilities

Capability Name Reference
--------------- ---------
[TBD-X-DRAFT-W05-QRESYNC] [RFC-lemonade-reconnect-client-05]

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

(1.a) Document Shepherd: Eric Burger, eburger@bea.com
, personally reviewed this document. This
document is ready for publication.

(1.b) Work group review: The lemonade work group provided review of this
document. There were a few comments by Randy Gellens on the WGLC of -02; the
two changes are incorporated in -03.

(1.c) Further review required: This document does not need further
specialized review, as it has received review by many members of the IMAP
community.

(1.d.i) Document Shepherd Comfort Level: High
(1.d.ii) Document Useful and Needed: Yes
(1.d.iii) IPR Disclosures: None known

(1.e) WG Consensus: There was virtually no comment on this revision, mainly
because there was substantial comment on the previous version that was
addressed. This group is normally very vocal if there are problems. The
only substantial comment was by a client implementer who said that the
protocol would ³do no harm.²

(1.f) There are no members with objections or concerns. There are no
threats of appeal or process issues.

(1.g) ID-nits: Check and verified with idnits 2.04.01

(1.h) References: All references (normative and informative) are current
RFCs, checked with rfc-what-i-mean (11/06)

(1.i) IANA Considerations: Yes, correct, consistent, and follows RFC 3501
rules; note that actual capability name will be given to IANA during AUTH48.

(1.j) ABNF: Passes Bill¹s ABNF Parser

(1.k) Document Announcement:

Technical Summary

This document defines an IMAP4 extension, which gives an IMAP client the
ability to quickly resynchronize any previously opened mailbox as part of
the SELECT command, without the need for server-side state or additional
client round-trips. This extension also introduces a new response that
allows for a more compact representation for a list of expunged messages.


Working Group Summary

There is consensus in the WG to publish this document. There are three
client implementations and four server implementations by work group
members.


Document Quality

Virtually all members of the Lemonade WG have reviewed the document.

The document has been checked manually and using idnits 2.04.01, and passed
both checks.

Eric Burger shepherds this document, has reviewed this document, and
believes that this version is ready for forwarding to the IESG for
publication.