mailing list archives

Hi,

i am a litle bit confused about some examples in rfc-5258 (page 17):
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done

baz2 is returned, and baz2 is not supscribed.
i miss the following response:
* LIST (\NonExistent) "/" qux2 ("CHILDINFO" ("SUBSCRIBED"))

why is qux2 not returned? i don't undertsand the difference in the examples
between list-mailbox "*" and "*2". in "*2" example the responses for "baz2"
and "qux2" are disabled (because redundant information), "foo2" is 
listed (because
it have an not matched chield).
in "*" example "baz2" is listed and "qux2" not.
the only difference is: "baz2" exists and "qux2" not.

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

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

bye
ThomasD

PS:
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))


-- 
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

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.

On 30/10/2012 17: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.
Right. Some examples in the document demonstrate valid, but maybe not 
entirely expected responses. That was intentional, although the document 
should have explained that.
>> 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).
Agreed.
>> 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.

This was already reported:

http://www.rfc-editor.org/errata_search.php?eid=2072

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