IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)
draft-ietf-qresync-rfc5162bis-10
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-02-22
|
10 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2018-12-20
|
10 | (System) | Received changes through RFC Editor sync (changed abstract to 'Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP … Received changes through RFC Editor sync (changed abstract to 'Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162. Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.') |
|
2017-06-30
|
10 | (System) | Received changes through RFC Editor sync (added Errata tag) |
|
2015-10-14
|
10 | (System) | Notify list changed from qresync-chairs@ietf.org, draft-ietf-qresync-rfc5162bis@ietf.org to (None) |
|
2014-05-23
|
10 | (System) | RFC published |
|
2014-05-22
|
10 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7162">AUTH48-DONE</a> from AUTH48 |
|
2014-05-06
|
10 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7162">AUTH48</a> from RFC-EDITOR |
|
2014-04-28
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2014-03-14
|
10 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
|
2014-03-04
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2014-03-03
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2014-03-02
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2014-02-25
|
10 | (System) | IANA Action state changed to In Progress |
|
2014-02-25
|
10 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2014-02-24
|
10 | (System) | RFC Editor state changed to EDIT |
|
2014-02-24
|
10 | (System) | Announcement was received by RFC Editor |
|
2014-02-24
|
10 | Barry Leiba | Notification list changed to : qresync-chairs@tools.ietf.org, draft-ietf-qresync-rfc5162bis@tools.ietf.org |
|
2014-02-24
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2014-02-24
|
10 | Cindy Morgan | IESG has approved the document |
|
2014-02-24
|
10 | Cindy Morgan | Closed "Approve" ballot |
|
2014-02-24
|
10 | Cindy Morgan | Ballot approval text was generated |
|
2014-02-20
|
10 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
|
2014-02-20
|
10 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
|
2014-02-20
|
10 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
|
2014-02-20
|
10 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
|
2014-02-20
|
10 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
|
2014-02-20
|
10 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
|
2014-02-19
|
10 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
|
2014-02-19
|
10 | Spencer Dawkins | [Ballot comment] This is a question, not a request for a text change. In section 4. Long Command Lines (Update to RFC 2683), does … [Ballot comment] This is a question, not a request for a text change. In section 4. Long Command Lines (Update to RFC 2683), does this work because the only implementations using command lines longer than 1000 bytes are using them to implement this spec? I wasn't completely comfortable updating RFC 2683 in a document that's mostly defining new extensions, wondering if that update would be visible enough to implementers who weren't reading this spec. I'm just majing sure I'm wrong about that ... |
|
2014-02-19
|
10 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
|
2014-02-19
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Phillip Hallam-Baker. |
|
2014-02-19
|
10 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
|
2014-02-19
|
10 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
|
2014-02-18
|
10 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
|
2014-02-18
|
10 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
|
2014-02-17
|
10 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
|
2014-02-17
|
10 | David Black | Request for Telechat review by GENART Completed: Ready. Reviewer: David Black. |
|
2014-02-13
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
|
2014-02-13
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
|
2014-02-04
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2014-02-04
|
10 | Barry Leiba | Ballot has been issued |
|
2014-02-04
|
10 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
|
2014-02-04
|
10 | Barry Leiba | Created "Approve" ballot |
|
2014-02-04
|
10 | Barry Leiba | Placed on agenda for telechat - 2014-02-20 |
|
2014-02-04
|
10 | Barry Leiba | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
|
2014-01-30
|
10 | Alexey Melnikov | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2014-01-30
|
10 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-10.txt |
|
2014-01-27
|
09 | David Black | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: David Black. |
|
2014-01-27
|
09 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call (ends 2014-01-27) |
|
2014-01-22
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
|
2014-01-22
|
09 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-qresync-rfc5162bis-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-qresync-rfc5162bis-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the IMAP Capabilities Registry located at: http://www.iana.org/assignments/imap4-capabilities the reference for the capabilities CONDSTORE and QRESYNC will be updated to point to [ RFC-to-be ]. IANA 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 only to confirm what actions will be performed. |
|
2014-01-17
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Frascone |
|
2014-01-17
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Frascone |
|
2014-01-16
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2014-01-16
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2014-01-16
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
|
2014-01-16
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
|
2014-01-13
|
09 | Barry Leiba | Notification list changed to : qresync-chairs@tools.ietf.org, draft-ietf-qresync-rfc5162bis@tools.ietf.org, imapext@Ietf.org |
|
2014-01-13
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2014-01-13
|
09 | Cindy Morgan | The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <imapext@ietf.org> Reply-To: ietf@ietf.org Sender: … The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <imapext@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-qresync-rfc5162bis-09.txt> (IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)) to Proposed Standard The IESG has received a request from the IMAP QRESYNC Extension WG (qresync) to consider the following document: - 'IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)' <draft-ietf-qresync-rfc5162bis-09.txt> 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 2014-01-27. 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 Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, The Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. Hence this memo obsoletes RFC 5162. Finally, this document also updates the line length recommendation in Section 3.2.1.5 of RFC 2683. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2014-01-13
|
09 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
|
2014-01-13
|
09 | Barry Leiba | Last call was requested |
|
2014-01-13
|
09 | Barry Leiba | Last call announcement was generated |
|
2014-01-13
|
09 | Barry Leiba | Ballot approval text was generated |
|
2014-01-13
|
09 | Barry Leiba | State changed to Last Call Requested from AD Evaluation |
|
2014-01-13
|
09 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-09.txt |
|
2014-01-09
|
08 | Barry Leiba | Ballot writeup was changed |
|
2014-01-09
|
08 | Barry Leiba | Ballot writeup was generated |
|
2014-01-09
|
08 | Barry Leiba | 1. Summary Eliot Lear is the shepherd. Barry Leiba is the Area Director. This document rolls together two sets of changes, one for CONDSTORE and … 1. Summary Eliot Lear is the shepherd. Barry Leiba is the Area Director. This document rolls together two sets of changes, one for CONDSTORE and one for QRESYNC, for the IMAP protocol. Errata have been addressed, as well as a small number of technical issues with the existing RFCs 4551 and 5162. The document is intended to obsolete both documents. Its status should be Proposed Standard, although it should be possible to elevate it relatively soon. 2. Review and Consensus Along with the shepherd, several implementors reviewed the document and came to consensus. This discussion caught an issue relating to mod-sequence-value. More than rough consensus exists, and this is a fairly uncontroversial document. An apps directorate review was performed. All issues were resolved. 3. Intellectual Property Each author has confirmed their conformance with BCPs 78 and 79. There are no IPR disclosures that the shepherd is aware of. The document contains a pre-5378 disclaimer because it contains text from four earlier RFCs, representing four authors that have not been contacted. At least two of them cannot be contacted. 4. Other Points There is a downref from this document to RFC 2683. RFC 2683 provides for commonly accepted implementation recommendations. The reason for the downrefis is that this document updates the line length limit. A familiarity with 2863 is therefore important to understand this discussion for purposes of implementation. The wiki has been updated accordingly. As this is an update, IANA is requested to update the imap4-capabilities registry to point to it instead of the documents it is obsoleting. |
|
2014-01-09
|
08 | Barry Leiba | State changed to AD Evaluation from Publication Requested |
|
2014-01-07
|
08 | Eliot Lear | IETF WG state changed to Submitted to IESG for Publication |
|
2014-01-07
|
08 | Eliot Lear | IESG state changed to Publication Requested |
|
2014-01-07
|
08 | Eliot Lear | AD requested the wiki template be used. It is now below: >== Document Writeup == > >As required by RFC 4858, this is the … AD requested the wiki template be used. It is now below: >== Document Writeup == > >As required by RFC 4858, this is the current template for the document >shepherd write-up. > >Changes are expected over time. This version is dated [under >revision]. 7 Jan. 2014 > >The intent of this writeup is to give information to the IESG and the >community. We expect it to be informative, rather than being a set of >rote questions and answers. Please be free about using it to provide >information about discussions, controversies, resolutions, and >decisions that were had and made with respect to the document. The >writeup is divided into four sections, and each section's response >should consist of a paragraph or two that covers the topics for that >section. Of course, if more information is needed, include more >information. > >Note that this writeup will be posted publicly. If there is >information that the IESG should know that would be better discussed >privately, send it in a separate email message to the responsible Area >Director. > >=== 1. Summary === > > Who is the document shepherd? Who is the responsible Area Director? Eliot Lear is the shepherd. Barry Leiba is the Area Director. > > Explain briefly what the intent of the document is (the document's > abstract is usually good for this), and why the working group has > chosen the requested publication type (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic). This document roles together two sets of changes, one for CONDSTORE and one for QRESYNC for the IMAP protocol. Errata have been addressed, as well as a small number of technical issues with the existing RFCs 4551 and 5162. The document is intended to obsolete both documents. Its status should be Proposed Standard, although it should be possible to elevate it relatively soon. > >=== 2. Review and Consensus === > > Explain how actively the document was reviewed and discussed, by the > working group and external parties, and explain in a general sense > how much of the interested community is behind the document. > Explain anything notable about the discussion of the document. Along with the shepherd, several implementors reviewed the document and came to consensus. This discussion caught an issue relating to mod-sequence-value. More than rough consensus exists, and this is a fairly uncontroversial document. An apps directorate review was performed. All issues were resolved. >=== 3. Intellectual Property === > > Confirm that each author has stated that their direct, personal > knowledge of any IPR related to this document has already been > disclosed, in conformance with BCPs 78 and 79. Explain briefly the > working group discussion about any IPR disclosures regarding this > document, and summarize the outcome. Confirmed. There are no IPR disclosured that I am aware of. > >=== 4. Other Points === > > Note any downward references (see RFC 3967) and whether they appear > in the DOWNREF Registry > (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), > as these need to be announced during Last Call. There is a downref from this document to RFC 2683. RFC 2683 provides for commonly accepted implementation recommendations. The reason for the downrefis is that this document updates the line length limit. A familiarity with 2863 is therefore important to understand this discussion for purposes of implementation. The wiki has been updated accordingly. > > Check the IANA Considerations for clarity and against the checklist > below. Note any registrations that require expert review, and say > what's been done to have them reviewed before last call. Note any > new registries that are created by this document and briefly > describe the working group's discussion that led to the selection of > the allocation procedures and policies (see RFC 5226) that were > selected for them. If any new registries require expert review for > future allocations, provide any public guidance that the IESG would > find useful in selecting the designated experts (private comments > may be sent to the Area Director separately). As this is an update, IANA is requested to update the imap4-capabilities registry to point to it instead of the documents it is obsoleting. > > Explain anything else that the IESG might need to know when > reviewing this document. If there is significant discontent with > the document or the process, which might result in appeals to the > IESG or especially bad feelings in the working group, explain this > in a separate email message to the responsible Area Director. > No issues. > >=== Checklist === > >This section is not meant to be submitted, but is here as a useful >checklist of things the document shepherd is expected to have verified >'''before''' publication is requested from the responsible Area >Director. If the answers to any of these is "no", please explain the >situation in the body of the writeup. > > * Does the shepherd stand behind the document and think the document > is ready for publication? > Yes. > * Is the correct RFC type indicated in the title page header? Yes. > * Is the abstract both brief and sufficient, and does it stand alone > as a brief summary? It is a hair long, but okay considering it is combining two documents. > > * Is the intent of the document accurately and adequately explained > in the introduction? Yes. > * Have all required formal reviews (MIB Doctor, Media Type, URI, > etc.) been requested and/or completed? Yes. > * Has the shepherd performed automated checks -- idnits (see > http://www.ietf.org/tools/idnits/ and the Internet-Drafts > Checklist), checks of BNF rules, XML code and schemas, MIB > definitions, and so on -- and determined that the document passes > the tests? (In general, nits should be fixed before the document > is sent to the IESG. If there are reasons that some remain (false > positives, perhaps, or abnormal things that are necessary for this > particular document), explain them.) Any remaining idnits are due to IMAP syntax in examples. > * Has each author stated that their direct, personal knowledge of any > IPR related to this document has already been disclosed, in > conformance with BCPs 78 and 79? > Yes. > * Have all references within this document been identified as either > normative or informative, and does the shepherd agree with how they > have been classified? RFC2683 needs to be normative. See above. > * Are all normative references made to documents that are ready for > advancement and are otherwise in a clear state? n/a. > * If publication of this document changes the status of any existing > RFCs, are those RFCs listed on the title page header, and are the > changes listed in the abstract and discussed (explained, not just > mentioned) in the introduction? Yes. > > * If this is a "bis" document, have all of the errata been > considered? Yes. > > * IANA Considerations: > * Are the IANA Considerations clear and complete? Remember that > * IANA have to understand unambiguously what's being requested, so > * they can perform the required actions. Yes. > * Are all protocol extensions that the document makes associated > * with the appropriate reservations in IANA registries? Yes. > * Are all IANA registries referred to by their '''exact''' names > * (check them in http://www.iana.org/protocols/ to be sure)? All one. > * Have you checked that any registrations made by this document > * correctly follow the policies and procedures for the appropriate > * registries? No changes other than the reference within the registry is requested. > * For registrations that require expert review (policies of Expert > * Review or Specification Required), have you or the working group > * had any early review done, to make sure the requests are ready > * for last call? n/a > * For any new registries that this document creates, has the > * working group actively chosen the allocation procedures and > * policies and discussed the alternatives? Have reasonable > * registry names been chosen (that will not be confused with those > * of other registries), and have the initial contents and valid > * value ranges been clearly specified? n/a |
|
2014-01-07
|
08 | Eliot Lear | State Change Notice email list changed to qresync-chairs@tools.ietf.org, draft-ietf-qresync-rfc5162bis@tools.ietf.org |
|
2014-01-07
|
08 | Eliot Lear | Responsible AD changed to Barry Leiba |
|
2014-01-07
|
08 | Eliot Lear | Working group state set to Submitted to IESG for Publication |
|
2014-01-07
|
08 | Eliot Lear | IESG state set to Publication Requested |
|
2014-01-07
|
08 | Eliot Lear | IESG process started in state Publication Requested |
|
2014-01-07
|
08 | Eliot Lear | Tag Doc Shepherd Follow-up Underway cleared. |
|
2014-01-07
|
08 | Eliot Lear | This document now replaces draft-melnikov-5162bis, draft-ietf-qresync-rfc4551bis instead of draft-melnikov-5162bis |
|
2014-01-07
|
08 | Eliot Lear | Changed document writeup |
|
2014-01-07
|
08 | Eliot Lear | Tag Doc Shepherd Follow-up Underway set. |
|
2014-01-07
|
08 | Eliot Lear | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2014-01-07
|
08 | Eliot Lear | Changed consensus to Yes from Unknown |
|
2014-01-07
|
08 | Eliot Lear | Intended Status changed to Proposed Standard from None |
|
2014-01-07
|
08 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-08.txt |
|
2014-01-07
|
07 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-07.txt |
|
2013-12-19
|
06 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-06.txt |
|
2013-12-16
|
05 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-05.txt |
|
2013-12-09
|
04 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-04.txt |
|
2013-12-02
|
03 | Dave Cridland | IETF WG state changed to In WG Last Call from WG Document |
|
2013-12-02
|
03 | Dave Cridland | Document shepherd changed to Eliot Lear |
|
2013-10-08
|
03 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-03.txt |
|
2013-07-02
|
02 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-02.txt |
|
2013-07-01
|
01 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-01.txt |
|
2013-05-30
|
00 | Alexey Melnikov | New version available: draft-ietf-qresync-rfc5162bis-00.txt |