Skip to main content

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 2683RFC 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 2683RFC 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