Re: Disconnected support and UIDs again

[Bart Schaefer <[e-mail]>]

On Sep 19,  8:40am, Barry Leiba (Multimedia Messaging) wrote:
} Subject: Disconnected support and UIDs again
}
} OK, I've worked through this on my white board for a while now, leaving it and
} coming back to it and trying to see what Mark intends, but I just don't see 
} it.  Mark, perhaps you could explain to all of us, clearly, how you expect a 
} client, fully on its own and with no help from the server or the spec, to 
} implement disconnected support.  Here's a scenario that has to work, and I 
} don't see how it can.  Maybe you can explain what you intend and show us that 
} the spec, as written, will allow a sure implementation of it.
} 
} (5) JC changes message UID:51 while disconnected.
} (6) MC changes message UID:51 while disconnected.
} (7) JC reconnects and "replaces" UID:51.  This really means that JC creates a 
} new message with UID 63, and deletes message UID:51.
} 
} It's important that MC be able to recognize that UID:63 is an updated
} version of what used to be UID:51.  How does it do that?

Maybe you can explain, clearly, why this scenario "has to work".  I can't
find any indication in the various documents describing disconnected IMAP
usage that leads me to believe support for this scenario was intended.

IMAP is not designed to permit revision control of shared drafts; it is
intended to detect additions/moves/deletions of entire messages, not of
the internals of any given message.

That said, I refer you to the (expired) draft on disconnected operations:

http://andrew2.andrew.cmu.edu/cyrus/rfc/draft-ietf-imap-disc-01.html

Therein, see 8. SPECIAL CASE: OPTIMIZING "MOVE" OPERATIONS

What you've effectively done in the scenario above is to move the message
to another folder (JC's cache) and then move it back to the original
folder.  MC now wants to detect this.  How MC detects that other changes
were made in the contents of the message in the process, is entirely
outside the IMAP specification.

Further, *because* it is outside the IMAP specification, you can have no
reasonable expectation that JC is going to be able to detect the changes
made by MC when MC reconnects and uploads.  In fact, you *should* expect
that JC will think that the "new" message is unchanged and thus will not
bother to download it!

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"