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

From: Stephane Maes <[email-masked]>
Date: Sun, 7 Nov 2004 12:32:23 -0700

In my view CHECKPOINT + CLEARIDLE try to achieve the same as CONDSTORE but monitoring more changes.

What is the status of CONDSTORE. Can't the additional diff items be added to CONDSTORE at IMAP Ext?

Stephane
_____
Stephane H. Maes, PhD,
Director of Architecture - Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM, Y!) or [email-masked] (MSN Messenger) 

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
CC: [email-masked] <[email-masked]>
Sent: Sun Nov 07 09:24:05 2004
Subject: [lemonade] Comments about CHECKPOINT (was Re: Mobile synchronization issues)

[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

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

---

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

>In my view CHECKPOINT + CLEARIDLE try to achieve the same as CONDSTORE but monitoring more changes.
Yes ("CONDSTORE + some bits of RECONNECT").

>What is the status of CONDSTORE.
>
It is an approved document (1 year now). However it depends on yet not 
finished document, that is why there is no RFC #.

> Can't the additional diff items be added to CONDSTORE at IMAP Ext?
>  
>
We can always specify an extension. Under extreme circumstances, we can 
try to revise CONDSTORE before it gets published. What kind of addition 
are you thinking about.

---

From: Stephane Maes <[email-masked]>
Date: Sun, 7 Nov 2004 12:42:45 -0700

Support the changed that Michael proposes the monitor in his drafts.

Stephane
_____
Stephane H. Maes, PhD,

---

From: [email-masked]
Date: Mon, 8 Nov 2004 18:48:24 -0600

> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Monday, November 08, 2004 9:28 AM
...
> >
> >The draft does state that the queueing is associated with an 
> >authenticated session.
> >  
> >
> The term "authenticated session" is what causes the most 
> confusion for 
> me. What does it mean?

It is a poor way of saying the queue is associated with an 
authenticated user. I'll clarify.

..
> >I tend to consider CHECKPOINT/CLEARIDLE as a combined solution.
> >  
> >
> I see a value of having them separate (e.g. I don't see why CONDSTORE 
> can't be used with CLEARIDLE), however the boundary between 
> the two must 
> be more explicit.

I also saw value in having them separate.

I would restate to say the relationship needs to be clarified. 
Both their distinctions, and how they compliment each other.

Mike