MBOX-Line: From thomas.dressler at 1und1.de  Wed Oct 31 03:27:45 2012
To: imap-protocol@u.washington.edu
From: =?ISO-8859-1?Q?Thomas_Dre=DFler?= <thomas.dressler@1und1.de>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] rfc-5258 LIST Command Extensions
In-Reply-To: <26B31F64-2066-43C7-B228-977ABE9AB695@iki.fi>
References: <508841A2.4010602@1und1.de>
	<26B31F64-2066-43C7-B228-977ABE9AB695@iki.fi>
Message-ID: <5090FD21.5040506@1und1.de>

i have added all examples from rfc-5258 to unit tests

Test9.3. (see also page 16):
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"

Test9.4 (see also page 17):
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"

if i use an implementation, for wich Test9.3 runs succesfull,
then Test9.4 fails because the same implementation hide
replies for baz2, foo2 with the same reason like in Test9.3

summary:
- Test9.3 is ok.
- Test9.4 is also ok, if the server don't reply baz2 / foo2.

are i'am correct?

PS:
the example (Test9.4) is strange, because the server
reply baz2 and foo2 and not qux2.


On 30.10.2012 18:37, Timo Sirainen wrote:
> 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.


-- 
Thomas Dressler
Software-Entwickler

1&1 Internet AG - Mail System Development
Brauerstrasse 48 DE-76135 Karlsruhe
Telefon: +49 721 91374-6790
thomas.dressler@1und1.de

Amtsgericht Montabaur / HRB 6484
Vorstaende: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


