5. Betriebsüberlegungen (Operational Considerations)

Die folgenden Regeln sind hier aufgeführt, um sicherzustellen, dass alle IMAP4rev2-Implementierungen ordnungsgemäß interoperieren.

5.1 Postfachbenennung (Mailbox Naming)

In IMAP4rev2 sind Postfachnamen in Net-Unicode [NET-UNICODE] kodiert (dies unterscheidet sich von IMAP4rev1). Client-Implementierungen können (können) versuchen, Net-Unicode-Postfachnamen zu erstellen, und müssen (müssen) alle 8-Bit-Postfachnamen, die von LIST zurückgegeben werden, als [NET-UNICODE] interpretieren. Server-Implementierungen müssen (müssen) die Erstellung von 8-Bit-Postfachnamen verbieten, die nicht mit Net-Unicode konform sind. Server können (können) jedoch einen denormalisierten UTF-8-Postfachnamen akzeptieren und ihn vor der Postfacherstellung in Unicode-Normalisierungsform C (NFC) (gemäß Net-Unicode-Anforderungen) konvertieren. Server, die sich dafür entscheiden, solche denormalisierten UTF-8-Postfachnamen zu akzeptieren, müssen (müssen) sie in allen IMAP-Befehlen akzeptieren, die einen Postfachnamen-Parameter haben. Insbesondere muss SELECT <name> dasselbe Postfach öffnen, das erfolgreich mit CREATE <name> erstellt wurde, auch wenn <name> ein denormalisierter UTF-8-Postfachname ist.

Der groß-/kleinschreibungsunabhängige Postfachname INBOX ist ein spezieller Name, der reserviert ist, um "das primäre Postfach für diesen Benutzer auf diesem Server" zu bedeuten. (Beachten Sie, dass dieser spezielle Name auf einigen Servern für einige Benutzer möglicherweise nicht existiert, zum Beispiel, wenn der Benutzer keinen Zugriff auf den persönlichen Namensraum hat.) Die Interpretation aller anderen Namen ist implementierungsabhängig.

Insbesondere nimmt diese Spezifikation keine Position zur Groß-/Kleinschreibungsempfindlichkeit bei Nicht-INBOX-Postfachnamen ein. Einige Server-Implementierungen sind im ASCII-Bereich vollständig groß-/kleinschreibungsempfindlich; andere bewahren die Groß-/Kleinschreibung eines neu erstellten Namens, sind aber ansonsten groß-/kleinschreibungsunempfindlich; und wieder andere zwingen Namen zu einer bestimmten Groß-/Kleinschreibung. Client-Implementierungen müssen in der Lage sein, mit all diesen zu interagieren.

Es gibt bestimmte Client-Überlegungen beim Erstellen eines neuen Postfachnamens:

1. Jedes Zeichen, das eines der atom-specials ist (siehe "Formale Syntax" in Abschnitt 9), erfordert, dass der Postfachname als zitierte Zeichenkette oder Literal dargestellt wird.

2. CTL und andere nicht-grafische Zeichen sind schwer in einer Benutzeroberfläche darzustellen und sollten am besten vermieden werden. Server können (können) die Erstellung von Postfachnamen ablehnen, die Unicode-CTL-Zeichen enthalten.

3. Obwohl die Listen-Wildcardzeichen ("%" und "*") in einem Postfachnamen gültig sind, ist es schwierig, solche Postfachnamen mit dem LIST-Befehl zu verwenden, da ein Konflikt mit der Wildcard-Interpretation besteht.

4. Normalerweise ist ein Zeichen (bestimmt durch die Server-Implementierung) reserviert, um Hierarchieebenen zu begrenzen.

5. Zwei Zeichen, "#" und "&", haben per Konvention Bedeutungen und sollten vermieden werden, außer wenn sie in dieser Konvention verwendet werden. Siehe Abschnitt 5.1.2.1 bzw. Anhang A.1.

5.1.1 Postfach-Hierarchiebenennung (Mailbox Hierarchy Naming)

Wenn es gewünscht ist, hierarchische Postfachnamen zu exportieren, müssen (müssen) Postfachnamen von links nach rechts hierarchisch sein und ein einzelnes ASCII-Zeichen verwenden, um Hierarchieebenen zu trennen. Dasselbe Hierarchie-Trennzeichen wird für alle Hierarchieebenen innerhalb eines einzelnen Namens verwendet.

5.1.2 Namensräume (Namespaces)

Persönlicher Namensraum (Personal Namespace): Ein Namensraum, den der Server im persönlichen Bereich des authentifizierten Benutzers auf einer bestimmten Verbindung betrachtet. Typischerweise hat nur der authentifizierte Benutzer Zugriff auf Postfächer in seinem persönlichen Namensraum. Es ist der Teil des Namensraums, der dem Benutzer gehört und für Postfächer zugewiesen ist. Wenn ein INBOX für einen Benutzer existiert, muss (muss) es im persönlichen Namensraum des Benutzers erscheinen. Im typischen Fall sollte (sollte) es nur einen persönlichen Namensraum pro Benutzer auf einem Server geben.

Namensraum anderer Benutzer (Other Users' Namespace): Ein Namensraum, der aus Postfächern aus den persönlichen Namensräumen anderer Benutzer besteht. Um auf Postfächer im Namensraum anderer Benutzer zuzugreifen, muss (muss) dem aktuell authentifizierten Benutzer explizit Zugriffsrechte gewährt werden. Zum Beispiel ist es üblich, dass ein Manager seinem administrativen Supportpersonal Zugriffsrechte auf sein Postfach gewährt. Im typischen Fall sollte (sollte) es nur einen Namensraum anderer Benutzer pro Benutzer auf einem Server geben.

Gemeinsamer Namensraum (Shared Namespace): Ein Namensraum, der aus Postfächern besteht, die zur gemeinsamen Nutzung unter Benutzern bestimmt sind und nicht innerhalb des persönlichen Namensraums eines Benutzers existieren.

Die Namensräume, die ein Server verwendet, können (können) sich pro Benutzer unterscheiden.

5.1.2.1 Historische Postfach-Namensraum-Benennungskonvention (Historic Mailbox Namespace Naming Convention)

Per Konvention identifiziert das erste hierarchische Element eines Postfachnamens, der mit "#" beginnt, den "Namensraum" des restlichen Namens. Dies ermöglicht es, zwischen verschiedenen Arten von Postfachspeichern zu unterscheiden, die jeweils ihre eigenen Namensräume haben.

Zum Beispiel können (können) Implementierungen, die Zugriff auf USENET-Newsgroups bieten, den "#news"-Namensraum verwenden, um den USENET-Newsgroup-Namensraum von dem anderer Postfächer zu trennen. So würde die comp.mail.misc-Newsgroup einen Postfachnamen "#news.comp.mail.misc" haben, und der Name "comp.mail.misc" kann sich auf ein anderes Objekt beziehen (z.B. ein privates Postfach eines Benutzers).

Namensräume, die das "#"-Zeichen enthalten, sind nicht IMAP-URL [IMAP-URL]-freundlich und erfordern, dass das "#"-Zeichen als %23 dargestellt wird, wenn es in URLs vorkommt. Daher können (können) Server-Implementierer stattdessen die Verwendung von Namensraum-Präfixen in Betracht ziehen, die das "#"-Zeichen nicht enthalten.

5.1.2.2 Gängige Namensraummodelle (Common Namespace Models)

Die vorherige Version dieses Protokolls hat keinen Standard-Server-Namensraum definiert. Zwei gängige Namensraummodelle haben sich entwickelt:

Das "Persönliches Postfach"-Modell (Personal Mailbox), bei dem der präsentierte Standard-Namensraum nur aus den persönlichen Postfächern des Benutzers besteht. Um auf gemeinsame Postfächer zuzugreifen, muss der Benutzer einen Escape-Mechanismus verwenden, um einen anderen Namensraum zu erreichen.

Das "Vollständige Hierarchie"-Modell (Complete Hierarchy), bei dem der präsentierte Standard-Namensraum die persönlichen Postfächer des Benutzers zusammen mit allen anderen Postfächern umfasst, auf die er Zugriff hat.

5.2 Postfachgröße und Nachrichtenstatusak tualisierungen (Mailbox Size and Message Status Updates)

Zu jedem Zeitpunkt kann ein Server Daten senden, die der Client nicht angefordert hat. Manchmal ist ein solches Verhalten durch diese Spezifikation und/oder Erweiterungen erforderlich. Zum Beispiel können andere Agenten als der Server Nachrichten zum Postfach hinzufügen (z.B. neue Nachrichtenzustellung); die Flags der Nachrichten im Postfach ändern (z.B. gleichzeitiger Zugriff auf dasselbe Postfach durch mehrere Agenten); oder sogar Nachrichten aus dem Postfach entfernen. Ein Server muss (muss) Postfachgrößenaktualisierungen automatisch senden, wenn während der Verarbeitung eines Befehls eine Postfachgrößenänderung beobachtet wird. Ein Server sollte (sollte) Nachrichtenflag-Aktualisierungen automatisch senden, ohne dass der Client solche Aktualisierungen explizit anfordern muss.

Besondere Regeln existieren für die Benachrichtigung eines Clients über die Entfernung von Nachrichten durch den Server, um Synchronisationsfehler zu vermeiden; siehe die Beschreibung der EXPUNGE-Antwort (Abschnitt 7.5.1) für weitere Details. Insbesondere ist es NICHT erlaubt, eine EXISTS-Antwort zu senden, die die Anzahl der Nachrichten im Postfach verringern würde; nur die EXPUNGE-Antwort kann dies tun.

Unabhängig davon, welche Implementierungsentscheidungen ein Client in Bezug auf das Merken von Daten vom Server trifft, muss (muss) eine Client-Implementierung Postfachgrößenaktualisierungen merken. Sie darf nicht (darf nicht) annehmen, dass ein Befehl nach der anfänglichen Postfachauswahl die Größe des Postfachs zurückgibt.

5.3 Antwort, wenn kein Befehl läuft (Response When No Command in Progress)

Server-Implementierungen dürfen eine nicht markierte Antwort (außer EXPUNGE) senden, während kein Befehl läuft. Server-Implementierungen, die solche Antworten senden, müssen (müssen) sich mit Flusssteuerungsüberlegungen befassen. Insbesondere müssen (müssen) sie entweder (1) überprüfen, dass die Größe der Daten die verfügbare Fenstergröße des zugrunde liegenden Transports nicht überschreitet, oder (2) nicht blockierende Schreibvorgänge verwenden.

5.4 Automatischer Abmeldetimer (Autologout Timer)

Wenn ein Server einen Inaktivitäts-Automatischen-Abmeldetimer hat, der auf Sitzungen nach der Authentifizierung angewendet wird, muss (muss) die Dauer dieses Timers mindestens 30 Minuten betragen. Der Empfang eines beliebigen Befehls vom Client während dieses Intervalls setzt den automatischen Abmeldetimer zurück.

Beachten Sie, dass diese Spezifikation keine Einschränkungen für einen automatischen Abmeldetimer hat, der vor erfolgreicher Client-Authentifizierung verwendet wird. Insbesondere dürfen Server einen verkürzten Vor-Authentifizierungstimer verwenden, um sich vor Denial-of-Service-Angriffen zu schützen.

5.5 Mehrere laufende Befehle (Befehls-Pipelining) (Multiple Commands in Progress / Command Pipelining)

Der Client kann (kann) einen weiteren Befehl senden, ohne auf die Abschluss-Ergebnisantwort eines Befehls zu warten, vorbehaltlich Mehrdeutigkeitsregeln (siehe unten) und Flusssteuerungsbeschränkungen auf dem zugrunde liegenden Datenstrom. Ähnlich kann (kann) ein Server mit der Verarbeitung eines anderen Befehls beginnen, bevor der aktuelle Befehl vollständig verarbeitet ist, vorbehaltlich Mehrdeutigkeitsregeln. Allerdings müssen (müssen) alle Befehlsfortsetzungsanforderungsantworten und Befehlsfortsetzungen ausgehandelt werden, bevor ein nachfolgender Befehl eingeleitet wird.

Die Ausnahme ist, wenn eine Mehrdeutigkeit aufgrund eines Befehls entstehen würde, der die Ergebnisse anderer Befehle beeinflussen würde. Wenn der Server eine mögliche Mehrdeutigkeit erkennt, muss (muss) er Befehle in der vom Client angegebenen Reihenfolge bis zum Abschluss ausführen.

Das offensichtlichste Beispiel für Mehrdeutigkeit ist, wenn ein Befehl die Ergebnisse eines anderen Befehls beeinflussen würde. Ein Beispiel ist ein FETCH, das dazu führen würde, dass \Seen-Flags gesetzt werden, und ein SEARCH UNSEEN-Befehl.

Eine nicht offensichtliche Mehrdeutigkeit tritt bei Befehlen auf, die eine nicht markierte EXPUNGE-Antwort zulassen (Befehle außer FETCH, STORE und SEARCH), da eine nicht markierte EXPUNGE-Antwort Sequenznummern in einem nachfolgenden Befehl ungültig machen kann. Dies ist kein Problem für FETCH-, STORE- oder SEARCH-Befehle, da Servern verboten ist, EXPUNGE-Antworten zu senden, während einer dieser Befehle läuft. Wenn der Client daher einen anderen Befehl als FETCH, STORE oder SEARCH sendet, muss (muss) er auf die Abschluss-Ergebnisantwort warten, bevor er einen Befehl mit Nachrichtensequenznummern sendet.

Hinweis: EXPUNGE-Antworten sind erlaubt, während UID FETCH, UID STORE und UID SEARCH laufen. Wenn der Client einen UID-Befehl sendet, muss (muss) er auf eine Abschluss-Ergebnisantwort warten, bevor er einen Befehl sendet, der Nachrichtensequenznummern verwendet (dies kann UID SEARCH einschließen). Alle Nachrichtensequenznummern in einem Argument für UID SEARCH sind mit Nachrichten vor der Wirkung von nicht markierten EXPUNGE-Antworten verbunden, die von UID SEARCH zurückgegeben werden.

Zum Beispiel sind die folgenden nicht wartenden Befehlssequenzen ungültig:

---