Shepherd writeup
rfc8508-03

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 replace an
  existing message with a new message.  This is particularly useful
  for updating Draft messages, as it can avoid transient quota
  limitations.

Working Group Summary

  This is a draft which has been around for a while without a good
  group to progress it.  There was some discussion of whether it
  could be implemented as an extension to the existing APPEND command
  instead, but the need to have a mailbox selected in order to EXPUNGE
  the original message made it clear that a new command would be
  more consistent. 

Document Quality

  The document spells out interactions with other 

Personnel

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


3. The Document Shepherd has read the document through in detail but has
not yet implemented it.

4. Multiple experienced implementors have commented on the list and
see no difficulties or conflicts in implementing this specification.

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.  The author has confirmed he is not aware of any IPR that affects this spec.

8. There have been no IPR disclosures for this spec.  The author has confirmed he is not aware of any IPR that affects 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 commented that [UID] looks like a reference.

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 pass validation and correctly reference
the documents which contain the expressions they are extending.
Back