Subject: RE: [lemonade] Notifications for multiple devices per user

From: Dave Cridland <[email-masked]>
Date: Thu, 03 Aug 2006 12:05:35 +0100

On Thu Aug  3 09:57:10 2006, Ben Last wrote:
> The problem of
> detecting folders that should not be synchronized is an important 
> one to
> mobile clients (where the consequences of repeated download are bad 
> and
> can involve serious data charges for end users).

There's a limited amount of support for this particular item in the 
subscription handling. I think that in general, this area could use 
some more examination, in particular I think that allowing a more 
arbitrary subscription mechanism might be very beneficial.

Something akin to user-settable flags, but on mailboxes. (Of course, 
purely with that, you then get the additional problem that the client 
needs to have configuration available to know which keywords 
indicated that the client ought to be fully synchronizing, or merely 
presenting for ad-hoc access).

Incidentally, *not* synchronizing message content - using a model 
much closer to online access - does yield considerably lower 
bandwidth.

> To reframe part of the problem, then, in a manner less contentious: 
> are
> there any proposals for mechanisms by which a client can be aware 
> that a
> folder has been renamed, so that it may avoid redownloading the 
> entire
> contents of that folder?

No. It could relatively easily be done, however, by (for example) 
overloading the UIDVALIDITY to act as a mailbox identifier. (You'd 
need to add a CAPABILITY string, force it to be unique system-wide, 
and that's really about it - I'm not claiming this is bullet-proof, 
but I can't see any obvious flaws).

That said, although it's very simple to do, I've not really seen 
mailboxes renamed sufficiently often to warrant the effort of doing 
even that, but I'll write up the idea in more detail if there's 
demand.

The far more prevelant problem is where messages are copied by a 
third-party (ie, another client), since there's no way for a client 
to know that it has the message in cache already. Most solutions for 
this problem tend to involve a sufficiently large overhead that the 
solution outweighs the problem, though.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

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

---

From: Philip Guenther <[email-masked]>
Date: Thu, 3 Aug 2006 05:32:22 -0700

On Thu, 3 Aug 2006, Dave Cridland wrote:
>> detecting folders that should not be synchronized is an important one to
>> mobile clients (where the consequences of repeated download are bad and

I always assumed that synchronization would be a "default off" kind of 
setting.  That is, only those folder that you explicitly told the client 
to synchronize would be synced.  If nothing else, a client that made the 
opposite choice will be buried by any server that contains even a few 
mailing-list archives or---even better---a USENET news gateway.

("$4000 in data charges!?!?"  "Yeah, but I got all of comp.lang.c on my 
phone...")

So, before we launch into proposals for recognizing various special 
purpose mailboxes, how about some explanations of why the existence of 
these mailboxes should provoke such angst in clients?

> subscription handling. I think that in general, this area could use some more 
> examination, in particular I think that allowing a more arbitrary 
> subscription mechanism might be very beneficial.
>
> Something akin to user-settable flags, but on mailboxes. (Of course, purely 
> with that, you then get the additional problem that the client needs to have 
> configuration available to know which keywords indicated that the client 
> ought to be fully synchronizing, or merely presenting for ad-hoc access).

mumble METADATA mumble

>> To reframe part of the problem, then, in a manner less contentious: are
>> there any proposals for mechanisms by which a client can be aware that a
>> folder has been renamed, so that it may avoid redownloading the entire
>> contents of that folder?

How often are mailboxes that clients synchronize going to be renamed?  If 
the answer is "not too often", then the effort spent developing a 
mechanism may never pay off...because it'll never get tested well enough 
to be relied on.

> No. It could relatively easily be done, however, by (for example) overloading 
> the UIDVALIDITY to act as a mailbox identifier. (You'd need to add a 
> CAPABILITY string, force it to be unique system-wide, and that's really about 
> it - I'm not claiming this is bullet-proof, but I can't see any obvious 
> flaws).

The constraints on UIDVALIDITY cause problems:

a CREATE foo
b CREATE bar
<assume that foo has UIDVALIDITY less than bar>
c DELETE bar
d RENAME foo bar

At this point, the UIDVALIDITY of bar must be greater than that of the 
original foo.  Ergo, UIDVALIDITY can't always be a stable identifier.

Some of us recall the NEWNAME response-code of RFC 2060.  It was removed 
when that was revised into 3501 because it couldn't support all mailbox 
names, but a version using a imap URL instead of a simple name could 
be made to work...but then you have to tackle issues like "how does the 
server know who has the rights to see the new name?", "how can I remove 
such a 'tombstone'?", "what if the mailbox gets renamed again?", etc.

Philip Guenther

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Aug 2006 15:09:51 +0200

I'll do a strawman proposal. It's workable for some servers, and it's 
concrete enough that its cost can be judged against its value.

1. Supporting servers report the MAILBOXID capability and also support listext.

2. The MAILBOXID of a mailbox is an atom and SHOULD be at most 50 bytes. 
On a server which uses the unix file system, it could be generated 
using the device number and an inode number, concatenated and e.g. 
encoded using base36.

3. A server MUST NOT assign the same mailboxid to two mailboxes at the 
same time, and MUST NOT routinely change a mailbox' mailboxid.

4. A client can ask for the mailboxid using a return option of list.

5. A client MUST assume that if the name and uidvalidity of a mailbox 
hasn't changed, it is the same mailbox, even if its mailboxid changes. 
(The change could be the result of a restore from backup, for example.) 
A client MAY assume that if a mailbox has the same mailboxid and 
uidvalidity as a no longer existing mailbox, it is in fact the old 
mailbox, just renamed. A client MUST NOT assume that ACLs apply 
unchanged.

(METADATA would work as well as listext, wouldn't it? Doesn't really 
matter. It's just a strawman.)

Traffic cost for ignorant clients: 10 bytes per connection (skipping 
over the capability name).

Traffic cost for a really smart client: About 50-200 bytes for each time 
the client starts caching information for a mailbox it hasn't formerly 
cached (send a LIST ... RETURN MAILBOXID, get the ID, see if it matches 
some other mailbox, and if it does, see if that other mailbox has gone 
away). Some savings in case of mailbox renames.

Traffic cost for a stupid client: 20 bytes for each LIST command and say 
50 bytes for each LIST response. Some savings as above.

Implementation cost for servers: I could do it easily. I think quite a 
few others could, too. And some people couldn't do it at all.

Implementation cost for clients: No idea.

How often are mailboxes renamed? blah -> blah-july-2006 at the end of 
July 2006 seems about the only case which is common enough to even 
dream of bothering about. Is that common?

Arnt