Skip to main content

Shepherd writeup
draft-ietf-extra-imap-status-size

Document Shepherd Write-Up for draft-extra-status-size

1. This document is being requested as an Internet Standard because it
extends an existing Internet Standard (RFC3501).  The request type is
indicated in the title page header.

2.

Technical Summary

  This spec extends IMAP to provide a way for clients to access
  a piece of data that many servers already keep, the total size
  of a mailbox.

Working Group Summary

  The only topic of debate was how tightly to define the method
  for calculating the size.  Many servers already implement a
  non-standard way to access this information, and many clients
  want access to the information.

Document Quality

  The Dovecot server already implements it.  It was implemented
  on the day it was proposed in the Cyrus IMAPd server.  Other
  vendors have stated their intention to implement.  All the
  server and client authors said that they would be able to
  implement the standard easily and agreed it was the best way
  to do it.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
implemented the full spec in a server as well as writing test-cases.

4. For such a short document it has had many reviews and been discussed
in two meetings where there was full consensus that it's a good idea.

5. There is no review required for the document by other areas, it's
very self-contained.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is very solid, while not everybody spoke, it was
clear that the entire group understood and agreed with the idea and
the method chosen.

10. There has been no discontent.

11. The ID nits tool complains about syntax inside [] for examples
which are in IMAP syntax.  There are no other issues found.  The
lines mentioned by the IDnits tool were the following:

121	   S: * OK [UNSEEN 7] First unseen.
122	   S: * OK [UIDVALIDITY 1364851417] UIDs valid
123	   S: * OK [UIDNEXT 242344] Predicted next UID
124	   S: * OK [HIGHESTMODSEQ 3914] Highest

This is exact IMAP syntax, so at least in the plain text version
it should be displayed like that.

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations ask for a single item to be added to
a registry, which is consistent with how that registry is used
in the body of the document.

18. None of the IANA registries mentioned require Expert Review.

19. The formal sections are simple enough that eyeball reading
was sufficient to validate them.


Back