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.