MBOX-Line: From tss at iki.fi  Tue Oct 30 10:37:53 2012
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] rfc-5258 LIST Command Extensions
In-Reply-To: <508841A2.4010602@1und1.de>
References: <508841A2.4010602@1und1.de>
Message-ID: <26B31F64-2066-43C7-B228-977ABE9AB695@iki.fi>

On 24.10.2012, at 22.29, Thomas Dressler wrote:

> i am a litle bit confused about some examples in rfc-5258 (page 17):
> C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
> S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
..
> S: D03 OK done
> 
> baz2 is returned, and baz2 is not supscribed.

I don't think it should have been included. It's not entirely wrong for the server to do it, but it's unnecessary when listing a "*". When listing "%" it would have been necessary, otherwise the client wouldn't have known of its children.

> i miss the following response:
> * LIST (\NonExistent) "/" qux2 ("CHILDINFO" ("SUBSCRIBED"))

This would also need to be returned for %, but for * it's optional (and better if not returned).

> in wich situations should "LIST (RECURSIVEMATCH SUBSCRIBED)" return an mailbox,
> which is not subscribed?

When the pattern matches an unsubscribed mailbox, which has subscribed children that don't match the pattern. That's the optimal case. Servers can somewhat easily optimize the % and * cases, but for others it would pretty much require to save the results in a tree structure and based on that figure out which nodes to return to client. If that's too much work, I think it's okay for the server to just return more than necessary (Dovecot does that with some settings).

> are there some rfc-conform implementations, for testing/orientating?

I think Dovecot v2.1 returns everything optimally with Maildir backend. See also imaptest's listext test: http://hg.dovecot.org/imaptest/file/62ac822588f0/src/tests/listext

> the second example in rfc-5819 is an invalid commandline (there must be an SP before mailbox):
> C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS (MESSAGES))

You could report this as RFC errata, and maybe the example change also.
