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

From: [email-masked]
Date: Fri, 18 Jun 2010 13:30:02 -0700 (PDT)

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-02.txt
	Pages           : 9
	Date            : 2010-06-18

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-02.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: Fri, 18 Jun 2010 16:34:39 -0400

> http://www.ietf.org/internet-drafts/draft-ietf-morg-list-specialuse-02.txt

This draft should now be ready to go.  I'm going to initiate
working-group last call on it now, to finish in two weeks, on 2 July
2010.

Everyone: please review it, and please post to this thread.  Please
post any requested changes here, and be specific about the changes and
the text.  Please also post if you have reviewed it and you think it's
OK.  We need to know how many people have reviewed it and want to move
it ahead.

Again: please review this document and post to this thread by 2 July
2010, WHETHER OR NOT you have any issues.

Barry, as chair

---

From: Dan Keen <[email-masked]>
Date: Fri, 18 Jun 2010 13:56:05 -0700

This doesn't seem to cover the request in the room:

> Proposal: leave CREATE option, don't add any non-metadata way to add special-use tag, define metadata way (registry) to add or change special use tags (if you support METADATA, we will give a reserved item for this function).  No objection in room; adopted.

We've left CREATE (good), but there's no way to alter an existent mailbox to become special use.

D

---

From: Dan Karp <[email-masked]>
Date: Fri, 18 Jun 2010 14:18:33 -0700 (PDT)

> OK. We need to know how many people have reviewed it and want to move

You need a CAPABILITY string to let clients know that they can issue an
extended LIST command with RETURN (SPECIAL-USE).  RFC 5258 mandates it:

   Both selection and return command options will be defined in this
   document and in approved extension documents; each option will be
   enabled by a capability string (one capability may enable multiple
   options), and a client MUST NOT send an option for which the server
   has not advertised support.  A server MUST respond to options it does
   not recognize with a BAD response.

Also, you've got a typo (missing the I in SPECIAL):

     C: t1 LIST "" "%" RETURN (SPECAL-USE)

---

From: Dan Karp <[email-masked]>
Date: Fri, 18 Jun 2010 19:27:37 -0700 (PDT)

> You need a CAPABILITY string to let clients know that they can
> issue an extended LIST command with RETURN (SPECIAL-USE).

Alternatively, you could have extended LIST work like regular LIST
and always include the special-use flags in the untagged responses.

And what happened to the proposal to have a SPECIAL-USE *selection*
criterion for extended LIST, which would filter the responses to
include only those mailboxes with special-use flags set on them?

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 22 Jun 2010 23:49:43 +0100

> include only those mailboxes with special-use flags set on them?

Yes, I think it's more useful as selection criteria. The return option seems a bit pointless to me. A selection criteria would still need a capability though.

Also, should a failed CREATE USE have a resp-code, so clients could determine if the problem was the mailbox name or the USE flag? Like: "NO [NOUSE] \All not supported".

(Maybe with the above change it would be possible to have only a single capability for the selection criteria and CREATE? Although could be a bit annoying for clients if they didn't know until after CREATE if the USE was supported.)

Other than that, it looks ok to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jun 2010 23:52:50 +0100

Timo Sirainen wrote:

>Yes, I think it's more useful as selection criteria. The return option seems a bit pointless to me.
>
It is only useless if the server always returns the new attributes in an 
unextended LIST response.

I think we need both.

>A selection criteria would still need a capability though.
>
I was about to make the same suggestion.

>(Maybe with the above change it would be possible to have only a single capability for the selection criteria and CREATE?
>
Yes, I think it would be worth just to have 1 capability for both.

>Although could be a bit annoying for clients if they didn't know until after CREATE if the USE was supported.)
>

---

From: Dan Karp <[email-masked]>
Date: Tue, 22 Jun 2010 16:13:55 -0700 (PDT)

> >(Maybe with the above change it would be possible to have only a
> >single capability for the selection criteria and CREATE?
> >

Then how would a client differentiate servers that allow them to
create special-use mailboxes from those that don't?

---

From: Barry Leiba <[email-masked]>
Date: Tue, 22 Jun 2010 20:23:01 -0400

Dan says...
> issue an extended LIST command with RETURN (SPECIAL-USE).

Yes; I've put that in my latest version.

> and always include the special-use flags in the untagged responses.

I don't think there's a lot of value in that.  A main point of LISText
is that you ask for what you want.

> include only those mailboxes with special-use flags set on them?

Timo says...

> Yes, I think it's more useful as selection criteria. The return option seems
> a bit pointless to me. A selection criteria would still need a capability though.

As Alexey says, I think we need both.  We can use the same capability
string for both, as well.

> Also, should a failed CREATE USE have a resp-code, so clients could
> determine if the problem was the mailbox name or the USE flag? Like:
> "NO [NOUSE] \All not supported".

Mm, good point.  I can add that.

> (Maybe with the above change it would be possible to have only a single
> capability for the selection criteria and CREATE? Although could be a bit
> annoying for clients if they didn't know until after CREATE if the USE was
> supported.)

I differ from Alexey here: I think we need two capabilities, one for
LISText and one for CREATE.  IMAP has generally been careful NOT to
set things up so you have to try commands to see whether they work.
It's not terribly expensive to have both.  Maybe I'll make the strings
"list-specialuse" and "create-specialuse".

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Jun 2010 10:53:03 +0100

>set things up so you have to try commands to see whether they work.
The second doesn't follow from the first.
The main question is: can you see a case where CREATE (USE) can be used 
without [specialuse-]extended LIST or vice versa? If not, no need to 
have 2 capabilities.

>"list-specialuse" and "create-specialuse".
It is always better to have one than to have two.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Jun 2010 13:16:32 -0400

> without [specialuse-]extended LIST or vice versa? If not, no need to have 2
> capabilities.

I don't follow this.  The problem is the other way around: we need a
capability for LIST, and we have at least one implementation (Google)
that wants to be able to implement LIST and *not* CREATE.  That gives
us the choice of having a separate capability for CREATE, or making
clients try the CREATE and see if it fails.

How can you resolve this otherwise; what am I missing?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Jun 2010 18:49:08 +0100

>How can you resolve this otherwise; what am I missing?
If Google is not planning to implement extended LIST, then we can just 
have 1 capability for both CREATE (USE) and the extended LIST.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Jun 2010 16:16:56 -0400

> If Google is not planning to implement extended LIST, then we can just have
> 1 capability for both CREATE (USE) and the extended LIST.

Right now, implementing the CREATE portion is optional.  That is:
* Implementing this extension in LIST (unextended) can happen with no
capability to announce it.
* Implementing this extension in extended LIST requires the capability
to be announced.
* Implementing this extension in CREATE is optional, regardless of
what type of LIST you implement.

You're suggesting that we change it as follows:
* Implementing this extension in LIST (unextended) can happen with no
capability to announce it.
* Implementing this extension in extended LIST requires the capability
to be announced.
* Implementing this extension in CREATE is mandatory if you implement
it in extended LIST.

I oppose that change, and would like to keep CREATE optional.  I don't
want to set up a barrier for doing the extended-LIST implementation.

Do others have opinions?  Jamie, what's your opinion, in particular?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Jun 2010 21:27:14 +0100

>want to set up a barrier for doing the extended-LIST implementation.
To be clear: there is no need to implement the whole extended LIST. The 
server can only implement handling of the new select and return options.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Jun 2010 16:59:46 -0400

> server can only implement handling of the new select and return options.

That's still backward; it's not a question of needing to implement
extended LIST.  The issue is, for a server that *does* implement
extended LIST, whether implementing CREATE becomes mandatory.  I want
it to remain optional, and so I think we need a second capability for
it.

Barry