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

From: [email-masked]
Date: Sun, 7 Nov 2004 17:32:36 -0600

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Sunday, November 07, 2004 11:24 AM
...
> >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.
...
> Does the CHECKPOINT extension try to address # 2. If it does - how?

CHECKPOINT combined with CLEARIDLE addresses #2. An IDLE CHECKPOINT command is issued in the authenticated state. The responses defined in CLEARIDLE then include imap urls. This in effect does not require the N SELECTs to visit each folder.

Note that N*M based resyncs are stilled required at certain reconnects, but they should be less frequent.

...
> 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.

It allows responses with IMAPURLs to be shared. Correct me if I'm wrong but an IMAPURL basically allows one to export information from one session to another. Is this not what URLAUTH does when used with BURL.

> 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 main differences between CONDSTORE are:
1) Expunge support 
2) Folder change support
3) It works from the authenticated state and therefore does not require the folder SELECT iteration.

...
> 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))
> 

Here is the difference. CHECKPOINT sends responses quasi-real-time, which means that one of it's goals is to maximize the response time at the client. It is greedy in the sense that information is sent as soon as it is available. When it is disconnected it may have the characteristic you mention, but it does not need to An implementation could perform the response aggregation you mention.

Mike

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Nov 2004 12:35:47 +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:
>>
Which is #1. It doesn't affect N*M (actually M1+M2+...MN), because if 
there are changes to Mi messages in mailbox i, one has to fetch/process 
Mi responses anyway.

>It allows responses with IMAPURLs to be shared. Correct me if I'm wrong but an IMAPURL basically allows one to export information from one session to another. Is this not what URLAUTH does when used…
Yes, but the person who generates an URLAUTH *authorizes* somebody else 
to use it. The draft as written may give an impression that all users 
are notified about all messages arriving for all users. Basically what 
you are proposing is even worse from security standpoint than the 
URLAUTH. An URLAUTH URL just gives information about message existence. 
CLEARIDLE FETCH replies might also contain messages subject and other 
sensitive information.

>3) It works from the authenticated state and therefore does not require the folder SELECT iteration.
(CLEARIDLE is needed to address # 3. I was comparing only CONDSTORE and 
CHECKPOINT)

I might agree that 2 and 3 are worth solving, but this is not a job for 
CONDSTORE or CHECKPOINT (it seems to belong to CLEARIDLE). As I 
mentioned before, #1 is already addressed in RECONNECT, although 
arguable it should be a separate extension to the CONDSTORE extension.

>Here is the difference. CHECKPOINT sends responses quasi-real-time, which means that one of it's goals is to maximize the response time at the client. It is greedy in the sense that information is sent as soon as it is available. When it is disconnected it may have the characteristic you mention, but it does not need to. An implementation could perform the response aggregation you mention.
>  
>
This is not clear from you document, if I understood the CHECKPOINT 
properly, the server is not allowed to skip responses.

Alexey