wasm-demo/demo/ermis-f/imap-protocol/cur/1600095126.22914.mbox:2,S

91 lines
3.7 KiB
Plaintext

MBOX-Line: From mrc at CAC.Washington.EDU Wed May 23 23:36:50 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun 8 12:34:39 2018
Subject: [Imap-protocol] Re: FLAGS response
In-Reply-To: <1179984406.32181.1730.camel@hurina>
References: <20070524012401.GA30894@penne.toroid.org>
<alpine.WNT.0.99.0705231829570.3716@Tomobiki-Cho.CAC.Washignton.EDU>
<20070524033850.GA31634@penne.toroid.org>
<alpine.OSX.0.99.0705232059170.10455@pangtzu.panda.com>
<1179984406.32181.1730.camel@hurina>
Message-ID: <alpine.OSX.0.99.0705232314230.10455@pangtzu.panda.com>
On Thu, 24 May 2007, Timo Sirainen wrote:
> And I suppose it's OK for server to drop unused keywords from a FLAGS
> reply and announce that to clients at any point?
I would not remove flags, nor change the order of flags in the FLAGS
response, during a session.
> Is it a good idea to drop unused keywords whenever their last user
> (message) went away?
Simple answer: "probably not"
See below for more discussion.
> Or should I bother adding some kind of a "unused
> for one month (or so)" timeout too?
Simple answer: "probably"
More discussion:
The IMAP specification is silent on the matter because there was no clear
understanding on anyone's part what is right.
I think that it is alright (from a protocol point of view) to remove
unused flags in a new session (but NOT during a session!). That's one
reason why flags are announced; to show what is there.
Put another way: a subsequent FLAGS response in a session should only add
flags at the end of the list, but a FLAGS response in a new session can
reorder/remove flags.
From a usability point of view (as opposed to protocol point of view), I
think that unused flags should be retained for a reasonable period of
time, and perhaps not removed at all unless there is some good reason
(such as an excessive number of unused flags).
For example, UW imapd has a limit (inherited from the 1980s when it was
quite generous) of 30 unique keywords per mailbox. That limit is quite
inadequate today, especially if people want to do a gmail style mail
organization. I plan to remove this limit for mix format mailboxes (older
legacy formats will keep the limit), sooner rather than later.
Anyway, if the mailbox uses up its 30 keywords, and there's a bunch of
unused ones, it's reasonable to clean those up. That hasn't been done by
any automated mechanism yet. It's on my to-do list; and even if mix
repeals the limit there will need to be some sort of garbage collection.
A server which has no limit, but finds itself with 3000 keywords in the
mailbox of which only 8 have been used in the past 3 years, is IMHO quite
adequately provoked into doing some recycling!
I use only 6 keywords myself. I would be *very* unhappy with an IMAP
server that deleted any of my keywords due to disuse, no matter how long
the period. A mere 6 keywords is not (should not be) costly to keep
around!
I think the key here is "use some common sense". I can't say what numbers
are "good" numbers since I think we're all groping towards a "sweet spot".
6 is "obviously small enough to be left alone", and 3000 is "obviously
huge enough to clean up"; so the threshold is somewhere in the middle.
UW imapd has only heard the first rumblings of "30 isn't enough" (but
there *are* rumblings). So I think that a "sweet spot" for cleaning up
unused keywords is somewhere in the 2-digit range.
The best thing is to try something that appears reasonable and see.
Eventually, there will probably be enough collective community knowledge
that we can provide more precise guidelines to future implementors.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.