[Kolab-commits] r2 - trunk/research
scm-commit@wald.intevation.org
scm-commit at wald.intevation.org
Mon Aug 17 12:09:12 CEST 2009
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 <bh at intevation.de>
+2009-01-21, Bernhard Reiter <bernhard at intevation.de>
+
+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/<nutzername>" 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
More information about the Kolab-commits
mailing list