Re: IMAP4 disconnected use draft

"James H. Thompson - HNL" <JIMMY_T@verifone.com> Tue, 21 June 1994 04:50 UTC

Errors-To: owner-imap@cac.washington.edu
Date: Mon, 20 Jun 1994 18:37:11 -1000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "James H. Thompson - HNL" <JIMMY_T@verifone.com>
Subject: Re: IMAP4 disconnected use draft
To: MRC@cac.washington.edu
Cc: IMAP@cac.washington.edu
Message-Id: <01HDRW842KVM94KZ2O@verifone.com>
Organization: VeriFone
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-Transfer-Encoding: 7bit

> 
> The initial very rough version of the IMAP4 disconnected use draft is now
> online on ftp.cac.washington.edu in the file
> 	mail/draft-ietf-imap-disc-00.txt
> 
> Please review this document.  It is very much a first draft, but it is being
> released now for maximum dissemination.  Please send comments to the IMAP
> list.
> 

> 1. DESIGN PRINCIPLES
> 
>    All mailbox state or content information stored on the disconnected
>    client should be viewed strictly as a cache of the state of the
>    server.  The "master" state remains on the server, just as it would

If the client supports local mailboxes, or if the client supports
operations like "delete on server but not local" then the above
would not be true.  

>    b) The set of "interesting" mailboxes pretty much has to be
>       determined by the human.  What mailboxes belong to this set may
>       vary between different IMAP4 sessions with the same server,
>       client, and human.

I would hope for a quick way to get a list of what mailboxes have
changed (new messages or changed old messages) since the last client session.

>    With no further information, the client can issue issue the following
>    two commands:
>       tag1 UID FETCH <lastseen+1>:* <descriptors>
>       tag2 UID FETCH 1:<lastseen> FLAGS

The second command would not be workable for many of our users that maintain
several thousand messages in a mailbox (they often have multiple mailboxes like
this).  It would take forever to find out that one message out of a thousand
had changed.

> 7. SPECIAL CASE: OPTIMIZING "MOVE" OPERATIONS
> 
>    Practical experience with IMAP, DMSP, and other mailbox access
>    protocols that support multiple mailboxes suggests that moving a
>    message from one mailbox to another is an extremely common operation.
>    In IMAP4 a "move" operation is really a combination of a COPY
>    operation and a STORE +FLAGS (\Deleted) operation.  This makes good
>    protocol sense for IMAP, but it leaves a simple-minded disconnected
>    client in the silly position of deleting and possibly expunging its

>    Fortunately, there is a relatively easy way around this problem.  By
...

If IMAP is going to support disconnected operation, wouldn't
it be better to change it to eliminate needing work arounds like
this that aren't even guaranteed to work?

Jim
+------------------------------------+--------------------------------------+
|  James H. Thompson                 |   jimmy_t@verifone.com    (Internet) |
|  VeriFone Inc.                     |   uunet!verifone!jimmy_t  (UUCP)     |
|  100 Kahelu Avenue                 |   808-623-2911            (Phone)    |
|  Mililani, HI 96789                |   808-625-3201            (FAX)      |
+------------------------------------+--------------------------------------+

IMAP4 disconnected use draft Mark Crispin
Re: IMAP4 disconnected use draft James H. Thompson - HNL
Re: IMAP4 disconnected use draft Rob Austein
Re: IMAP4 disconnected use draft Chris Newman
Re: IMAP4 disconnected use draft James H. Thompson - HNL