Shepherd writeup

Document Shepherd Write-Up for draft-ietf-extra-imap-fetch-preview

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


Technical Summary

  This spec extends IMAP with an additional fetch item (PREVIEW)
  which allows clients to obtain a short piece of text to use as
  a preview line in mailbox listings.

Working Group Summary

  This document and fetch item was originally named "snippet", however
  JMAP uses "preview" for the equivalent field, and "snippet" for a
  marked up section of the message containing search terms, so the
  working group agreed to change the naming to be consistent.

  There was also debate over the maximum length, with both JMAP and
  EXTRA working groups settling on 256 characters maximum.

  Finally there were questions over whether "LAZY" was useful, but nobody
  saw any downside to including it.  Servers can choose to always calculate
  the preview even if LAZY is given.

Document Quality

  This spec is quite easy to implement - it has multiple examples for all
  the likely cases.  It's been implemented in Dovecot and Cyrus IMAPd.


  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 it in the Cyrus IMAPd 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 said that the document year doesn't match current
year, but that's only because I ran it really early in 2019!

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

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 just asks for an entry in the IMAP
capabilities registry.

18. There are no new IANA registries.

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