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"
2.
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.
There was a significant amount of rework through multiple meetings which
led to a very complex document. In the end, the authors asked to drop
the complexity and go back to an earlier version. This achieved working
group consensus, so we're back where we were again!
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.
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 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
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 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.