5. Betriebsüberlegungen (Operational Considerations)

2. CTL und andere nicht-grafische Zeichen sind schwer in einer Benutzeroberfläche darzustellen und sollten am besten vermieden werden.

3. Obwohl die Listen-Platzhalterzeichen ("%" und "*") in einem Postfachnamen gültig sind, ist es aufgrund des Konflikts mit der Platzhalter-Interpretation schwierig, solche Postfachnamen mit den Befehlen LIST und LSUB zu verwenden.

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

5. Zwei Zeichen, "#" und "&", haben konventionelle Bedeutungen und sollten vermieden werden, außer wenn sie in dieser Konvention verwendet werden.

5.1.1. Postfachhierarchie-Benennung (Mailbox Hierarchy Naming)

Wenn es gewünscht ist, hierarchische Postfachnamen zu exportieren, MÜSSEN (MUST) Postfachnamen von links nach rechts hierarchisch sein und ein einzelnes Zeichen verwenden, um Hierarchieebenen zu trennen. Dasselbe Hierarchietrennzeichen wird für alle Hierarchieebenen innerhalb eines einzelnen Namens verwendet.

5.1.2. Postfach-Namensraum-Benennungskonvention (Mailbox Namespace Naming Convention)

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

Beispielsweise KÖNNEN (MAY) Implementierungen, die Zugriff auf USENET-Newsgroups bieten, den Namensraum "#news" verwenden, um den USENET-Newsgroup-Namensraum von dem anderer Postfächer zu trennen. Somit hätte die Newsgroup comp.mail.misc einen Postfachnamen "#news.comp.mail.misc", und der Name "comp.mail.misc" kann sich auf ein anderes Objekt beziehen (z. B. ein privates Postfach eines Benutzers).

5.1.3. Internationale Postfach-Benennungskonvention (Mailbox International Naming Convention)

Per Konvention werden internationale Postfachnamen in IMAP4rev1 unter Verwendung einer modifizierten Version der in [UTF-7] beschriebenen UTF-7-Kodierung (Encoding) angegeben. Modifiziertes UTF-7 kann auch in Servern verwendbar sein, die eine frühere Version dieses Protokolls implementieren.

In modifiziertem UTF-7 repräsentieren druckbare US-ASCII-Zeichen, mit Ausnahme von "&", sich selbst; das heißt, Zeichen mit Oktettwerten 0x20-0x25 und 0x27-0x7e. Das Zeichen "&" (0x26) wird durch die Zwei-Oktett-Sequenz "&-" dargestellt.

Alle anderen Zeichen (Oktettwerte 0x00-0x1f und 0x7f-0xff) werden in modifiziertem BASE64 dargestellt, mit einer weiteren Modifikation von [UTF-7], dass "," anstelle von "/" verwendet wird. Modifiziertes BASE64 DARF NICHT (MUST NOT) verwendet werden, um druckbare US-ASCII-Zeichen darzustellen, die sich selbst repräsentieren können.

"&" wird verwendet, um zu modifiziertem BASE64 zu wechseln, und "-", um zurück zu US-ASCII zu wechseln. Es gibt keinen impliziten Wechsel von BASE64 zu US-ASCII, und Null-Wechsel ("-&" in BASE64; beachten Sie, dass "&-" in US-ASCII "&" bedeutet) sind nicht zulässig. Alle Namen beginnen jedoch in US-ASCII und MÜSSEN (MUST) in US-ASCII enden; das heißt, ein Name, der mit einem Nicht-ASCII-ISO-10646-Zeichen endet, MUSS (MUST) mit einem "-" enden.

Der Zweck dieser Modifikationen besteht darin, die folgenden Probleme mit UTF-7 zu beheben:

1. UTF-7 verwendet das Zeichen "+" zum Wechseln; dies steht im Konflikt mit der häufigen Verwendung von "+" in Postfachnamen, insbesondere USENET-Newsgroup-Namen.

2. Die UTF-7-Kodierung ist BASE64, die das Zeichen "/" verwendet; dies steht im Konflikt mit der Verwendung von "/" als beliebtes Hierarchietrennzeichen.

3. UTF-7 verbietet die unkodierte Verwendung von ""; dies steht im Konflikt mit der Verwendung von "" als beliebtes Hierarchietrennzeichen.

4. UTF-7 verbietet die unkodierte Verwendung von ""; dies steht im Konflikt mit der Verwendung von "" in einigen Servern als Home-Verzeichnis-Indikator.

5. UTF-7 erlaubt mehrere alternative Formen zur Darstellung derselben Zeichenkette; insbesondere können druckbare US-ASCII-Zeichen in kodierter Form dargestellt werden.

Obwohl modifiziertes UTF-7 eine Konvention ist, legt es bestimmte Anforderungen an die Serverbehandlung von Postfachnamen mit einem eingebetteten "&"-Zeichen fest. Insbesondere MÜSSEN (MUST) Serverimplementierungen die genaue Form des modifizierten BASE64-Teils eines modifizierten UTF-7-Namens bewahren und diesen Text als groß-/kleinschreibungsempfindlich behandeln, auch wenn Namen ansonsten groß-/kleinschreibungsunempfindlich oder groß-/kleinschreibungsgefaltet sind.

Serverimplementierungen SOLLTEN (SHOULD) überprüfen, dass jeder Postfachname mit einem eingebetteten "&"-Zeichen, der als Argument für CREATE verwendet wird: in der korrekt modifizierten UTF-7-Syntax ist, keine überflüssigen Wechsel hat und keine Kodierung in modifiziertem BASE64 von druckbaren US-ASCII-Zeichen hat, die sich selbst repräsentieren können. Clientimplementierungen DÜRFEN JEDOCH NICHT (MUST NOT) darauf vertrauen, dass der Server dies tut, und SOLLTEN NICHT (SHOULD NOT) versuchen, einen Postfachnamen mit einem eingebetteten "&"-Zeichen zu erstellen, es sei denn, er entspricht der modifizierten UTF-7-Syntax.

Serverimplementierungen, die einen Mailstore exportieren, der nicht der modifizierten UTF-7-Konvention folgt, MÜSSEN (MUST) jeden Postfachnamen, der entweder Nicht-ASCII-Zeichen oder das "&"-Zeichen enthält, in modifiziertes UTF-7 konvertieren.

Beispielsweise ist hier ein Postfachname, der englischen, chinesischen und japanischen Text mischt:
~peter/mail/&U,BTFw-/&ZeVnLIqe-

Beispielsweise ist die Zeichenkette "&Jjo!" kein gültiger Postfachname, da sie keinen Wechsel zu US-ASCII vor dem "!" enthält. Die korrekte Form ist "&Jjo-!". Die Zeichenkette "&U,BTFw-&ZeVnLIqe-" ist nicht zulässig, da sie einen überflüssigen Wechsel enthält. Die korrekte Form ist "&U,BTF2XlZyyKng-".

5.2. Postfachgröße und Nachrichtenstatusaktualisierungen (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 ERFORDERLICH (REQUIRED). Beispielsweise KÖNNEN (MAY) andere Agenten als der Server Nachrichten zum Postfach hinzufügen (z. B. Zustellung neuer Nachrichten), die Flags der Nachrichten im Postfach ändern (z. B. simultaner Zugriff auf dasselbe Postfach durch mehrere Agenten) oder sogar Nachrichten aus dem Postfach entfernen. Ein Server MUSS (MUST) automatisch Postfachgrößenaktualisierungen senden, wenn während der Verarbeitung eines Befehls eine Änderung der Postfachgröße beobachtet wird. Ein Server SOLLTE (SHOULD) automatisch Nachrichtenflag-Aktualisierungen senden, ohne dass der Client solche Aktualisierungen explizit anfordern muss.

Es gelten besondere Regeln für die Serverbenachrichtigung eines Clients über das Entfernen von Nachrichten, um Synchronisationsfehler zu vermeiden; siehe die Beschreibung der EXPUNGE-Antwort für weitere Details. Insbesondere ist es NICHT zulässig, 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 beim Speichern von Daten vom Server trifft, MUSS (MUST) eine Clientimplementierung Postfachgrößenaktualisierungen aufzeichnen. Sie DARF NICHT (MUST NOT) 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)

Serverimplementierungen dürfen eine nicht getaggte Antwort (außer EXPUNGE) senden, während kein Befehl läuft. Serverimplementierungen, die solche Antworten senden, MÜSSEN (MUST) Flusskontrollüberlegungen behandeln. Insbesondere MÜSSEN (MUST) 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. Automatische Abmeldezeitgeber (Autologout Timer)

Wenn ein Server einen Inaktivitäts-Abmeldezeitgeber hat, MUSS (MUST) die Dauer dieses Zeitgebers mindestens 30 Minuten betragen. Der Empfang JEDES Befehls vom Client während dieses Intervalls SOLLTE (SHOULD) ausreichen, um den Abmeldezeitgeber zurückzusetzen.

5.5. Mehrere laufende Befehle (Multiple Commands in Progress)

Der Client KANN (MAY) einen anderen Befehl senden, ohne auf die Abschlussergebnisantwort eines Befehls zu warten, vorbehaltlich Mehrdeutigkeitsregeln (siehe unten) und Flusskontrollbeschränkungen für den zugrunde liegenden Datenstrom. Ebenso KANN (MAY) ein Server mit der Verarbeitung eines anderen Befehls beginnen, bevor die Verarbeitung des aktuellen Befehls abgeschlossen ist, vorbehaltlich Mehrdeutigkeitsregeln. Alle Befehlsfortsetzungsanforderungsantworten und Befehlsfortsetzungen MÜSSEN (MUST) jedoch ausgehandelt werden, bevor ein nachfolgender Befehl initiiert wird.

Die Ausnahme besteht, wenn eine Mehrdeutigkeit aufgrund eines Befehls entstehen würde, der die Ergebnisse anderer Befehle beeinflussen würde. Clients DÜRFEN NICHT (MUST NOT) mehrere Befehle senden, ohne zu warten, wenn eine Mehrdeutigkeit entstehen würde. Wenn der Server eine mögliche Mehrdeutigkeit erkennt, MUSS (MUST) er Befehle bis zum Abschluss in der vom Client angegebenen Reihenfolge ausführen.

Das offensichtlichste Beispiel für Mehrdeutigkeit ist, wenn ein Befehl die Ergebnisse eines anderen Befehls beeinflussen würde, z. B. ein FETCH der Flags einer Nachricht und ein STORE der Flags derselben Nachricht.

Eine nicht offensichtliche Mehrdeutigkeit tritt bei Befehlen auf, die eine nicht getaggte EXPUNGE-Antwort zulassen (andere Befehle als FETCH, STORE und SEARCH), da eine nicht getaggte EXPUNGE-Antwort Sequenznummern in einem nachfolgenden Befehl ungültig machen kann. Dies ist bei FETCH-, STORE- oder SEARCH-Befehlen kein Problem, da Server daran gehindert sind, EXPUNGE-Antworten zu senden, während einer dieser Befehle läuft. Daher MUSS (MUST) der Client, wenn er einen anderen Befehl als FETCH, STORE oder SEARCH sendet, auf die Abschlussergebnisantwort warten, bevor er einen Befehl mit Nachrichtensequenznummern sendet.

Hinweis: UID FETCH, UID STORE und UID SEARCH sind andere Befehle als FETCH, STORE und SEARCH. Wenn der Client einen UID-Befehl sendet, muss er auf eine Abschlussergebnisantwort warten, bevor er einen Befehl mit Nachrichtensequenznummern sendet.