MBOX-Line: From imap at maclean.com  Wed May 19 08:33:54 2010
To: imap-protocol@u.washington.edu
From: Pete Maclean <imap@maclean.com>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] Namespace questions
Message-ID: <mailman.2.1528486483.22076.imap-protocol@mailman13.u.washington.edu>

I am adding support for namespaces to my IMAP server and have some 
questions about how the LIST command should work with them.  I have 
to say that I am finding it hard to figure this out from RFC 
3501.  My main difficulty stems from the fact that LIST is described 
as returning "names" and I am unclear as to just what a "name" can be.

Is it correct that the command:

1 LIST "" *

should list mailboxes in all namespaces?  (Well, all mailboxes except 
those in other users' namespaces that are not explicitly 
advertised.)  It seems to me that it should because of the way that 
the * wildcard is defined.  Should it include namespace prefixes by themselves?

What about:

1 LIST "" %

My guess is that this should list top-level mailboxes in the default 
namespace and the prefixes of other namespaces.  (My notion of 
"default namespace" is simply the namespace that does not have a prefix.)

If I am correct about these first two commands then, as far as I can 
see, there is no way in a single LIST command to list only those 
mailboxes in the default namespace -- which seems unfortunate.  Is 
this the case?

I am also implementing the NAMESPACE command.  With one of the 
clients I using to test, I see command-response sequences like this:

C: 4 NAMESPACE
S: * NAMESPACE (("#Namespace1" "/")("#Namespace2" "/")("" "/")) NIL NIL
S: 4 OK NAMESPACE completed
...
C: 6 LIST "" #Namespace1
S: 6 OK LIST completed

For one thing, I am unsure as to whether my server's response to this 
LIST command should be as shown or like this:

C: 6 LIST "" #Namespace1
S: * LIST (\Noselect) "/" #Namespace1
S: 6 OK LIST completed

But what's more, I see no point to such a LIST command since, no 
matter which response is appropriate, surely it's a given?

Thanks,

Pete Maclean


