Re: APPEND and UIDs (was "Results from IMC meeting")

[Mark Crispin <[e-mail]>]

On Wed, 21 Aug 96 19:39:46 -0400, Barry Leiba (Multimedia Messaging) wrote:
> I don't follow this, Mark; can you explain your model of reconnection for
> disconnected clients?

Did you read Austein's "SYNCHRONIZATION OPERATIONS FOR DISCONNECTED IMAP4
CLIENTS"?  It's on
	ftp://ftp.cac.washington.edu/mail/draft-ietf-imap-disc-01.txt

> Speaking as one who *has* actually implemented
> disconnected client support (in the IBM Workgroup product) I can say that it

> was more important that the equivalent of UID be immutable.

What do you mean by the "equivalent of UID"?

> If I take two clients away and each has a copy of the message with UID 1234,

> and then one client changes it and reconnects first, the result, as the
> IMAP4 spec is now, is that a new message gets appended with the changed text
> and a new UID, say 5432, and the old message with UID 1234 gets removed.
> Now the other client comes in and reconnects and sees that 1234 has gone
> away.  That client has no idea that 5432 is a replacement.

This isn't true.  The RFC 822 Message-ID is presumably the same, isn't it?

Now, let's consider the case where you can change the text in a UID:

	If I take two clients away and each has a copy of the
	message with UID 1234, and then one client changes it
	and reconnects first, the result is that a new message
	gets written with the same UID 1234.  Now the other
	client comes in and reconnects and sees that 1234 is
	still there.  That client has no idea that 1234 has changed.


> What would solve this is one of two things: an "original UID" attached to
> each message, which would remain the same throughout revisions of the
> message that got new UIDs; or else the UID stays the same and each message
> has a "last modified" timestamp.

Aren't we talking about RFC 822 Message-ID?

> The latter is what we used in IBM Workgroup; it was very
> easy for the client to take a timestamp at the beginning of the disconnect
> and then, on reconnect, ask the server what had changed since then.

In IMAP, if you recorded the highest known UID from the previous session, then
you know that all higher UIDs are new data since then.  So, suppose that the
previous session's highest UID was 1234.

We now start a new session.  The first possible new UID is 1235; UIDs are
strictly ascending so we know that a new 1212 could not have been created.  We
can quickly get all new UIDs with the command "FETCH 1235:* UID".

> The UID for a
> message always remained the same, even through revisions of the contents,
> and the way the disconnected client knew that it had to pick up new text was
> that the timestamp changed.

The way we discover this in IMAP is that there's a new UID.

> In fact, that there's no way to update a message without changing the UID is
> a tremendous hole in the IMAP4 protocol for the work that my group is
> currently doing with it.

I guess that one man's meat is another man's poison.