Shepherd writeup
draft-ietf-extra-imap4rev2-30

(1) Document Type: Proposed Standard.

This is appropriate as it combines the work from other documents which are Proposed Standard.

(2) Document Announcement Write-Up:

Technical Summary:

This document is revision 2 of the IMAP4 protocol, of which revision 1
is defined in RFC3501.

IMAP4 is widely used and widely extended - there are over 50 RFCs defining
extensions to the IMAP protocol.

This document merges in many of the widely-used and popular extensions to
form a new baseline.  It also removes a couple of the unused and poorly
supported features that are no longer used.

IMAP4rev2 is an opt-in extension which is designed to be implementable
alongside IMAP4rev1.

Working Group Summary:

This document is very long and complex and there was a lot of discussion
about specific points.  The discussion involved developers from many of
the largest IMAP4 servers, as well as client authors.

While there are tradeoffs that had to be made, there's nobody in the
working group who has expressed unhappiness or concerns about the
content of this document.

Document Quality:

To a large extent this document covers existing practice in common servers.

The document has been closely reviewed by many expert IMAP server
implementers.


Personnel:

* Document Shepherd: Bron Gondwana
* Area Director: Murray Kucherawy

(3) I reviewed an earlier revision of this document in fine detail, over a
couple of solid days sitting with a printout and a red pen checking each
section against a pretty deep understanding of the data model as a developer
of one of the IMAP4rev1 servers.  Since then, I've read all the diffs and
followed the mailing list discussion closely.

(4) I don't have any concerns about the length and bredth of reviews.
Multiple detailed reviews on the list have been done by the foremost world
experts on this protocol suite, many of whom have implemented and managed
IMAP servers for over a decade.

(5) This document doesn't contain sections which need specific review from
other areas, it doesn't add anything significantly new from the IMAP4rev1
extensions that it combines.

(6) I don't have any specific concerns for the Area Director or IESG to
be aware of.

(7) Yes, I have confirmed that there is no IPR to be declared by either of
the authors.

(8) There have been no IPR disclosures.

(9) There's a very solid working group consensus.

(10) There are no appeal threats.

(11) Nits:

 a couple of lines are too long, which are protocol examples

(12) There are no formal reviews required.

(13) Yes, all references have been identified.

(14) There are no references to documents that are incomplete.

(15) There are no downwards references.

(16) This document won't change the status of other documents.

(17) No new IANA registries are created, and this document specifies
which IANA registries have entries that need to be updated to point
to this document.

(18) There are no new IANA registries.

(19) I haven't tested the formal ABNF sections other than reading
through them fairly carefully back when I reviewed this.

(20) There's no YANG here.


Back