4. Datenformate (Data Formats)
IMAP4rev2 verwendet textuelle Befehle und Antworten. Daten in IMAP4rev2 können in einer von mehreren Formen vorliegen: Atom (Atom), Zahl (Number), Zeichenkette (String), geklammerte Liste (Parenthesized List) oder NIL. Beachten Sie, dass ein bestimmtes Datenelement mehr als eine Form annehmen kann; beispielsweise kann ein Datenelement, das als Verwendung der "astring"-Syntax definiert ist, entweder ein Atom oder eine Zeichenkette sein.
4.1 Atom (Atom)
Ein Atom (Atom) besteht aus einem oder mehreren nicht-speziellen Zeichen.
4.1.1 Sequenzmenge und UID-Menge (Sequence Set and UID Set)
Eine Menge von Nachrichten kann durch eine Sequenzmenge (Sequence Set) referenziert werden, die entweder Nachrichtensequenznummern oder eindeutige Identifikatoren enthält. Siehe Abschnitt 9 für Details. Eine Sequenzmenge kann Bereiche von Sequenznummern (wie "5:50"), eine Aufzählung bestimmter Sequenznummern oder eine Kombination davon enthalten. Eine Sequenzmenge kann das Sondersymbol "*" verwenden, um die maximale Sequenznummer im Postfach darzustellen. Eine Sequenzmenge enthält niemals eindeutige Identifikatoren.
Eine "UID-Menge" (UID Set) ist der Sequenzmenge ähnlich, verwendet jedoch eindeutige Identifikatoren anstelle von Nachrichtensequenznummern und darf das Sondersymbol "*" nicht enthalten.
4.2 Zahl (Number)
Eine Zahl (Number) besteht aus einem oder mehreren Ziffernzeichen und repräsentiert einen numerischen Wert.
4.3 Zeichenkette (String)
Eine Zeichenkette (String) liegt in einer von drei Formen vor: synchronisierendes Literal (Synchronizing Literal), nicht-synchronisierendes Literal (Non-synchronizing Literal) oder zitierte Zeichenkette (Quoted String). Die synchronisierende Literalform ist die allgemeine Form einer Zeichenkette ohne Einschränkung der Zeichen, die die Zeichenkette enthalten kann. Die nicht-synchronisierende Literalform ist ebenfalls die allgemeine Form, hat jedoch eine Längenbeschränkung. Die zitierte Zeichenkettenform ist eine Alternative, die den Overhead der Verarbeitung eines Literals vermeidet, aber Einschränkungen bei den verwendbaren Zeichen hat.
Wenn die Unterscheidung zwischen synchronisierenden und nicht-synchronisierenden Literalen nicht wichtig ist, verwendet dieses Dokument nur den Begriff "Literal".
Ein synchronisierendes Literal (Synchronizing Literal) ist eine Sequenz von null oder mehr Oktetten (einschließlich CR und LF), präfix-zitiert mit einer Oktettanzahl in Form einer öffnenden geschweiften Klammer ("), der Anzahl der Oktette, einer schließenden geschweiften Klammer (") und einem CRLF. Im Fall von synchronisierenden Literalen, die vom Server an den Client übertragen werden, folgen die Oktettdaten unmittelbar auf das CRLF. Im Fall von synchronisierenden Literalen, die vom Client an den Server übertragen werden, muss (muss) der Client warten, um eine Befehlsfortsetzungsanforderung (Command Continuation Request) zu erhalten, bevor er die Oktettdaten (und den Rest des Befehls) sendet.
Das nicht-synchronisierende Literal (Non-synchronizing Literal) ist eine alternative Form des synchronisierenden Literals und kann (kann) vom Client zum Server überall dort verwendet werden, wo ein synchronisierendes Literal erlaubt ist. Die nicht-synchronisierende Literalform darf nicht (darf nicht) vom Server an den Client gesendet werden. Das nicht-synchronisierende Literal unterscheidet sich vom synchronisierenden Literal dadurch, dass zwischen der Oktettanzahl und der schließenden geschweiften Klammer ("}") ein Pluszeichen ("+") steht. Der Server generiert keine Befehlsfortsetzungsanforderung als Antwort auf ein nicht-synchronisierendes Literal, und Clients sind nicht verpflichtet, zu warten, bevor sie die Oktette eines nicht-synchronisierenden Literals senden. Sofern nicht in einer IMAP-Erweiterung anders angegeben, dürfen nicht-synchronisierende Literale nicht (dürfen nicht) größer als 4096 Oktette sein. Jedes Literal, das größer als 4096 Oktette ist, muss (muss) als synchronisierendes Literal gesendet werden.
Eine zitierte Zeichenkette (Quoted String) ist eine Sequenz von null oder mehr Unicode-Zeichen, ausgenommen CR und LF, codiert in UTF-8, mit Anführungszeichen (">") an jedem Ende.
Die leere Zeichenkette wird als "" (eine zitierte Zeichenkette mit null Zeichen zwischen Anführungszeichen), als {0} gefolgt von einem CRLF (ein synchronisierendes Literal mit einer Oktettanzahl von 0) oder als {0+} gefolgt von einem CRLF (ein nicht-synchronisierendes Literal mit einer Oktettanzahl von 0) dargestellt.
Hinweis: Auch wenn die Oktettanzahl 0 ist, muss (muss) ein Client, der ein synchronisierendes Literal überträgt, warten, um eine Befehlsfortsetzungsanforderung zu erhalten.
4.3.1 8-Bit- und Binärzeichen ketten (8-Bit and Binary Strings)
8-Bit-Text- und Binär-E-Mails werden durch die Verwendung einer [MIME-IMB]-Inhaltsübertragungscodierung unterstützt. IMAP4rev2-Implementierungen können (können) 8-Bit- oder Multi-Oktett-Zeichen in Literalen übertragen, sollten (sollten) dies jedoch nur tun, wenn das [CHARSET] identifiziert ist.
IMAP4rev2 ist mit [I18N-HDRS] kompatibel. Infolgedessen ist der identifizierte Zeichensatz für Header-Feldwerte mit 8-Bit-Inhalt UTF-8 [UTF-8]. IMAP4rev2-Implementierungen müssen (müssen) [UTF-8]-Text in zitierten Zeichenketten akzeptieren und können (können) ihn übertragen, solange die Zeichenkette kein NUL, CR oder LF enthält. Dies unterscheidet sich von IMAP4rev1-Implementierungen.
Obwohl eine BINARY-Inhaltsübertragungscodierung definiert ist, sind uncodierte Binärzeichen ketten nicht erlaubt, es sei denn, sie werden in einem <literal8> als Antwort auf ein BINARY.PEEK[<section-binary>]<<partial>> oder BINARY[<section-binary>]<<partial>> FETCH-Datenelement zurückgegeben. Eine "Binärzeichen kette" (Binary String) ist jede Zeichenkette mit NUL-Zeichen. Eine Zeichenkette mit übermäßiger Anzahl von CTL-Zeichen kann (kann) ebenfalls als binär betrachtet werden. Sofern sie nicht als Antwort auf BINARY.PEEK[...]/BINARY[...] FETCH zurückgegeben wird, müssen (müssen) Client- und Server-Implementierungen Binärdaten in eine Textform codieren, wie z. B. base64, bevor sie die Daten übertragen.
4.4 Geklammerte Liste (Parenthesized List)
Datenstrukturen werden als "geklammerte Liste" (Parenthesized List) dargestellt; eine Sequenz von Datenelementen, durch Leerzeichen getrennt und an jedem Ende durch Klammern begrenzt. Eine geklammerte Liste kann andere geklammerte Listen enthalten, wobei mehrere Ebenen von Klammern verwendet werden, um Verschachtelung anzuzeigen.
Die leere Liste wird als () dargestellt -- eine geklammerte Liste ohne Mitglieder.
4.5 NIL
Die Sonderform "NIL" repräsentiert die Nicht-Existenz eines bestimmten Datenelements, das als Zeichenkette oder geklammerte Liste dargestellt wird, im Gegensatz zur leeren Zeichenkette "" oder zur leeren geklammerten Liste ().
Hinweis: NIL wird niemals für ein Datenelement verwendet, das die Form eines Atoms annimmt. Beispielsweise ist ein Postfachname von "NIL" ein Postfach namens NIL im Gegensatz zu einem nicht existierenden Postfachnamen. Dies liegt daran, dass Postfächer die "astring"-Syntax verwenden, die ein Atom oder eine Zeichenkette ist. Umgekehrt ist ein addr-name von NIL ein nicht existierender persönlicher Name, da addr-name die "nstring"-Syntax verwendet, die NIL oder eine Zeichenkette ist, aber niemals ein Atom.
Beispiele
Die folgende LIST-Antwort:
* LIST () "/" NIL
ist gleichbedeutend mit:
* LIST () "/" "NIL"
da die LIST-Antwort ABNF "astring" für den Postfachnamen verwendet.
Die folgende Antwort:
* FETCH 1 (BODY[1] NIL)
ist jedoch nicht gleichbedeutend mit:
* FETCH 1 (BODY[1] "NIL")
Ersteres zeigt die Abwesenheit des Körperteils an, während letzteres bedeutet, dass es eine Zeichenkette mit den drei Zeichen "NIL" enthält.