Subject: [MORG] I-D Action:draft-ietf-morg-list-specialuse-03.txt

From: [email-masked]
Date: Mon, 08 Nov 2010 18:15:28 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Message Organization Working Group of the IETF.

	Title           : IMAP LIST extension for special-use mailboxes
	Author(s)       : B. Leiba, J. Nicolson
	Filename        : draft-ietf-morg-list-specialuse-03.txt
	Pages           : 12
	Date            : 2010-11-08

Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages.  Many mail clients
allow users to specify where draft or sent messages should be put,
but configuring them requires that the user know which mailboxes the
server has set aside for these purposes.  This extension adds new
mailbox flags that a server MAY include in IMAP LIST command
responses to identify special-use mailboxes to the client, easing
configuration.

Note

A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community.  Discussion
and suggestions for improvement are requested, and should be sent to
[email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-morg-list-specialuse-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Nov 2010 16:14:03 +0800

I have posted a new version of special-use, which I believe satisfies
all comments through working-group last call.  Chairs, I think the
document is now ready for PROTO write-up and sending to the IESG.
Please either do that, or, if you think it needs it, post another
working group last call.

Thanks,
Barry

> responses to identify special-use mailboxes to the client, easing
...

---

From: "Georg C. F. Greve" <[email-masked]>
Date: Tue, 9 Nov 2010 09:47:24 +0100

Hi all,

With the same disclaimer as for my other mail, my question would be whether it 
might be possible to have a query for ANNOTATE Extension values for this, in 
order to get returned a list of special folders containing address book data, 
calendars or such.

Has this been considered?

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: [email-masked]
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve

---

From: Dan Karp <[email-masked]>
Date: Tue, 9 Nov 2010 05:01:04 -0800 (PST)

> Please either do that, or, if you think it needs it, post another

I think the document could use a note explaining that the special-use
flags apply only to the authenticated user's personal mailboxes.  (Or
the opposite, if you so desire!)  In other words, if you did a LIST
on another user's mailboxes (per NAMESPACE), should the \Inbox show
up on their INBOX?

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Nov 2010 10:25:32 +0800

> Please either do that, or, if you think it needs it, post another
I need to double check ABNF (I don't have Internet connectivity at the 
moment), but this version looks good to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Nov 2010 10:29:04 +0800

> on another user's mailboxes (per NAMESPACE), should the \Inbox show
Ah, good point. I think \Inbox and friends shouldn't be shown for 
INBOXes (etc.) of other users.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Nov 2010 11:03:41 +0800

> moment), but this version looks good to me.
   resp-text-code =/  "USEFLAG"
                    ; Extends "resp-text-code" from
                    ; IMAP [RFC5258 <./rfc5258>]

The comment is incorrect here, as resp-text-code is defined in RFC 3501.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 16 Nov 2010 16:15:07 +0000

> INBOXes (etc.) of other users.

+1

Also maybe this example should use "*" instead of "%":

     C: t3 LIST (SPECIAL-USE) "" "%"
     S: * LIST (\Sent) "/" SentMail
     S: * LIST (\Marked \Drafts) "/" MyDrafts
     S: * LIST (\Trash) "/" Trash
     S: t3 OK done

And a small note that it's not required that the special-use mailboxes
exist on root level (especially when server uses e.g. INBOX/ namespace
prefix), and with "*" it's guaranteed to return all of them.

> CREATE command "USE" parameter: In some server implementations, some
>    special uses may imply automatic action by the server.  For example,
>    creation of a "\Junk" mailbox might cause the server to start placing
>    messages that have been evaluated as spam into the mailbox.  Server
>    implementors SHOULD consider the consequences of allowing a user (or
>    client program) to designate the target of such automatic action.

Maybe make it clearer with a note something like: "(e.g. mailboxes
containing spaces, line feeds, quotes or '`' characters might break some
scripts)".

Other than that, looks good.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 16 Nov 2010 16:18:02 +0000

> order to get returned a list of special folders containing address book data, 

Earlier METADATA drafts supported something like this, but it was
removed (probably because of the extra complexity). Could be useful, but
I don't think it anyway belongs to SPECIAL-USE spec.

---

From: Dan Karp <[email-masked]>
Date: Tue, 16 Nov 2010 08:31:22 -0800 (PST)

> prefix), and with "*" it's guaranteed to return all of them.

Along those lines, it might be good to have a RECURSIVEMATCH example in
the document.  Especially one that demonstrates multiple selection
criteria (e.g. "LIST (RECURSIVEMATCH SELECTED SPECIAL-USE) ...") and
a CHILDINFO extended data item.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Nov 2010 08:36:27 +0800

> a CHILDINFO extended data item.

Can do.  As I've said a number of times, suggestions for examples will
be best if they're accompanied by the full example.  Please.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Nov 2010 08:42:37 +0800

>> INBOXes (etc.) of other users.

I wonder when y'all last read this doc: \Inbox has been out for a while now.

I'm not sure we want to restrict things, and forbid using a shared
mailbox for some functions.  While I agree that in most cases you'll
want to have all the special-use boxes in the user's private
namespace, I'd rather keep any discussion of that as non-normative
advice.

What do you folks think of that suggestion?

> prefix), and with "*" it's guaranteed to return all of them.

OK, sure.  Reasonable change.

> containing spaces, line feeds, quotes or '`' characters might break some

Hm.  That's not what that security note is talking about at all.  I
could certainly add your note as well (though I don't know that it's a
security consideration), but it's entirely orthogonal to the paragraph
you cited.

Barry

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 17 Nov 2010 01:10:29 +0000

> I wonder when y'all last read this doc: \Inbox has been out for a while now.

I didn't even think about that.

> What do you folks think of that suggestion?

I guess it's ok to have to have them in other namespaces, as long as the namespaces are how Mark intended them, meaning LIST "" * won't show such namespaces' contents.

> security consideration), but it's entirely orthogonal to the paragraph

Oh. What possible consequences there could be then?

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Nov 2010 09:52:24 +0800

> Oh. What possible consequences there could be then?

Suppose you have a mailbox you've shared with others (using ACLs), and
you then designate it as \Junk.  False positives will automatically be
placed by the server into a shared mailbox that others can see.
Suppose you designate an existing mailbox as \Trash, and the server
policy is to automatically delete messages that have been in \Trash
for more than 20 days... and suddenly the messages that used to be in
that mailbox start disappearing.  The point is that these are not just
"flags" on the mailboxes -- they specify certain mailbox behaviour.
If a client can move that behaviour around, that might cause side
effects that the user won't like.  That might be one reason a server
implementation might not want to allow certain special uses to be
moved around.

Barry

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 17 Nov 2010 01:55:46 +0000

> implementation might not want to allow certain special uses to be

I think client implementors should also consider those things, not just server implementors.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Nov 2010 09:57:27 +0800

> I think client implementors should also consider those things, not just server implementors.

D'accord.  I'll change that.

b

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Nov 2010 05:48:04 +0000

Hi Barry,

Barry Leiba wrote:

>mailbox for some functions.
>
That is not what I meant. I was saying that a mailbox marked as \Inbox 
for you must not be returned as \Inbox for me, *unless* I mark the same 
mailbox as \Inbox in my view of IMAP universe.

>While I agree that in most cases you'll
 [...]

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Nov 2010 19:36:57 +0800

> I was saying that a mailbox marked as \Inbox for
> you must not be returned as \Inbox for me, *unless* I mark the same mailbox
> as \Inbox in my view of IMAP universe.

I will add a note that the special uses on a mailbox are user-specific.

Barry