Skip to main content

Shepherd writeup
draft-ietf-extra-quota

Document Shepherd Write-Up for draft-ietf-extra-quota

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501) and obsoletes another
Proposed Standard (RFC2087).

The request type is indicated in the title page header as "Standards Track".

2.

Technical Summary

  This spec extends IMAP with additional commands (GETQUOTA, GETQUOTAROOT,
  SETQUOTA) and new STATUS attributes (DELETED and DELETED-STORAGE),
  allowing clients to determine how much space is used by an IMAP account
  and how much additional space might be available.

Working Group Summary

  There was no significant disagreement.  The main questions were around
  whether particular features were worth including, and whether the syntax
  was reliably parseable for OVERQUOTA responses that included tags (they
  were eventually removed as being un-necessary and ambiguous).

Document Quality

  This spec is quite easy to implement.  Most IMAP servers are already
  basically compatible because they have implemented RFC2087.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Murray Kucherawy


3. The Document Shepherd has read the document through in detail and has
plans to implement it in the Cyrus IMAP server.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

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

7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool complains about a non-RFC2606-compliant FQDN, but this
is a false positive on a newsgroup name example.  It also complains that the
document date is February 2022, which also appears to be a tool bug, as that
is the expiry date on the draft.

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 is a normative reference to an experimental RFC (RFC5257) however
this specification was written in 2008 and is widely enough used that we
should probably update it to a Proposed Standard as well.  The only reference
to that RFC is documenting an extension to allow quotas for those annotations
as well.

16. This RFC obsoletes one other RFC, RFC2087.

17. The IANA considerations ask that the imap4-capabilities registry both
have an entry updated, and have a prefix registered to restrict the use
of that prefix to IETF consesensus documents.

18. There is a new registry requested for IMAP quota resource types.  The
initial contents of the registry are set out clearly in the document.
The registration policy is "Specification Required".

19. The formal sections were validated with Chris Newman's ABNF
validator tool.

Back