[Kolab-devel] IMAP and "flat" namespaces

[Gunnar Wrobel]

Quoting Bernhard Reiter <bernhard at intevation.de>:

> Hi Kolab-Developers and Friends,
>
> over the years I've often heard the question about "INBOX" being displayed in
> a Kolab Client and all folder being subfolders to it. I've just published a
> small result of this consideration to:
> https://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/research/imap-flacher-namensraum-de.txt?rev=2&root=kolab&view=log
>
> Attention, this document is in Germany.
> The short summary:
>
> To use a "flat privat namespace", which means having folder belonging to one
> user in parallel to the special IMAP folder "INBOX" is okay with the IMAP
> standard RFCs.
>
> There is one conceptual problem, that is irrelevant in practice, if  
> you intend
> to add more non-private namespaces later in an IMAP  installation.
>
> For the implementation side there are some more remarks:
> a) Clients must be able to clearly detect if a folder belongs to other users
> or not, so an empty private namespace must not be checked against the folder
> paths first or this will fail.
> b) Servers should block the creating of private folders having names that are
> to be used by other namespaces, e.g. "user/".
> c) Clients can implement to display folders being parallel to the special
> folder "INBOX" independently which model is used by the server.
>
> It would have been cool if the IMAP specs would disallow the use of the
> empty "flat" private namespace, which would implementors live easier for
> clients and servers.
>
> Currently a cool IMAP Client must implement both schemes reasonably well.
> Given the Cryus IMAPD by default supports the "private INBOX namespace",
> and it is easier to implement on client side, I suggest that our default
> configuration for IMAP servers with Kolab should be to use the "privat INBOX
> namespace"  and improve our clients to display that nicely.

If I understand you correctly this means we would change the current  
Cyrus Imapd configuration. Is that right? Could you post the necessary  
configuration changes you would like to suggest? I'm pretty certain  
this should no problem for webmail client but I'd like to give it a  
short test.

Thanks!

Cheers,

Gunnar

>
> Bernhard
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090828/d05486ff/attachment.sig>