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 |