Anhang B. Änderungen gegenüber RFC 2060 (Appendix B. Changes from RFC 2060)
-
Klargestellt, dass Befehle, die die Befehlspipelining (command pipelining) unterbrechen, auf eine Abschlussergebnisantwort warten müssen.
-
Klargestellt, dass EXAMINE \Recent nicht beeinflusst.
RFC 3501 IMAPv4 March 2003
-
Beschreibung der MIME-Struktur konsistent gestaltet.
-
Klargestellt, dass Datensuchen (date searches) die Zeit und Zeitzone des INTERNALDATE- oder Date:-Headers außer Acht lassen. Mit anderen Worten bedeutet „ON 13-APR-2000" Nachrichten mit einem INTERNALDATE-Text, der mit „13-APR-2000" beginnt, selbst wenn die Zeitzonendifferenz zur lokalen Zeitzone ausreicht, um jenes INTERNALDATE auf den vorherigen oder nächsten Tag zu verschieben.
-
Klargestellt, dass Header-Fetches keine leere Zeile hinzufügen, wenn keine in der [RFC-2822]-Nachricht vorhanden ist.
-
Klargestellt (in der Erörterung von UIDs), dass Nachrichten unveränderlich (immutable) sind.
-
Ein Beispiel für CHARSET-Suche hinzugefügt.
-
In SEARCH geklärt, dass Schlüsselwörter (keywords) eine Art von Flag sind.
-
Die verbindliche Natur der SELECT-Datenantworten geklärt.
-
Optionalen CAPABILITY-Antwortcode in der initialen OK- oder PREAUTH-Antwort hinzugefügt.
-
Hinweis hinzugefügt, dass der Server eine nicht getaggte CAPABILITY- Antwort als Teil der Antworten auf AUTHENTICATE und LOGIN senden kann.
-
Aussage entfernt, dass es unnötig sei, einen CAPABILITY-Befehl innerhalb einer Verbindung mehr als einmal auszugeben. Diese Aussage trifft nicht mehr zu.
-
Klargestellt, dass nicht getaggtes EXPUNGE die Anzahl der Nachrichten in der Mailbox verringert.
-
Definition von „body" korrigiert (Konkatenation bindet fester als Alternation).
-
Neuen Abschnitt „Special Notes to Implementors" mit Verweis auf [IMAP-IMPLEMENTATION] hinzugefügt.
-
Klargestellt, dass eine nicht getaggte CAPABILITY-Antwort auf einen AUTHENTICATE-Befehl nur erfolgen sollte, wenn keine Sicherheitsebene (security layer) ausgehandelt wurde.
-
Definition von atom geändert, um „]" auszuschließen. astring aktualisiert, damit „]" zur Kompatibilität mit der Vergangenheit enthalten ist. resp-text-atom entfernt.
-
NEWNAME entfernt. Es kann nicht funktionieren, da Mailbox-Namen Literale sein und „]" enthalten können. Die Funktionalität kann über Verweise (referrals) adressiert werden.
RFC 3501 IMAPv4 March 2003
-
Begründung für modifiziertes UTF-7 verschoben, um einen logischeren Absatzfluss zu erhalten.
-
UID-Eindeutigkeitsgarantien mit der Verwendung von MUST geklärt.
-
Hinweis, dass Clients Antwortdaten lesen sollten, bis die Verbindung geschlossen ist, anstatt bei einem BYE sofort zu schließen.
-
RFC-822-Verweise zu RFC-2822 geändert.
-
Klargestellt, dass RFC-2822 anstelle von RFC-822 befolgt werden sollte.
-
Empfehlung für optionale automatische Fähigkeiten in LOGIN und AUTHENTICATE geändert, damit der CAPABILITY-Antwortcode in der getaggten OK verwendet wird. Dies ist interoperabler als eine unaufgeforderte nicht getaggte CAPABILITY-Antwort.
-
STARTTLS und AUTH=PLAIN sind verpflichtend zu implementieren; Empfehlungen für andere [SASL]-Mechanismen hinzugefügt.
-
Klargestellt, dass eine „Verbindung" (im Gegensatz zu „Server" oder „Befehl") sich in einem der vier Zustände befindet.
-
Klargestellt, dass ein fehlgeschlagener oder zurückgewiesener Befehl den Zustand nicht ändert.
-
Verweise zwischen normativ und informativ aufgeteilt.
-
Authentifizierungsfehlerprobleme im Sicherheitsabschnitt erörtert.
-
Klargestellt, dass ein Datenelement nicht notwendigerweise von nur einem Datentyp ist.
-
Klargestellt, dass Sequenzbereiche (sequence ranges) unabhängig von der Reihenfolge sind.
-
Ein Beispiel geändert, um zu klären, dass überflüssige Shifts in Modified-UTF7 nicht einfach durch Weglassen des Shifts behoben werden können. Die gesamte Zeichenkette muss neu berechnet werden.
-
Definition der Envelope-Structure geändert, da [RFC-2822] „envelope" verwendet, um den [SMTP]-Umschlag und nicht die Umschlagdaten zu bezeichnen, die im [RFC-2822]-Header erscheinen.
-
RFC822.HEADER-Antwortdaten gegenüber BODY[HEADER] ausgeführt.
-
Logout-Zustandssemantik geklärt, ASCII-Kunst geändert.
-
Sicherheitsänderungen zur Einhaltung der IESG-Anforderungen.
RFC 3501 IMAPv4 March 2003
-
Definition für Body-URI hinzugefügt.
-
Sequenzbereichsdefinition in drei Regeln aufgeteilt, mit neu geschriebenen Beschreibungen für jede.
-
STARTTLS und LOGINDISABLED hierher aus [IMAP-TLS] verschoben.
-
Abschnitt „IANA Considerations" hinzugefügt.
-
Gültige Client-Annahmen für neue Nachrichten-UIDs gegenüber UIDNEXT geklärt.
-
Klargestellt, dass Änderungen an permanentflags gleichzeitige Sitzungen ebenso wie nachfolgende Sitzungen betreffen.
-
Klargestellt, dass der authentifizierte Zustand über den CLOSE- Befehl erreicht werden kann.
-
Betont, dass SELECT und EXAMINE die Ausnahmen von der Regel sind, dass ein fehlschlagender Befehl den Zustand nicht ändert.
-
Klargestellt, dass neu angehängte Nachrichten das Recent-Flag gesetzt haben.
-
Klargestellt, dass neu kopierte Nachrichten das Recent-Flag gesetzt HABEN SOLLTEN.
-
Klargestellt, dass UID-Befehle immer die UID in FETCH-Antworten zurückgeben.
C. Stichwortverzeichnis (Key Word Index)
+FLAGS \<flag list> (store command data item) ............... 59
+FLAGS.SILENT \<flag list> (store command data item) ........ 59
-FLAGS \<flag list> (store command data item) ............... 59
-FLAGS.SILENT \<flag list> (store command data item) ........ 59
ALERT (response code) ...................................... 64
ALL (fetch item) ........................................... 55
ALL (search key) ........................................... 50
ANSWERED (search key) ...................................... 50
APPEND (command) ........................................... 45
AUTHENTICATE (command) ..................................... 27
BAD (response) ............................................. 66
BADCHARSET (response code) ................................. 64
BCC \<string> (search key) .................................. 51
BEFORE \<date> (search key) ................................. 51
BODY (fetch item) .......................................... 55
BODY (fetch result) ........................................ 73
BODY \<string> (search key) ................................. 51
RFC 3501 IMAPv4 March 2003
BODY.PEEK[\<section>]\<\<partial>> (fetch item) ............... 57
BODYSTRUCTURE (fetch item) ................................. 57
BODYSTRUCTURE (fetch result) ............................... 74
BODY[\<section>]\<\<origin octet>> (fetch result) ............. 74
BODY[\<section>]\<\<partial>> (fetch item) .................... 55
BYE (response) ............................................. 67
Body Structure (message attribute) ......................... 12
CAPABILITY (command) ....................................... 24
CAPABILITY (response code) ................................. 64
CAPABILITY (response) ...................................... 68
CC \<string> (search key) ................................... 51
CHECK (command) ............................................ 47
CLOSE (command) ............................................ 48
COPY (command) ............................................. 59
CREATE (command) ........................................... 34
DELETE (command) ........................................... 35
DELETED (search key) ....................................... 51
DRAFT (search key) ......................................... 51
ENVELOPE (fetch item) ...................................... 57
ENVELOPE (fetch result) .................................... 77
EXAMINE (command) .......................................... 33
EXISTS (response) .......................................... 71
EXPUNGE (command) .......................................... 48
EXPUNGE (response) ......................................... 72
Envelope Structure (message attribute) ..................... 12
FAST (fetch item) .......................................... 55
FETCH (command) ............................................ 54
FETCH (response) ........................................... 73
FLAGGED (search key) ....................................... 51
FLAGS (fetch item) ......................................... 57
FLAGS (fetch result) ....................................... 78
FLAGS (response) ........................................... 71
FLAGS \<flag list> (store command data item) ................ 59
FLAGS.SILENT \<flag list> (store command data item) ......... 59
FROM \<string> (search key) ................................. 51
FULL (fetch item) .......................................... 55
Flags (message attribute) .................................. 11
HEADER (part specifier) .................................... 55
HEADER `<field-name>` \<string> (search key) .................. 51
HEADER.FIELDS `<header-list>` (part specifier) ............... 55
HEADER.FIELDS.NOT `<header-list>` (part specifier) ........... 55
INTERNALDATE (fetch item) .................................. 57
INTERNALDATE (fetch result) ................................ 78
Internal Date (message attribute) .......................... 12
KEYWORD \<flag> (search key) ................................ 51
Keyword (type of flag) ..................................... 11
LARGER \<n> (search key) .................................... 51
LIST (command) ............................................. 40
RFC 3501 IMAPv4 March 2003
LIST (response) ............................................ 69
LOGIN (command) ............................................ 30
LOGOUT (command) ........................................... 25
LSUB (command) ............................................. 43
LSUB (response) ............................................ 70
MAY (specification requirement term) ....................... 4
MESSAGES (status item) ..................................... 45
MIME (part specifier) ...................................... 56
MUST (specification requirement term) ...................... 4
MUST NOT (specification requirement term) .................. 4
Message Sequence Number (message attribute) ................ 10
NEW (search key) ........................................... 51
NO (response) .............................................. 66
NOOP (command) ............................................. 25
NOT `<search-key>` (search key) .............................. 52
OK (response) .............................................. 65
OLD (search key) ........................................... 52
ON \<date> (search key) ..................................... 52
OPTIONAL (specification requirement term) .................. 4
OR `<search-key1>` `<search-key2>` (search key) ................ 52
PARSE (response code) ...................................... 64
PERMANENTFLAGS (response code) ............................. 64
PREAUTH (response) ......................................... 67
Permanent Flag (class of flag) ............................. 12
READ-ONLY (response code) .................................. 65
READ-WRITE (response code) ................................. 65
RECENT (response) .......................................... 72
RECENT (search key) ........................................ 52
RECENT (status item) ....................................... 45
RENAME (command) ........................................... 37
REQUIRED (specification requirement term) .................. 4
RFC822 (fetch item) ........................................ 57
RFC822 (fetch result) ...................................... 78
RFC822.HEADER (fetch item) ................................. 57
RFC822.HEADER (fetch result) ............................... 78
RFC822.SIZE (fetch item) ................................... 57
RFC822.SIZE (fetch result) ................................. 78
RFC822.TEXT (fetch item) ................................... 58
RFC822.TEXT (fetch result) ................................. 79
SEARCH (command) ........................................... 49
SEARCH (response) .......................................... 71
SEEN (search key) .......................................... 52