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

From: [email-masked]
Date: Tue, 02 Jul 2013 06:54:54 -0700

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           : IMAP4 Extensions for Quick Mailbox Resynchronization
	Author(s)       : Alexey Melnikov
                          Dave Cridland
	Filename        : draft-ietf-qresync-rfc5162bis-02.txt
	Pages           : 25
	Date            : 2013-07-02

Abstract:
   This document defines an IMAP4 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-02

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

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

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 2 Jul 2013 20:02:25 +0300

> If at least one message got expunged and QRESYNC was enabled,
>    the server MUST send the updated per-mailbox modification sequence
>    using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the
>    tagged OK response.
> 
>    Example:    C: A202 EXPUNGE
>                S: * 3 EXPUNGE
>                S: * 3 EXPUNGE
>                S: * 5 EXPUNGE
>                S: * 8 EXPUNGE
>                S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
> 
>    Note: In this example the client hasn't enabled QRESYNC, so the
>    server is still using untagged EXPUNGE responses.  Note that the
>    presence of HIGHESTMODSEQ response code is optional in this case.

Since this is about implementing QRESYNC support, wouldn't it be easier and less confusing to remove most of this text and simply use an example using VANISHED?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Jul 2013 13:52:23 +0100

> Since this is about implementing QRESYNC support, wouldn't it be easier and less confusing to remove most of this text and simply use an example using VANISHED?
I was thinking about the section as being a complete replacement of the 
definition in RFC 3501.

I think it is important to point out that there are some conditions when 
EXPUNGE responses will still be used. How about reversing the order of 
examples (and possibly some extra clarifying text)?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 3 Jul 2013 15:56:23 +0200

On Wed, Jul 03, 2013 at 01:52:23PM +0100, Alexey Melnikov wrote:
> I was thinking about the section as being a complete replacement of
> the definition in RFC 3501.

In that case, you ought to completely replace EXPUNGE. Either you
extend or replace. Don't mix, please.

> I think it is important to point out that there are some conditions
> when EXPUNGE responses will still be used.

It's so much more pleasant to implement extensions when one can avoid
annoying this-or-that-it-depends semantics.

Arnt