Zusammenfassung

  • Zwei in RFC 1957 genannte Clients scheiterten, wenn dem Statusindikator kein Leerzeichen folgte, obwohl RFC 1939 dieses ohne Zusatztext nicht verlangte.
  • Der verbreitete UCB-Server popper lieferte immer Zusatzinformationen und damit auch immer das Leerzeichen, an das sich Parser gewöhnten.
  • Netscape verlangte UIDL und Eudora TOP, obwohl RFC 1939 beide Befehle als optional führte.

Eine knappe POP3-Antwort durfte nach +OK oder -ERR enden, wenn nichts mehr mitzuteilen war. Erst zusätzlicher Text brachte das trennende Leerzeichen mit. Die schriftliche Sprache des Protokolls enthielt also auch die kurze Form.

Der verbreitete UCB-Server popper, später von Qualcomm weiterentwickelt, sendete diese Form offenbar nicht. Er hängte stets Informationen an den Statusindikator und erzeugte dadurch stets ein Leerzeichen. Die Entscheidung war zulässig. Ihre Gleichförmigkeit machte sie jedoch zu einem stillen Testvektor für andere Programme.

RFC 1957 nennt den frei kopierbaren Unix-Client popclient und das proprietäre netApp Systems Internet Series. Beide waren beobachtet worden, wie sie das Leerzeichen erwarteten und ohne es ausfielen. Ein neuer Server konnte damit die Spezifikation erfüllen und dennoch an der tatsächlich installierten Gegenstelle scheitern.

Das ist mehr als ein Parserfehler. Die Spezifikation beschreibt einen zulässigen Verhaltensraum. Eine häufige Implementierung nutzt nur einen Teil davon. Clients, die fast ausschließlich gegen sie entwickelt werden, akzeptieren schließlich ebenfalls nur diesen Teil. Aus einem Beispiel wird eine Eintrittsbedingung, ohne dass ein normativer Satz geändert wurde.

RFC 1957 hält die Übergangsfrage offen und beantwortet sie zugleich praktisch. Die Autoren beider Clients waren kontaktiert worden; neue Versionen sollten das Leerzeichen nicht mehr erwarten. Alte Versionen sollten trotzdem unterstützt werden. Korrektur und Kompatibilität haben unterschiedliche Fristen. Der Parser muss breiter werden, während die bestehende Abhängigkeit vorübergehend weiter bedient wird.

Bei optionalen Funktionen entsteht derselbe Druck. RFC 1939 führt TOP und UIDL in seinem Abschnitt zu optionalen POP3-Befehlen. Laut RFC 1957 verlangte Netscape UIDL und Eudora TOP. Entscheidend ist hier nicht die interne Semantik der Befehle, sondern die Verschiebung der Wahl: Was der Server formal weglassen durfte, musste er praktisch anbieten, wenn diese Clients zu bedienen waren.

Eine klare Fähigkeitserkennung fehlte. RFC 1939 bot keine allgemeine Methode, einen nicht implementierten optionalen Befehl von einer situativen Weigerung oder Unfähigkeit zu unterscheiden. RFC 2449 beschrieb 1998 optionale Merkmale, die nur durch Ausprobieren erkennbar waren, wenn überhaupt, und führte CAPA zur Ankündigung unter anderem von TOP und UIDL ein. Das machte Unterschiede ausdrücklicher, belegt aber weder eine direkte Ursache durch RFC 1957 noch eine lückenlose Einführung.

Die Quellenlage setzt enge Grenzen. RFC 1957 ist eine informationelle Notiz vom Juni 1996, die den Standards-Track RFC 1939 aktualisiert. Sie berichtet benannte Beobachtungen, keine Statistik. Installationszahlen, Fehlerhäufigkeit, Kosten und Absichten fehlen. Sie erklärt weder popper für regelwidrig noch die optionalen Befehle für normativ verpflichtend.

Laufender Code zeigt somit die tatsächliche Bruchkante. Er entscheidet aber nicht allein, welche Kante bestehen bleiben soll. Verbreitung kann einer Eigenheit praktische Macht geben; Legitimität entsteht daraus nicht automatisch. Gute Interoperabilität schützt die vorhandene Nutzung und bewahrt zugleich die Möglichkeit, den Unfall wieder aus dem Protokoll zu entfernen.

Quellen