Skip to main content

IMAP REPLACE Extension
draft-ietf-extra-imap-replace-03

Revision differences

Document history

Date Rev. By Action
2019-01-02
03 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-12-03
03 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-11-14
03 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-10-30
03 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-10-30
03 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2018-10-29
03 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-10-29
03 (System) RFC Editor state changed to EDIT
2018-10-29
03 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-10-29
03 (System) Announcement was received by RFC Editor
2018-10-29
03 (System) IANA Action state changed to In Progress
2018-10-29
03 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-10-29
03 Cindy Morgan IESG has approved the document
2018-10-29
03 Cindy Morgan Closed "Approve" ballot
2018-10-29
03 Cindy Morgan Ballot approval text was generated
2018-10-26
03 Alexey Melnikov This document addressed IESG comments. There was a small ABNF error introduced in the latest version which was addressed by an RFC Editor note.
2018-10-26
03 Alexey Melnikov IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2018-10-26
03 Alexey Melnikov RFC Editor Note was changed
2018-10-26
03 Alexey Melnikov RFC Editor Note for ballot was generated
2018-10-26
03 Alexey Melnikov RFC Editor Note for ballot was generated
2018-10-25
03 Cindy Morgan New version available: draft-ietf-extra-imap-replace-03.txt
2018-10-25
03 (System) Secretariat manually posting. Approvals already received
2018-10-25
03 Cindy Morgan Uploaded new revision
2018-10-25
02 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2018-10-24
02 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-24
02 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-10-24
02 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-10-24
02 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-10-24
02 Alissa Cooper [Ballot comment]
Please take a look at the Gen-ART review.
2018-10-24
02 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-10-23
02 Ben Campbell
[Ballot comment]
Thanks for this effort. I am balloting "yes", but I have some minor (mostly editorial) comments:

§1: Is there a reason not to …
[Ballot comment]
Thanks for this effort. I am balloting "yes", but I have some minor (mostly editorial) comments:

§1: Is there a reason not to use the new boilerplate from RFC 8174?

§3.4: "the intermediate states produced do not occur,"
That seems an odd statement; one might say that if a state did not occur it was not produced. Would it make sense to just say "the intermediate states do not occur"?

§3.5: "Unlike the APPEND command which is valid..."
Missing comma before "which".
2018-10-23
02 Ben Campbell Ballot comment text updated for Ben Campbell
2018-10-23
02 Ben Campbell
[Ballot comment]
Thanks for this effort. I am balloting "yes", but I have some minor (mostly editorial) comments:

§1: Is there a reason not to …
[Ballot comment]
Thanks for this effort. I am balloting "yes", but I have some minor (mostly editorial) comments:

§1: Is there a reason not to use the new boilerplate from RFC 8174?

§3.4: "the intermediate states produced do not occur,"
That seems an odd statement; one might say that if a state did not occur it was not produced. Would it make sense to kist say "the intermediate states do not occur"?

§3.5: "Unlike the APPEND command which is valid..."
Missing comma before "which".
2018-10-23
02 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2018-10-23
02 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2018-10-23
02 Spencer Dawkins
[Ballot comment]
I'm curious about one point -

  In its simplest form, the REPLACE command is a single-command
  encapsulation of APPEND, STORE +flags …
[Ballot comment]
I'm curious about one point -

  In its simplest form, the REPLACE command is a single-command
  encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a
  message, except that it avoids any of the quota implications or
  intermediate states associated with the 3 command sequence.  In
  handling a REPLACE command, a server MUST NOT generate a response
  code for the STORE +flags \DELETED portion of the sequence.
  Additionally, servers supporting the REPLACE command MUST NOT infer
  any inheritance of content, flags, or annotations from the message
  being replaced.  Finally, the replaced and replacing messages SHOULD
  NOT be present in the mailbox at the same time.

I can imagine that having the replaced and replacing messages present at the same time is better than having the replaced message deleted and the replacing message not stored due to quota limits when pipelining APPEND, STORE, EXPUNGE, but is SHOULD the right level of requirement language here? Is MUST just a non-starter?
2018-10-23
02 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-10-23
02 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12061



COMMENTS
S 2.
>      handling a REPLACE command, a server MUST NOT generate a …
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12061



COMMENTS
S 2.
>      handling a REPLACE command, a server MUST NOT generate a response
>      code for the STORE +flags \DELETED portion of the sequence.
>      Additionally, servers supporting the REPLACE command MUST NOT infer
>      any inheritance of content, flags, or annotations from the message
>      being replaced.  Finally, the replaced and replacing messages SHOULD
>      NOT be present in the mailbox at the same time.

I don't think I understand this text. What would it look like for them
to be present at the same time.
2018-10-23
02 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-10-23
02 Benjamin Kaduk
[Ballot comment]
Section 1

(RFC 8174 provides an updated version of the BCP 14 boilerplate that can be
used instead of the RFC 2119 …
[Ballot comment]
Section 1

(RFC 8174 provides an updated version of the BCP 14 boilerplate that can be
used instead of the RFC 2119 boilerplate.)

Section 3.5

  Unlike the APPEND command which is valid in the authenticated state,
  the REPLACE and UID REPLACE commands MUST only be valid in the
  selected state.  This difference from APPEND is necessary since
  REPLACE operates on message sequence numbers.

The stated justification applies only to REPLACE.  What is the
justification for disallowing UID REPLACE from the authenticated state?

Section 4.3

  (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS
  specification means that the client first receives an EXPUNGE for a
  message and afterwards APPENDUID for the new message.  [...]

nit: This comma is either spurious or missing a partner (if "as described
in the UIDPLUS specification" is supposed to be a parenthetical).
2018-10-23
02 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-10-23
02 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-10-20
02 Scott Bradner Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Scott Bradner. Sent review to list.
2018-10-16
02 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-10-16
02 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-10-16
02 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-10-12
02 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-10-12
02 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-10-12
02 Stuart Brandt New version available: draft-ietf-extra-imap-replace-02.txt
2018-10-12
02 (System) New version approved
2018-10-12
02 (System) Request for posting confirmation emailed to previous authors: Stuart Brandt
2018-10-12
02 Stuart Brandt Uploaded new revision
2018-10-12
01 Robert Sparks Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list.
2018-10-11
01 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2018-10-11
01 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-imap-replace-01. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-imap-replace-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 registration will be made as follows:

Capability Name: REPLACE
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
2018-10-11
01 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Catherine Meadows.
2018-10-04
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2018-10-04
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2018-10-04
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2018-10-04
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2018-10-03
01 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2018-10-03
01 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2018-10-02
01 Cindy Morgan Placed on agenda for telechat - 2018-10-25
2018-10-02
01 Alexey Melnikov Ballot writeup was changed
2018-10-02
01 Alexey Melnikov Ballot has been issued
2018-10-02
01 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-10-02
01 Alexey Melnikov Created "Approve" ballot
2018-10-02
01 Alexey Melnikov Ballot writeup was changed
2018-10-02
01 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-10-02
01 Amy Vezza
The following Last Call announcement was sent out (ends 2018-10-16):

From: The IESG
To: IETF-Announce
CC: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-replace@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com …
The following Last Call announcement was sent out (ends 2018-10-16):

From: The IESG
To: IETF-Announce
CC: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-replace@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IMAP REPLACE 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: - 'IMAP
REPLACE 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-10-16. 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 defines an IMAP extension which can be used to replace
  an existing message in a message store with a new message.  Message
  replacement is a common operation for clients that automatically save
  drafts or notes as a user composes them.




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

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


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




2018-10-02
01 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-10-02
01 Alexey Melnikov Last call was requested
2018-10-02
01 Alexey Melnikov Last call announcement was generated
2018-10-02
01 Alexey Melnikov Ballot approval text was generated
2018-10-02
01 Alexey Melnikov Ballot writeup was generated
2018-10-02
01 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2018-10-01
01 Stuart Brandt New version available: draft-ietf-extra-imap-replace-01.txt
2018-10-01
01 (System) New version approved
2018-10-01
01 (System) Request for posting confirmation emailed to previous authors: Stuart Brandt
2018-10-01
01 Stuart Brandt Uploaded new revision
2018-09-30
00 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2018-09-17
00 Bron Gondwana
1. This document is being requested as an Internet Standard because it
extends an existing Internet Standard (RFC3501).  The request type is
indicated …
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.
2018-09-17
00 Bron Gondwana Responsible AD changed to Alexey Melnikov
2018-09-17
00 Bron Gondwana IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2018-09-17
00 Bron Gondwana IESG state changed to Publication Requested
2018-09-17
00 Bron Gondwana IESG process started in state Publication Requested
2018-09-17
00 Bron Gondwana Changed document writeup
2018-08-10
00 Bron Gondwana Changed document writeup
2018-08-10
00 Bron Gondwana Have to re-add all the state now it's been replaced with a WG doc!
2018-08-10
00 Bron Gondwana IETF WG state changed to In WG Last Call from WG Document
2018-08-10
00 Bron Gondwana Changed consensus to Yes from Unknown
2018-08-10
00 Bron Gondwana Intended Status changed to Proposed Standard from None
2018-08-10
00 Bron Gondwana Notification list changed to Bron Gondwana <brong@fastmailteam.com>
2018-08-10
00 Bron Gondwana Document shepherd changed to Bron Gondwana
2018-08-10
00 Bron Gondwana This document now replaces draft-brandt-imap-replace instead of None
2018-08-10
00 Stuart Brandt New version available: draft-ietf-extra-imap-replace-00.txt
2018-08-10
00 (System) WG -00 approved
2018-08-08
00 Stuart Brandt Set submitter to "Stuart Brandt ", replaces to (none) and sent approval email to group chairs: extra-chairs@ietf.org
2018-08-08
00 Stuart Brandt Uploaded new revision