Fine with me. On Apr 1, 2013, at 5:41 PM, Robert Sparks <[email protected]> wrote:
> On 3/28/13 1:17 PM, SM wrote: >> Hi Eric, >> At 05:13 28-03-2013, Burger Eric wrote: >>> Rather than guessing all of the bad things that could happen, I would offer >>> it would be better to say what we mean, like: >>> The IMAP interface MUST NOT provide any IMAP facilities that modify >>> the underlying message and message metadata, such as mailbox, flags, >>> marking for deletion, etc. If the client is authenticated and authorized, >>> the IMAP interface MUST provide per-user marking of the underlying message >>> as read or flagged. >> >> The IMAP interface is a front-end to the read-only mailboxes (archive). >> It's easier to do what is mentioned above. > I'm taking more or less that approach in my working copy (I'll be posting -06 > soon). >> >>> Something to ponder: >>> I use the IMAP interface once, mark a bunch of things as read, and then >>> decide never to use the IMAP interface ever again. How long does the server >>> need to keep my (per-user) marking metadata? E.g., besides CPU and I/O >>> issues, there is a potentially unbounded storage problem as well. It is >>> unbounded because in IMAP I can assign any kind of label (marking) to a >>> message, even ones I make up. >>> >>> One thought for an approach to a solution: >>> 1. per-user markings expire after X time units (six months?) >>> 2. per-user markings may take up at most X storage units (512KB?) >> >> I would go for both. > Instead, I propose that we make it possible to notice an abuser and turn off > access (this is what -06 will contain). > > I don't believe we could come to a consensus on an automatic expiry of state > - there are use cases I can think of where any short > expiration (like 6-months) would be infuriating. > > If keeping this state for normal use turns out to be too expensive for us, > then we will have learned something, and can start talking about future IMAP > work in general to help systems mitigate that expense. >> >>> Per-user metadata can be incredibly useful - I might label things by >>> project, work group, draft, mumble, or foo. I would not want to limit the >>> labels to red or green. However, we need some predictable limit as well. >> >> Yes. >> >> Regards, >> -sm >
