Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-05.txt

From: [email-masked]
Date: Mon, 16 Dec 2013 10:50:40 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IMAP QRESYNC Extension Working Group of the IETF.

	Title           : IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)
	Author(s)       : Alexey Melnikov
                          Dave Cridland
	Filename        : draft-ietf-qresync-rfc5162bis-05.txt
	Pages           : 49
	Date            : 2013-12-16

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 synchronize state
   changes for messages within the mailbox.  They must be able to
   guarantee that only one client can change message state (e.g.,
   message flags of the specific message being looked up) at any time.
   An example of such an application is use of an IMAP mailbox as a
   message queue with multiple dequeueing clients.

   The Conditional Store facility provides a protected update mechanism
   for message state information that can detect and resolve conflicts
   between multiple writing mail clients.

   The Conditional Store facility also allows a client to quickly
   resynchronize mailbox flag changes.

   This document additionally defines another IMAP extension, which
   gives an IMAP client the ability to quickly resynchronize any
   previously opened mailbox as part of the SELECT command, without the
   need for server-side state or additional client round-trips.  This
   extension also introduces a new response that allows for a more
   compact representation of a list of expunged messages (and always
   includes the Unique Identifiers (UIDs) expunged).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Dec 2013 19:01:21 +0000

Hi everybody,

> 	Filename        : draft-ietf-qresync-rfc5162bis-05.txt
This version addresses all known issues (include 63-bit mod-sequences) 
other than rewrite of the Abstract and the Introduction.

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 17 Dec 2013 22:07:41 +1100

> other than rewrite of the Abstract and the Introduction.

The wording on the section I was concerned about looks good now.

...and there's nothing in here that would cause problems for what we're doing at
FastMail now, where there's a single HIGHESTMODSEQ counter across all mailboxes,
and the per-mailbox one just grabs that (+1) for a new per-mailbox HIGHESTMODSEQ
when it makes any changes - meaning we can track a single value to know if there
were changes anywhere for that user, and trigger a STATUS check.

We're also using list extended syntax to get the STATUS fields in a single LIST
command, which allows very fast resync - because we get an updated folder list
each time as well, rather than pipelining STATUS commands for known folders.

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Dec 2013 22:11:14 +0000

> each time as well, rather than pipelining STATUS commands for known folders.
Sounds great. If you want to define an extra IMAP capability for 
server-wide MODSEQs, I can add it to the document.