Zusammenfassung

  • RFC 2062 entfernte alte IMAP-Formen aus der Hauptspezifikation, bewahrte aber eine begrenzte Landkarte für Begegnungen mit früheren Implementierungen.
  • Neue Server mussten veraltete Befehle nicht unterstützen und durften alte Antworten im Allgemeinen nicht mehr senden; Clients behielten genau bestimmte Empfangsregeln.
  • Eine alte Eingabe verstehen zu können, gab dem Sender kein dauerhaftes Recht, sie weiter zu erzeugen.

Beide Enden einer Verbindung werden selten gleichzeitig erneuert. Eine Zeit lang muss neue Software die Vergangenheit hören, ohne sie selbst zu sprechen. RFC 2062 ordnete diese Asymmetrie in nur acht Seiten.

Das Informational-Dokument erklärte ausdrücklich, keinen Internetstandard festzulegen. Es sammelte Syntax aus RFC 1176, experimentellen IMAP2bis-Varianten und RFC 1730, nachdem IMAP4rev1 sie aus dem Haupttext entfernt hatte. Dokumentation blieb erhalten; Produktionsautorität nicht.

Zu den alten Befehlen gehörten FIND ALL.MAILBOXES, FIND MAILBOXES, SUBSCRIBE MAILBOX, UNSUBSCRIBE MAILBOX und PARTIAL. Auch FETCH-Formen wie BODY[0] und RFC822.HEADER.LINES wurden archiviert. Neue Server waren nicht verpflichtet, sie zu implementieren. Unterstützung für einen alten Client war eine freiwillige Brücke, keine Empfehlung an neue Clients.

PARTIAL zeigt, dass Ersatz mehr als Umbenennung war. Die Daten kamen in einer FETCH-Antwort zurück, ohne dass die Antwort den gelieferten Bereich auswies. Mehrere Befehle konnten außer Reihenfolge ausgeführt werden; der Client musste daher jeden Schritt verarbeiten und synchronisieren. Eine neuere Teilabfrage konnte eine ähnliche Funktion mit deutlicherer Zuordnung von Anfrage und Ergebnis erfüllen.

Für alte Antworten galten verschiedene Regeln. Neue Server durften sie grundsätzlich nicht senden. MAILBOX war nur als Antwort auf alte FIND-Befehle erlaubt. Ein Client musste die experimentelle COPY-Antwort ignorieren und STORE wie FETCH behandeln. Empfangskompatibilität konnte also bedingtes Parsen, unschädliches Verwerfen oder semantische Normalisierung bedeuten.

RFC 2683 warnte später ausdrücklich davor, Toleranz in Erlaubnis umzudeuten: Dass manche Server alte Befehle akzeptierten, machte deren Versand nicht gültig. RFC 2061 trennte Kompatibilitätshinweise ebenfalls von den Basisanforderungen und riet davon ab, alte Bboard-Befehle selbst für frühere Clients neu einzuführen. Toleranz war ein Ausgang, keine Verlängerung.

RFC 3501 behielt RFC 2062 als historischen Kontext. RFC 9051 machte die Wahl zwischen IMAP4rev1 und IMAP4rev2 durch Fähigkeiten und ENABLE IMAP4rev2 sichtbar. Ein Server, der beide Revisionen nennt, gibt entfernte Formen normalerweise nur bei entsprechendem Verhalten eines rev1-Clients aus. Das ist eine spätere Parallele, kein Beleg direkter Verursachung.

Für den Betrieb beweist ein erfolgreicher Parser-Test nur Empfangsfähigkeit, nicht konfigurierte Ausgabe. FIND-Toleranz beweist nicht, dass ein Client FIND senden soll. Ein IANA-Eintrag beweist weder Verbreitung noch die Bytes einer konkreten Sitzung.

Nachweisbarer Rückzug trennt vier Datensätze: akzeptierte Eingabegrammatik, gewählte Ausgabegrammatik, ausgehandelten Modus und beobachteten Verkehr. Zuerst endet die alte Ausgabe. Dann werden verbliebene Eingaben gemessen, Ausnahmen an bekannte Gegenstellen gebunden und der Parser erst nach dem belegten Ende des Bedarfs entfernt. So bleibt Kompatibilität eine begrenzte Empfangspflicht statt einer dauerhaften Produktionslizenz.

Quellen