On 4/1/13 4:41 PM, Robert Sparks wrote:
On 3/28/13 1:17 PM, SM wrote:
At 05:13 28-03-2013, Burger Eric wrote:
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.
During my IESG Evaluation review of the document, I noticed the
resultant paragraph for this. I don't know how I missed it before. Here
is what I said in my ballot:
---
o It must be possible for administrators, on a per-user basis, to
disable setting read/unread marks and other annotations and to
delete any such marks or annotations.
I don't think that's the appropriate requirement. A perfectly reasonable
way to address the issue of annotations taking up too much space is to
use per-user storage quotas. I would prefer not to give administrators
the ability or the need to decide which users get to use annotations and
which users' annotations they get to delete. And I can imagine servers
for which implementing this requirement would be a significant pain.
Quotas solve the problem in a much more general way.
---
I wanted to post here to make sure that folks who were involved in the
earlier discussion saw what I was suggesting and had a chance to object
if they thought I was full of crap.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478