Subject: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues)

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Nov 2004 16:24:05 +0000

[email-masked] wrote:

>I do not believe the current set of drafts address directly the primary mobile synchronization issues. I believe a full solution must cover:
>1) Multi-Folder monitoring
>2) Mitigate the N*M algorithm typically used at sync time.
>  
>
>3) Folder events
>4) Expunge Events
>5) New mail events
>6) Smoothed connection loss caused by the carrier
>7) Reduce the set of visible messages per folder
>
>
>Below are the personal drafts that address these issues along with their abstracts. A goal of these drafts was to address the problem specifically with a minimum of variation from the current IMAP RFCs. Clearidle and Checkpoint address the first 6 above.
>
Does the CHECKPOINT extension try to address # 2. If it does - how?

> Number 7 is addressed by Msgfilter.
>
>Clearidle (See attached)
>   The IMAPRev4 specification supports unsolicited responses being sent
>   to a client at any time. The IDLE specification defines a way for a 
>   client to sit in an idle connection waiting to receive these 
>   responses. This document clarifies and extends the set of responses 
>   that a client may receive while in the idle state. The desire is to 
>   allow a client to predict exactly what set of unsolicited responses 
>   it can rely on receiving when listening on an idle connection.
>
I will send my comments on this document separately.

>
>http://www.ietf.org/internet-drafts/draft-wener-lemonade-checkpoint-00.txt
>   This document describes an IMAP extension that aids in allowing a 
>   client to maintain mailbox synchronization without performing a deep
>   sync after each connection. The goal is to minimize, but not 
>   eliminate, the need for deep synchronizations. The extension defines
>   a way for a client to receive and acknowledge state change responses
>   from the server.
>
I've tried to understand details of the CHECKPOINT extension, however I 
don't think I was very successful. (Hopefully I got the basic idea, 
correct me if I've misunderstood something). The main reason for that, 
IMHO, is because the document makes many assumptions about what the 
extension is trying to do, but those assumptions are not clearly stated 
anywhere in the document. And the assumptions look definitely different 
from my understanding of the IMAP model. For example, the extension 
assumes that unsolicited responses sent to multiple clients can be 
shared between all of them. I actually strongly disagree, a user Foo 
must not be allowed to get responses for the user Bar. If it was not 
your intent, the document must be clarified that only responses for the 
same user are shared.

I also didn't like some syntactical constructs that you were using, but 
this is minor.

The CHECKPOINT extension pretty much tries to do everything that the 
CONDSTORE extension can already do (with exception of notifying about 
expunged messages, which is addressed in the latest RECONNECT draft), 
although in a slightly different way.
The CONDSTORE extension doesn't dictate how it can be implemented, one 
can use a queue of responses (as CHECKPOINT does).

Now, CHECKPOINT requires that all sessions receive exactly the same 
responses. CONDSTORE is a bit more smart on this. For example, let's 
imagine that the \Seen flag was set on the message 4 and then later on 
the \Deleted flag was also set. The CHECKPOINT will send:

   S: * 4 FETCH (FLAGS (\Recent \Seen)) (1006)
   ...
   S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted)) (1054)

The CONDSTORE only requires a single response:

   S: * 4 FETCH (FLAGS (\Recent \Seen \Deleted) MODSEQ (1054))

(observe that "a CHECKPOINT response number" can be the same as 
CONDSTORE "modification sequence").

Alexey

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Nov 2004 17:18:22 +0000

[Also crossposting this to IMAPEXT.]

> it can rely on receiving when listening on an idle connection.

One thing the needs discussing is whether the problem of receiving flag 
changes/new mail notifications for multiple mailboxes (over a single 
connection) is worth solving. I frankly don't know for sure.

I will try to emphasize some specific technical issues with this document.

 >2.1 LIST Response
 >
 >   Currently the LIST response occurs as the result of a LIST command.
 >   This document modifies the syntax of a LIST response and also defines
 >   it's occurrence as a legal unsolicited response that could be received
 >   on IDLE connections associated with a user.
 >
 >   Two new name attributes are defined:
 >
 >   \Deleted
 >       The mailbox has been deleted and no longer exists. After a LIST
 >       response with this attribute is seen the server will no longer
 >       show the named folder in any LIST commands. There MUST NOT be
 >       any other name attributes sent along with this attribute.

I suggest you review the LISTEXT extension (currently 
draft-ietf-imapext-list-extensions-10.txt).
\Deleted is the same as \NonExistent.

 >   \Renamed
 >       The mailbox has been renamed. A second LIST response MUST
 >       immediately follow indicating the new name.
[...]
 >     3) If a folder is renamed two LIST responses are sent. The first
 >     indicating the old name and a \Renamed attribute and a second
 >     response MUST immediately follow the first indicating the new name.

This might be less obvious for people not following IMAPEXT, but there 
was a proposal to have REFERRAL data returned in LIST responses. It 
serves exactly this purpose. See 
<http://www.imc.org/ietf-imapext/mail-archive/msg01921.html>, item # 5.
It also avoids the proposed hack (sorry, I can't find a better word) of 
tying two LIST responses together.

 >2.2 FETCH Response
 >
 >   Currently the FETCH response occurs as the result of a FETCH command
 >   or as an unsolicited response on an IDLE connection. This document
 >   clarifies exactly what form of response should be sent when the
 >   specified events occur on the server.
[...]
 >   New Message Arrival      
 >       An unsolicited FETCH response with envelope, body, flag and uid
 >       data MUST be sent on all IDLE connections.
 >
 >       Example:
 >          S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...))

Actually no, BODY must not be in this list, as it is potentially very 
big. You surely wouldn't want to push a 10Mb message to you cell phone.
I also suggest to replace the ENVELOPE with the BODYSTRUCTURE.

 >3.1.1 Mailbox Identification Syntax
 >
 >   While in the Authenticated state there is no way to implicitly
 >   determine which mailbox the response applies to. While this is not a
 >   problem for some responses such as the LIST response it does pose a
 >   problem for responses that are mail message specific.
[...]
 >   Example:
 >      S: * 22 EXISTS (imap://mail/inbox)

Why can't we just you the STATUS response?

        S: * STATUS INBOX (MESSAGES 231 RECENT 7)

Alexey

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 07 Nov 2004 16:28:28 -0800

--On 2004-11-7 5:18 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>
> One thing the needs discussing is whether the problem of receiving
> flag changes/new mail notifications for multiple mailboxes (over a
> single connection) is worth solving. I frankly don't know for sure.

It has been brought up enough times over the last five years that I am
convinced it is. I wrote a non-published draft a few years back that
proposed a solution to the multiple-mailbox newmail notification 
problem.
And since the issue has come up once again over the last few months I 
have
updated the draft and will submit it after the IETF.

--lyndon