Subject: [apps-discuss] Fwd: Proposal for a new IMAP Working Group to revise CONDSTORE & QRESYNC

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Mar 2013 15:02:19 +0000

Hi,
I've posted a proposal for a new IMAP-related WG. If you are interested 
in the topic, please follow-up on [email-masked].

Thank you,
Alexey

-------- Original Message --------
Subject: 	Proposal for a new IMAP Working Group to revise CONDSTORE & 
QRESYNC
Date: 	Tue, 05 Mar 2013 14:57:25 +0000
From: 	Alexey Melnikov <[email-masked]>
To: 	[email-masked] <[email-masked]>

Hi,
I've noticed some surge in activity related to implementing CONDSTORE
(RFC 4551)/QRESYNC (RFC 5162) in both clients and servers, so I drafted
a new WG charter proposal to update/clarify these:

-----------
The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for accessing email messages on a server
that implements a message store from a client. It also includes
commands for manipulating the message store -- creating, deleting, and
renaming mailboxes, adding a message to a mailbox, and copying
messages from one mailbox to another.

Base IMAP as described in RFC 3501 requires that in order to discover
flag changes and expunged messages in a mailbox, the client has to
fetch flags for all messages it knows in the mailbox and compare returned
results with its own state. This can generate a significant amount of
traffic for big mailboxes.

The IMAP CONDSTORE extension (RFC 4551) provides a facility for IMAP
clients to quickly resynchronize mailbox flag changes in a mailbox.
The IMAP QRESYNC extension (RFC 5162) extended CONDSTORE to also
cover expunged messages and reduced the number of round trips needed
to resynchronize by extending the SELECT/EXAMINE command.
Both extensions seen deployment in both clients and servers.
These deployments has exposed errors and clarity issues in the
specifications, which need correcting.

The IMAP QRESYNC extension (imapqresync) working group has the task
of updating CONDSTORE and QRESYNC extensions as Proposed Standards.
The working group might produce one (combined) or two separate
documents (as now) updating these extensions. The working group will
review errata and update the documents as needed to incorporate those,
and will correct significant errors and inconsistencies, but will keep
changes at this stage to a minimum. In the event that implementation
experience would dictate an incompatible change to one (or both) of
these extensions, the corresponding IMAP capability identifiers would
be changed.

No other IMAP extension work is in scope for this working group.
---------

So please comment on whether you think this work is worth doing and on
the proposed charter text.

I've also posted a new version of RFC 5162bis
(http://tools.ietf.org/html/draft-melnikov-5162bis-01), which addressed
most (but not all) of existing errata on the document. If a new WG is to
be formed, I propose that the document is used as one of the initial
documents.

Thank you,
Alexey