Internet Message Access Protocol (IMAP) - SAVEDATE Extension
draft-ietf-extra-imap-savedate-01

[Ballot comment]
Section 1

  to permanently remove (expunge) all messages in that Trash mailbox
  deleted before a certain time (e.g. a configurable expiration

nit: comma after "e.g.".

Section 4.2

Should there be an example for the 'NIL response' case?

[Ballot comment]
This seems a very useful mechanism. Thanks to everyone who contributed.

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [KEYWORDS].

Please update to use RFC 8174's boilerplate.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-imap-savedate-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the IMAP Capabilities registry on the Internet Message Access Protocol (IMAP) Capabilities Registry page located at:

https://www.iana.org/assignments/imap-capabilities/

a single, new capability is to be registered as follows:

Capability Name: SAVEDATE
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-08-30):

From: The IESG
To: IETF-Announce
CC: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-savedate@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Message Access Protocol (IMAP) - SAVEDATE Extension) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'Internet
Message Access Protocol (IMAP) - SAVEDATE Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document adds a new capability called "SAVEDATE" to the Internet
  Message Access Protocol (IMAP).  It defines a new IMAP message
  attribute called 'save date' that, unlike the existing 'internal
  date' attribute, always indicates the moment at which the message was
  saved in its current mailbox.  The SAVEDATE capability extends the
  FETCH command with the means to retrieve the save date attribute and
  it extends the SEARCH command to allow using that attribute in
  searching criteria.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-extra-savedate

1. This document is being requested as a Proposed Standard because it
extends an existing Proposed Standard (RFC3501).

2.

Technical Summary

  This spec extends IMAP with an additional data point on each
  email in a mailbox which records the time at which the email
  was added to the mailbox.

Working Group Summary

  The only topic of debate was how to deal with mailboxes which don't
  support storing the savedate.  Various ideas were debated, and a
  conclusion was found which everybody was happy with.

Document Quality

  This specification has been implemented in multiple servers and is
  very easy to follow.

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
has implemented it in a 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. 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 has no issues with this spec.

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 capability to be added
to the IMAP capabilities registry.

18. There are no new IANA registries.

19. The ABNF has been eyeball checked and tested with the online ABNF
validator.