Fine with me.

On Apr 1, 2013, at 5:41 PM, Robert Sparks <rjspa...@nostrum.com> 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
> 

Reply via email to