Skip to main content

Shepherd writeup
draft-ietf-extra-specialuse-important

Document Shepherd Write-Up for draft-extra-specialuse-important

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

2.

Technical Summary

  This spec extends IMAP with an additional special-use [RFC6154]
  type for a mailbox (possibly virtual) which stores messages that
  may be important to the user.

  The document also creates a registry for mailbox uses to allow
  other uses to be defined in future.

Working Group Summary

  The only topic of debate was how to make the the registry useful
  for JMAP and other non-IMAP specifications as well, which led to
  adding instructions to IANA for a free-form column with usage
  guidance.

Document Quality

  An \Important special-use has been implemented by Gmail already,
  and all the other server implementations said it would be easy to
  add.

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
is happy that it's easy to implement.

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. There have been no IPR disclosures for this spec.

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

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool said one page was too long (60 lines rather than
58) however this may be due to instructions that will be removed before
publication.

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 new registry to be created and an
expert to be designated.  The initial values for the registry are fully
specified with clear instructions, and a good name has been chosen for
the registry.  Sources for all the initial values in the registry have
been provided.

18. The new IANA registry (IMAP Mailbox Name Attributes) will require
an expert reviewer, who should have IMAP protocol experience and ideally
server implementation experience.

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


Back