From scm-commit at wald.intevation.org Mon Aug 17 12:09:12 2009 From: scm-commit at wald.intevation.org (scm-commit@wald.intevation.org) Date: Mon, 17 Aug 2009 12:09:12 +0200 (CEST) Subject: [Kolab-commits] r2 - trunk/research Message-ID: <20090817100912.1D67C852FD8F@pyrosoma.intevation.org> Author: bernhard Date: 2009-08-17 12:09:11 +0200 (Mon, 17 Aug 2009) New Revision: 2 Added: trunk/research/imap-flacher-namensraum-de.txt Log: Adding a research document about flat namespaces (in German). Added: trunk/research/imap-flacher-namensraum-de.txt =================================================================== --- trunk/research/imap-flacher-namensraum-de.txt 2008-03-26 10:43:13 UTC (rev 1) +++ trunk/research/imap-flacher-namensraum-de.txt 2009-08-17 10:09:11 UTC (rev 2) @@ -0,0 +1,161 @@ +Flacher Privater Namensraum im IMAP-Protokoll +============================================= +2008-12-03, Bernhard Herzog +2009-01-21, Bernhard Reiter + +Zusammenfassung +--------------- +"Flache private Namensräume", also private Ordner ("mailboxen") parallel +zu dem besonderen Ordner "INBOX", sind konform to den IMAP-Standard-RFCs. +Konzeptuell gibt es nur dann ein Problem, wenn weitere nicht-private +Namensräumen bei einer Installation hinzugenommen werden sollen und +der entsprechende Präfix bei Nutzern schon als Präfix existiert. +Das dürfte in der Praxis irrelevant sein, weil meist exakt zwei andere +Namensräume fest stehen und sich nicht mehr ändern: "user/" (andere Nutzer) +und "shared/" (kontolose Nutzer). + +Weitere Schwierigkeiten haben also mit den Implementationen zu tun: +Davon bemerkenswert: +a) Der Klient sollte auseinanderhalten können, was Ordner anderer Nutzer sind. + Damit das geht, darf er das leere Ergebniss des NAMESPACE Kommandos für + private Ordner _nicht_ als ersten Präfix prüfen, da auch + die anderen Namensräume mit "" beginnen + und eventuell nicht mehr erkannt würden. +b) Es scheint sinnvoll, dass Server das Anlegen eines privaten Ordners "user" + verweigern, wenn "user/" der Präfix eines anderen Namensraums ist. + (Der von uns getestete dovecot verhielt sich anders.) +c) Bei einem "nicht-flachen" privaten Namensraum könnten Klienten + konzeptuell den Präfix "INBOX/" bei der Darstellung weglassen + und den gleichen optischen Effekt wie bei einem "flachen Namensraum" + erzielen. Der Ordner "INBOX" selbst wird von IMAP besonders behandelt, + sollte immer vorhanden sein und wird von Klienten wahrscheinlich übersetzt + dargestellt. + +Es wäre schön, die "flachen Namensräume" in den IMAP-Standards auszuschliessen, +da sie für gut implementierte Klienten keine Vorteile bieten, +aber komplizierter für Server und Klienten umzusetzen sind. + + +Einordnung +---------- +Der "flache" Namensraum kann Implementierungsschwächen in manchen Klienten +ausgleichen und zu einer angenehmeren Darstellung führen. +Hier eine englische Besprechung des Problems +und der Konfigurationsoption des Cyrus IMAPDs: +http://blog.fastmail.fm/2008/08/11/alternate-namespace-imap-port-may-help-outlook-ol-express-apple-mail-and-bis-users/ + + +Namespaces in IMAP +------------------ + +Grundsätzlich ist die Interpretation von Mailboxnamen von der jeweiligen +Implementation abhängig. Es gibt nur wenige Ausnahmen. Dazu der RFC zu +IMAP4rev1 [RFC3501] in Abschnitt 5.1.: + + The case-insensitive mailbox name INBOX is a special name reserved to + mean "the primary mailbox for this user on this server". The + interpretation of all other names is implementation-dependent. + +Ausserdem gibt es die Konvention, dass ein '#' am Anfang +des ersten Teils eines hierarchischen Mailboxnamens +einen Namespace anzeigt (Abschnitt 5.1.2.): + + By convention, the first hierarchical element of any mailbox name + which begins with "#" identifies the "namespace" of the remainder of + the name. + +Zusätzlich definiert der IMAP4 Namespace RFC [RFC2342] Mechanismus, wie +sich Klienten über die Konventionen des Servers informieren können. Der +NAMESPACE-Befehl liefert Informationen über die Namens-Präfixe, die der +Server verwendet, um verschiedene Namensräume zu trennen. RFC2342 sagt +jedoch nichts darüber, was passiert, wenn es Mailboxnamen gibt, die zu +mehreren Präfixen passen, etwa weil es einen Namensraum ohne Präfix gibt. + + +Flacher Privater Namensraum +--------------------------- + +Eine verbreitete Konvention für den privaten Namensraum, ist INBOX/ als +Präfix zu verwenden. Dies ist zum Beispiel die Standardkonfiguration +beim Cyrus Imapd. Eine Konsequenz dieser Konvention ist, +dass alle privaten Mailboxen Unterordner der INBOX sind. +Eine Alternative ist, keinen Präfix für den privaten Namensraum zu haben, +so dass auch Ordner auf der gleichen Hierarchieebene wie INBOX möglich sind. +Diese Alternative nennen wir hier kurz "flach". + + +Namenskonflikte durch Flache Private Namensräume +------------------------------------------------ + +Bei flachen privaten Namensräumen hat der private Namensraum keinen Präfix. +Die anderen Namensräume, z.B. für freigegebene Ordner von Nutzern, +können brauchen dann einen Ordnernamen als Kennzeichnung. +Der Klient kann diese mit den NAMESPACE-Befehl abfragen. +Damit es keine Konflikte gibt, sollten diese Namen nicht als +private Ordnernamen verwendet werden. Üblich sind bei Cyrus IMAP +die Namen "user/" für die freigegebenen Ordner anderer Nutzer +und "shared/" für Ordner ohne zugehöriges IMAP-Konto. + +Namenskonflikte sind nur zu erwarten, wenn zu einer bestehenden +Installation neue Namensräume hinzukommen und Ordner mit diesen Namem +bestehen. Sofern die zwei obigen Namen bereits fest sind, +läßt sich das in der Praxis vermeiden. + + +Verhalten von Dovecot +--------------------- + +Getestete dovecot Version: 1.2.alpha3 mit Kolab Patches + genauer Revision 310ab696497b aus HG kolab_branch + +In dovecot lässt sich die Situation mit einem präfixlosen privaten +Namensraum und einem weiteren Namensraum mit Präfix mit einer +Konfiguration wie dieser nachstellen: + + namespace private { + separator = / + inbox = yes + list = yes + subscriptions = yes + } + + namespace shared { + separator = / + prefix = users/%%u/ + location = ... + subscriptions = no + list = yes + hidden = no + } + +Also, ein privater Namespace ohne Präfix, in dem auch die INBOX ist, und +ein Namespace mit Präfix "users/" für freigegebene Mailboxen +anderer Nutzer. + +Dovecot lässt es zu, den Ordner "users" zu erzeugen, der dann auch im +privaten Namespace sichtbar ist. Unterordner von "users" können aber +nicht angelegt werden. + +Wenn der oben angegebene shared Namespace vorübergehend deaktiviert +wird, können auch Unterordner von "users" angelegt werden. Wenn dann +der shared Namespace wieder aktiviert wird, werden diese Unterordner +zwar aufgelistet, können aber nicht verwendet werden, weil dovecot ihre +Namen als Namen im shared Namespace interpretiert. + +Es wäre wünschenswert, dass dovecot das Anlegen des Ordners "users" +gleich ablehnt, da es sonst in der Darstellung und Erkennung der anderen Ordner +bei Klienten zu Verwirrungen kommen könnte. + + +Hinweis zur Kolab-Kompatibilität von Namensräumen +------------------ +Der Namensraum für die Ordner anderer Nutzer +muss als zweites Element den IMAP (bzw. Kolab) Nutzernamen enthalten. +Das ist für das Anstossen der Freibelegtlisten-Erstellung notwendig. + + +Referenzen +---------- + +[RFC3501] IMAP4rev1 http://www.ietf.org/rfc/rfc3501.txt +[RFC2342] IMAP4 Namespace http://www.ietf.org/rfc/rfc2342.txt