Subject: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

From: Robert Sparks <[email-masked]>
Date: Wed, 27 Mar 2013 15:31:24 -0500

All -

draft-sparks-genarea-imaparch has been revised to address comments from
Pete Resnick and Barry Leiba. Jari Arkko has suggested that the security 
considerations
section contain something like what RFC6778 contained about potential 
risks to CPU
and I/O utilization. I plan to make that change in the next version.

While looking at it, I noticed we don't explicitly say that this IMAP 
interface MUST NOT
allow messages in the archive to be deleted or moved to other mailboxes, 
and MUST NOT
allow messages to be inserted. I plan to add those as requirements in 
the next version.

RjS

On 3/26/13 3:45 PM, [email-masked] wrote:
> A new version (-05) has been submitted for draft-sparks-genarea-imaparch:
> http://www.ietf.org/internet-drafts/draft-sparks-genarea-imaparch-05.txt
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-sparks-genarea-imaparch/
>
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=draft-sparks-genarea-imaparch-05
>
> IETF Secretariat.
>

---

From: Burger Eric <[email-masked]>
Date: Thu, 28 Mar 2013 08:13:28 -0400

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.

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?)

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.

Thoughts?

On Mar 27, 2013, at 4:31 PM, Robert Sparks <[email-masked]> wrote:

> Pete Resnick and Barry Leiba. Jari Arkko has suggested that the security considerations
> section contain something like what RFC6778 contained about potential risks to CPU
> While looking at it, I noticed we don't explicitly say that this IMAP interface MUST NOT
> allow messages in the archive to be deleted or moved to other mailboxes, and MUST NOT
> allow messages to be inserted. I plan to add those as requirements in the next version.
> 
> RjS
>

---

From: SM <[email-masked]>
Date: Thu, 28 Mar 2013 11:17:40 -0700

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.

>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.
>

I would go for both.

>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

---

From: David Morris <[email-masked]>
Date: Thu, 28 Mar 2013 14:15:16 -0700 (PDT)

On Thu, 28 Mar 2013, SM 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.
> 
> > 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.
> > 
> > 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.

Any spec on this point should be re. minimum retention time, not a limit.
I frankly think that any limits based on storage units are suspect as
there is probably no way to related the impact of such limits to the
resulting user experience. In any case, the spec should be of the form:

1. per-user marking must be retained for at least X time units (6 months?)
2. At least X storage units must be provided for per-user markings.

Dave Morris