Re: [Imap-protocol] rfc-5258 LIST Command Extensions

Thomas Dreßler <[email protected]>
Newsgroups gmane.mail.imap.general
Message-ID <[email protected]>
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
[email protected]

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

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.