Zusammenfassung

  • RFC 822 vom August 1982 trennte offiziell veröffentlichte Erweiterungsfelder der E-Mail von benutzerdefinierten Feldern. Erstere durften nicht mit X- beginnen; Letztere bekamen damit einen geschützten Namensraum.
  • Diese Trennung hinterließ später Aliasarbeit. RFC 2068 vom Januar 1997 empfahl für HTTP, x-gzip und x-compress aus Kompatibilitätsgründen wie gzip und compress zu behandeln. RFC 5064 vom Dezember 2007 standardisierte Archived-At, beschrieb und registrierte aber auch dessen Vorläufer X-Archived-At.
  • RFC 6648 vom Juni 2012 riet vom Präfix für neu benannte textuelle Anwendungsprotokollparameter ab. Implementierungen sollten Standardisierungsgrad und Sicherheit nicht aus der Schreibweise ableiten; Register sollten den Status dokumentieren.

Ein reserviertes Fach für private Ideen

Ein Nachrichtenfeld besteht aus Name und Wert. Empfangende Programme lesen den Namen, um den Wert richtig zu behandeln. Wenn zwei Gruppen denselben Namen für verschiedene Dinge wählen, entsteht beim Austausch ein Konflikt. Ein eigener Bereich für lokale Versuche schien deshalb vernünftig. Entwickler konnten etwas ausprobieren, ohne vorher eine offizielle Spezifikation durchzusetzen, und den künftigen Standards blieben unbesetzte Namen.

RFC 822, veröffentlicht im August 1982, machte diese Aufteilung für E-Mail ausdrücklich. Formal veröffentlichte Erweiterungen sollten niemals mit X- beginnen. Von Benutzern definierte Felder erhielten so einen geschützten Bereich. Eine Organisation konnte ihren Nachrichten zusätzliche Informationen geben, ohne schon für jede Idee einen allgemein anerkannten Feldnamen zu benötigen.

Der Haken lag im Wort „Name“. Für Menschen erklärte X- den gegenwärtigen Status: privat, örtlich oder experimentell. Ein Programm interpretiert die Zeichen als Teil des Identifikators. Wer für X-Beispiel Code geschrieben hat, erkennt Beispiel nach einer späteren offiziellen Zulassung nicht plötzlich von selbst. Eine Institution kann den Status ändern; die alten Bytes in Software und gespeicherten Nachrichten bleiben.

Solange niemand ein Feld benutzt, ist Umbenennung leicht. Ein erfolgreicher Versuch wird aber gerade deshalb schwierig umzubenennen, weil Sender ihn verwenden, Empfänger ihn lesen und Archive ihn erhalten. Der offizielle Name tritt hinzu, während der vermeintlich vorläufige weiter gebraucht wird.

HTTP bezahlt schon 1997 für zwei Schreibweisen

Eine knappe Regel in RFC 2068 vom Januar 1997 zeigt die Kosten. Für die Kompatibilität mit früheren HTTP-Implementierungen sollten Anwendungen x-gzip wie gzip und x-compress wie compress behandeln. Der Standard konnte sich nicht auf einen schönen Namen beschränken. Die frühere Schreibweise war bereits Teil der Eingaben, auf die laufende Programme vorbereitet waren.

Das betrifft die Verarbeitung und nicht bloß Stilfragen. Ein Sender kann die Inhaltskodierung unter einem der beiden Namen ankündigen. Ein Empfänger, der nur den anderen kennt, behandelt den Inhalt womöglich falsch. Weiterleitende und archivierender Systeme müssen die Beziehung ebenso kennen. Die experimentelle Kennzeichnung wurde zum Gegenstand einer offiziellen Kompatibilitätsregel.

Bei E-Mail verschob sich die Regel selbst. RFC 2822 vom April 2001 ersetzte RFC 822 und beschrieb optionale Felder ohne dessen alte grammatische Trennung zwischen formalen Erweiterungen und Benutzerfeldern. Das Entfernen der Trennung aus einem neuen Dokument änderte keine bereits verschickte Nachricht. Auch die Programme, die frühere Namen lasen, liefen weiter.

Noch deutlicher ist RFC 5064 vom Dezember 2007. Es definierte Archived-At, ein Mailfeld mit der Adresse einer archivierten Nachricht. Für die Rückwärtskompatibilität musste es zugleich X-Archived-At beschreiben. Die alte Form durfte gelesen, aber möglichst nicht mehr neu erzeugt werden. Sie wurde mit veraltetem Status neben der neuen Form registriert. Die formale Beförderung eines Felds machte seinen alten Namen zum offiziellen Teil der Migrationsbeschreibung.

Die Beispiele haben unterschiedliche Regeln. HTTP erklärt bestimmte Kodierungsnamen für gleichwertig. Der Mailstandard erlaubt das Lesen der alten und bevorzugt das Erzeugen der neuen Form. Keiner dieser Texte zählt, wie viele Systeme beide Namen zu einem bestimmten Zeitpunkt verwendeten. Dafür wären datierte Implementierungslisten oder Nachrichtenproben nötig. Dass die Standards die Brücke zwischen den Namen pflegen mussten, lässt sich unmittelbar nachlesen.

Der Name verliert seine Amtsplakette

RFC 6648, im Juni 2012 als IETF Best Current Practice veröffentlicht, zog aus solchen Fällen eine allgemeine Folgerung. Ein nicht standardisierter Parameter kann sich verbreiten. Wird er unter neuem Namen standardisiert, kennen ältere Implementierungen nur die Präfixform, während neue vielleicht nur den offiziellen Namen kennen. Um miteinander zu sprechen, behalten neue Implementierungen den alten Namen oft dauerhaft bei. Aus dem geschützten Versuchsraum wird ein faktischer Standardraum.

Für neu definierte textuelle Parameter von Anwendungsprotokollen riet die IETF deshalb vom X--Präfix ab. Bestehende Felder sollten ihre Betreuer selbst behandeln; keine pauschale Löschung wurde angeordnet. Private Experimente blieben erlaubt, und besondere Regeln einzelner Protokolle wurden nicht automatisch aufgehoben. Aufgegeben wurde die Idee, den aktuellen Verwaltungsstatus in die Zeichen des Drahtnamens einzubauen.

Auch Empfänger sollten ihre Entscheidungen ändern. Aus Vorhandensein oder Fehlen von X- allein dürfen sie nicht auf den Standardisierungsstatus schließen. Ebenso wenig darf die bloße Schreibweise bestimmen, ob ein Feld als sicher gilt. Ein Name identifiziert Daten; er bescheinigt weder Registrierung noch Sicherheitsprüfung.

Stattdessen sollten Protokolldesigner große, brauchbare Register mit einfachen Verfahren schaffen, gegebenenfalls mit vorläufigen und dauerhaften Einträgen. Auch ein Name mit Präfix darf registriert werden. Entscheidend ist, was das Register über ihn festhält, nicht welche zwei Zeichen vorne stehen. Der Status kann sich dort ändern, ohne dass jeder Empfänger einen zweiten Namen lernen muss.

RFC 6648 warnte zudem vor blindem Gleichsetzen. Bei der Standardisierung können sich Semantik oder Sicherheitseigenschaften eines Versuchsfelds ändern. Ein Programm, das überall X- entfernt und die neue Form als identisch annimmt, kann dadurch neue Fehler erzeugen. RFC 2068 enthält eine spezifische Gleichwertigkeitsregel für x-gzip; es formuliert kein allgemeines Umschreibeverfahren für sämtliche Felder.

Ein erfolgreicher Versuch hinterlässt einen alten Namen

Die Ordnung von 1982 verschaffte Entwicklern Freiheit zum Testen. Die Revision von 2012 hielt fest, was Erfolg mit einem Namen macht: Software verarbeitet ihn, Archive bewahren ihn, andere Teilnehmer rechnen mit ihm. Wenn das zuständige Gremium später einen neuen Namen veröffentlicht, besitzt der alte bereits Nutzer, die sich nicht durch einen Beschluss aktualisieren lassen.

Die Kosten stehen in den Originaldokumenten. Der HTTP-Standard von 1997 verband zwei Namen für eine Kodierung. Der Mailstandard von 2007 registrierte den veralteten Vorläufer neben dem Nachfolger. Wie häufig die Namen tatsächlich verwendet wurden, ließe sich nur mit datierten Betriebsbelegen messen. Die Machtverteilung ist dennoch sichtbar. Das Gremium kann den Registereintrag ändern; laufende Programme und alte Nachrichten bestimmen, wie lange ein Name noch gelesen werden muss.

RFC 6648 räumte die alte Schublade nicht aus. Es bat die nächsten Designer, keine neue zu bauen. Der Status eines Experiments lässt sich in einem Register festhalten und später ändern. Sein Name im Protokoll muss dabei nicht jedes Mal mitwandern.