Subject: [MORG] New WG document:draft-ietf-morg-list-specialuse-00

From: Barry Leiba <[email-masked]>
Date: Mon, 25 Jan 2010 20:57:43 -0500

> 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-00.txt
>        Pages           : 9
>        Date            : 2010-01-25
>
> 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.
...
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-morg-list-specialuse-00.txt

At the Hiroshima meeting, the working group agreed to add this
document to its list of work items.  It is a standards-track version
of gmail's "XLIST" extension, which has been implemented by several
mail clients already.  Google has said they would alter their
implementation to confirm to a standards-track version.

Please review this new draft and comment on it.

Barry, MORG secretary

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 26 Jan 2010 13:04:52 +0200

> Please review this new draft and comment on it.

I'm mainly wondering if it should describe interaction with
LIST-EXTENDED, similar to how LIST-EXTENDED handles \*Children flags. So
basically "when doing extended LIST, don't send these specialuse flags,
unless SPECIALUSE return option is specified". But I don't have any
strong opinion on it either way.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Jan 2010 10:33:31 -0500

Timo says...
> unless SPECIALUSE return option is specified".

Yes, I think this is a good idea.  On the queue for -01.

Barry

---

From: Dan Karp <[email-masked]>
Date: Tue, 26 Jan 2010 07:40:23 -0800 (PST)

> > LIST-EXTENDED, similar to how LIST-EXTENDED handles \*Children
> > flags. So basically "when doing extended LIST, don't send these
> > specialuse flags, unless SPECIALUSE return option is specified".
> 

Except that's not what LIST-EXTENDED says about CHILDREN, right?

   The CHILDREN
   return option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Jan 2010 10:46:44 -0500

> Except that's not what LIST-EXTENDED says about CHILDREN, right?

What I mean is that I'll put in appropriate wording for list-extended,
as distinct from non-extended list.

Barry

---

From: Filip Navara <[email-masked]>
Date: Tue, 26 Jan 2010 17:17:51 +0100

On Tue, Jan 26, 2010 at 2:57 AM, Barry Leiba
<[email-masked]> wrote:
> _______________________________________________
> MORG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/morg
> Note Well: http://www.ietf.org/maillist.html

I know at least three servers that implement XLIST to some degree...
- Gmail
- Kerio Mail Server 6.7+
- IceWarp Mail Server 10.1 betas

... and at least three clients that implement it to some degree:
- Mozilla Thunderbird 3+
- Apple iPhone
- eM Client 2.5.6501+

Anybody else implements it?

One issue I see with the draft is the behavior of \AllMail - in Gmail,
the \AllMail folder is also used for archivation. Copying a message
into it has the effect of the "Archive" button on Gmail web site. I
believe Thunderbird 3+ also has the archive button that works based on
the \AllMail flag and we eventually want to implement it in eM Client
as well. The \AllMail flag as currently defined - "This mailbox
presents all messages in the user's message store." - however couldn't
be used by servers that don't support virtual folders and which have
designated archive folder. Thus I propose an "\Archive" flag that
could be used instead of or in combination with the "\AllMail" flag.

Another thing I would like to point out is that internally the IceWarp
Mail Server uses METADATA [1] to store the special types of folders.
This has its pros and cons and could be made compatible with the draft
as it is by converting the USE parameter into the metadata on mailbox
creating. The more important aspect of it is that it allows the
clients to modify the locations of those special folders after they
are created (much like in the Thunderbird "Copies and folders" pane in
the "Account settings" dialog). Would such feature be useful or
desirable to be standardized?

Best regards,
Filip Navara

[1] http://tools.ietf.org/html/rfc5464

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Jan 2010 11:41:29 -0500

On Tue, Jan 26, 2010 at 11:17 AM, Filip Navara <[email-masked]> wrote:
> into it has the effect of the "Archive" button on Gmail web site.

Of course, this draft (intentionally) doesn't specify anything about
how the special-use mailboxes actually WORK, or what side effects
their use has.  I did try to get that idea across by saying that these
may be strange entities (well, not in those words), but beyond that,
they are what the server makes them.  And I did point out that, for
\AllMail in particular, the server MAY make adjustments.

That said...

> The \AllMail flag as currently defined - "This mailbox

...I like the idea of an \Archive flag, and I'll add it to the next
draft unless there's objection to it.  I'd like to see comments in
support of it, as well.

> desirable to be standardized?

Hm.  Maybe.
I can certainly put in an informative paragraph here that says that
this says nothing about how the server stores this information, but if
the server stores this information in metadata, it MAY allow clients
to modify it (with a note in security considerations), and that any
standardization of this is out of scope here, and subject to a
possible future standard.

What do others think?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Jan 2010 11:46:15 -0500

> strong opinion on it either way.

Here's what I've changed for this:

--------------------------------
2.  New mailbox flags identifying special-use mailboxes

   An IMAP server that supports this extension MAY include any or all of
   the following flags in responses to the non-extended IMAP LIST
   command.  The new flags are included along with existing flags, such
   as "\Marked" and "\Noselect".  A given mailbox may have none, one, or
   more than one of these flags.  In some cases, a special use is advice
   to a client about what to put in that mailbox.  In other cases, it's
   advice to a client about what to expect to find there.

   For the extended list command [LISTX], this extension adds a new
   return option, "SPECIAL-USE".  The new special-use flags SHOULD be
   returned if the client specifies the SPECIAL-USE return option, and
   SHOULD NOT be returned otherwise.
--------------------------------

And I've added a registration for the SPECIAL-USE return option, and a
normative reference to RFC 5258.  [I can change the SHOULD NOT to MAY,
if people prefer; I don't care either way.]

Barry