Subject: RE: [lemonade] About "Avoiding Duplicates"

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Aug 2006 14:08:02 +0100

On Fri Aug 25 09:24:35 2006, Ben Last wrote:
> From: Dave Cridland [mailto:[email-masked]] Sent: 25 August 2006 
> 09:04
> >FWIW, I do have a bit of a plan here:
> >1) Assign a unique identifier to all mailboxes on a server. This 
> >unqiue identifier is essentially a shorthand for (mailbox path, 
> >UIDVALIDITY), except that should a folder be renamed, it will be 
> >preserved. This allows clients to shorten the triplet to a 2-tuple 
> >(mailbox id, UID).
> 
> This I like very much; it also helps to solve the potentially very
> expensive resynchronization/download currently incurred by renaming 
> of a
> mailbox.

... which I don't think is a big problem, but it's a nice side-effect 
to take advantage of.

>   It could also help to identify "special" mailboxes, if there
> were some agreement on reserved identifiers for certain special
> mailboxes.
> 
> 
No, sorry, I don't like magic numbers, only mystic names. :-)

> >2) All messages acquire this 2-tuple when they first enter the 
> IMAP >server, whether via delivery or via APPEND. This 2-tuple is 
> preserved >across COPY.
> Hang on; doesn't that imply that a message can be copied to another
> mailbox, but keep the id of the mailbox in which it first appeared?

Yes - I didn't intend to merely imply it, but state it categorically. 
It's kept as a distinct bit of information, though - ie, it still 
gets a new UID.

>   If
> so, that means that nearly all messages would end up with the 
> mailbox id
> of the INBOX, surely?
> 
> 
That might happen, yes. It depends on what server-side delivery 
filtering is happening, for instance. I can't see a way of avoiding 
that, right now.

> >3) The 2-tuple can be read via a FETCH operation that will only 
> >return the 2-tuple when the mailbox id differs from the current 
> >mailbox id - that is, it'll only be shown for messages which have 
> >been copied or otherwise duplicated with the knowledge of the IMAP 
> >server.
> Interesting: presumably a SEARCH could also do this?
> 
> 
I have to admit, I hadn't really considered that.

> I guess this has already been considered, but if we're adding new
> attributes (like this 2-tuple) to messages, why not just allocate a
> unique id to each message on arrival, and preserve that over COPY?  
> Then
> that id can serve to allow identification of individual messages as
> duplicates between vfolders or mailboxes?  Effectively this is what
> you're doing, but with a 2-tuple.
> 
> 
Yes. The first advantage of the 2-tuple is that if I do the currently 
mythical:

A01 UID FETCH 1:* (PROPOSED2TUPLE)

Then the server can omit the PROPOSED2TUPLE if it's the "default".

As you point out, for many messages, this will only occur when 
they're seen in the INBOX, but maybe we can work out some refinement 
to deal with that.

The second advantage is that it's lower impact on existing client 
code, or at least, I think it probably is.

>   Plus, as far as I can tell from a quick re-reading of
> RFC3501, there's no reason that UIDVALIDITY values currently need 
> to be
> unique across mailboxes.
> 
> 
True - it's not the lack of uniqueness that stopped me making 
UIDVALIDITY serve double duty, since that additional constraint could 
have been retrospectively imposed by the extension, it was Phil 
pointing out that UIDVALIDITY MUST always increase for a mailbox, and 
therefore tends to get "bumped" by a RENAME. That I couldn't work 
around.

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: "Ben Last" <[email-masked]>
Date: Fri, 25 Aug 2006 14:18:29 +0100

>From: Dave Cridland [mailto:[email-masked]] 
>Sent: 25 August 2006 14:08

>> expensive resynchronization/download currently incurred by renaming
of 
>> a mailbox.
to take advantage of.
Well, it doesn't happen very often, but there's a very large cost when
it does.

>>   It could also help to identify "special" mailboxes, if there were 
>> some agreement on reserved identifiers for certain special mailboxes.
"Mystic identifiers", then :)

Regards
ben
EMCC Software Ltd