Subject: [imapext] Protocol Action: 'IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)' to Proposed Standard (draft-ietf-qresync-rfc5162bis-10.txt)

From: The IESG <[email-masked]>
Date: Mon, 24 Feb 2014 09:33:56 -0800

The IESG has approved the following document:
- 'IMAP Extensions for Conditional STORE Operation or Quick Flag Changes
   Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization
   (QRESYNC)'
  (draft-ietf-qresync-rfc5162bis-10.txt) as Proposed Standard

This document is the product of the IMAP QRESYNC Extension Working Group.

The IESG contact persons are Barry Leiba and Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/

Technical Summary

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.

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.

There is a downref from this document to RFC 2683, which provides
commonly accepted IMAP implementation recommendations.  This
document updates the recommendation about line-length limits.

Personnel

Eliot Lear is the shepherd.  Barry Leiba is the responsible Area Director.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 24 Feb 2014 13:57:14 -0800

> This document is the product of the IMAP QRESYNC Extension Working Group.

Congratulations and thanks for getting this done, everyone.  The
working group will remain officially active until the RFC is
published, for the unlikely case where something comes up during
AUTH48 (final RFC Editor editing and author approval) that needs to be
discussed with the working group.

Barry