Subject: RE: [lemonade] VFolder and IMAP extended LIST command

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 21 Mar 2006 10:46:39 -0600

In the London joint meeting with OMA, we discussed the requirement to support client-to-client sync.  I don't know where in the past few meeting this has gone, if anywhere.  However, it seems to play here as well.

To restate by example, Imagine that my laptop with a thick client has cached most messsages from the server, including vitual views.  My diverses mobile device connects via bluetooth to my laptop and interacts with my email store to grab a copy of the messages received while sitting in this meeting.  When I closes the laptop and "go mobile", the mobile client connects via the more expensive and slower pipe to get new messages.

Besides being another case where the "desktop" client has a copy of all the vfolders, does this also require the GUID?  

Greg V.

-----Original Message-----
From: Philip Guenther [mailto:[email-masked]]
Sent: Tuesday, March 21, 2006 5:51 AM
To: Enhancements to Internet email to support diverse service
enivronments
Subject: Re: [lemonade] VFolder and IMAP extended LIST command 

Philip Guenther wrote:
>A protocol exists where containers hold mappings from name to unique
>ID, which may appear in multiple containers, and all actual data
>access is by unique ID.  It's called NFS.

Sorry, I was too opaque by stopping there.  I think there are number
of parallels and/or warnings we can take from the file-sharing world
when considering server-unique IDs for message.  To blather some...

NFSv[23] use opaque binary blobs as file-handles.  Simply put, they
are they are returned by directory lookup operations and then passed
to most other operations include 'read' and 'write'.  (That's an
oversimplification; read the RFC or /usr/include/rpcsvc/nfs_prot.x
on a UNIX box for the details.)

In NFS, access rights are enforced on each object.  This mean that
just having a file-handle isn't enough: your authenticated ID must
be authorized to access the object.  This is what lets the access
control work in the face of multiple access-paths for a given
file-handle.  This contrasts to IMAP, where the only standardized
access-control is at the level of mailboxes, not messages.  Whether
you can access a given message _is_ dependent on the access-path.
So, for a server to decide whether a request for message with
GOID=142857 should be permitted, it has to track the reverse mapping
of which mailboxes that message appears in and have an efficient
way of tracking the union of rights.  That's a _large_ constraint
on server implementations.

Making the IDs persistent has its own problems.  As a protocol, NFS
does not guarantee persistence of file-handles past unmount or
across server restarts.  That contrasts with AppleTalk Filing
Protocol (AFP), which has always(?) supported persistent IDs and
used them for various things.  The result of that decision has been
to make basically impossible implementing a portable and _correct_
AFP server that shares files from an existing filesystem.  Some
fairly good implementations exist, but I believe the all fudge the
persistence aspect in some way.  Again, supporting the particular
requirement (persistent IDs) places a large constraint on the
backend.

Anyway, I've now swung from too succinct to blathering.  My point
is that this is heading into parts of the design space that are
both (partially) mapped and treacherous.

Philip Guenther

_______________________________________________
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: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 21 Mar 2006 21:11:32 +0100

The easiest way to do this (which even works perfectly with plain IMAP 
servers) is if both clients record the UIDVALIDITY of each mailbox and 
the UID of each message. Then it all works.

Arnt