Zusammenfassung

  • Die Märzausgabe von RFC 1410 warnte ausdrücklich davor, diese Fassung nach dem 31. Juli 1993 zu benutzen. Selbst die amtliche Statusliste galt nur für ihren Zeitpunkt.
  • Ein Stufenwechsel brauchte eine Empfehlung des IESG und die Bestätigung des IAB. Das IAB konnte die Vorlage an die IETF zurückgeben; Wartezeiten und unabhängig gebaute Software waren weitere Hürden.

Ein amtliches Verzeichnis, das sein eigenes Ablaufdatum druckt, nimmt Veränderung ernst. RFC 1410 vom März 1993 forderte zur Prüfung der aktuellen Ausgabe auf und untersagte die Nutzung dieser Fassung nach dem 31. Juli. Der Status eines Protokolls konnte weiterwandern. Das Papier mit dem Status musste durch eine neue Ausgabe ersetzt werden.

Die Stufen hießen Proposed Standard, Draft Standard und Standard. Der größte Teil der Entwicklungsarbeit lag bei Arbeitsgruppen der IETF. Für jeden Schritt nach oben empfahl die Internet Engineering Steering Group den Übergang; das Internet Architecture Board bestätigte ihn. Verweigerte das IAB die Bestätigung, ging die Vorlage zur weiteren Arbeit an die IETF zurück. Zwei Gremien, zwei Entscheidungen und ein ausdrücklich beschriebener Weg rückwärts: So wurde aus einem Vorschlag ein überprüfbarer Status.

Auch die Uhr gehörte zum Verfahren. Ein Proposed Standard musste mindestens sechs Monate warten, ehe er Draft Standard werden konnte. Ein Draft Standard musste mindestens vier Monate warten, ehe er Standard werden konnte. Beide Untergrenzen gaben der Gemeinschaft Zeit für Einwände. Für Draft nannte der Text außerdem eine Erwartung: Ohne schwerwiegende Einwände oder Mängel sei eine Beförderung zu Standard binnen sechs Monaten wahrscheinlich. Diese Erwartung war kein zusätzlicher Mindestzeitraum.

Dann kam die Frage, die sich mit einer Abstimmung nicht erledigt: Können getrennt entwickelte Programme miteinander reden? Nach allgemeiner Praxis verlangte das IAB für Proposed zu Draft mindestens zwei unabhängige Implementierungen. Für den letzten Schritt zählten im Regelfall Betriebserfahrung und nachgewiesene Interoperabilität von mindestens zwei Implementierungen. Ein Dokument kann auf dem Tisch geschlossen wirken. Erst Software aus verschiedenen Händen zeigt, ob die Beschreibung für denselben Austausch reicht.

Für strittige Fälle gab es noch einen Weg zu einer technischen Entscheidung. Das IAB konnte eine besondere Kommission aus Fachleuten von IETF, IRTF und IAB zusammenrufen; sie sollte dem IAB eine konkrete Handlung empfehlen. Die Regel zur Rückgabe an die IETF steht im Verfahrensabschnitt von RFC 1410. Einen namentlich dokumentierten Rückgabefall führt diese Ausgabe nicht auf. Wer einen solchen Vorgang behaupten will, braucht das Sitzungsprotokoll und den weiteren Weg des betroffenen Vorschlags.

Heute führt der RFC Editor diese Ausgabe selbst als Historic; RFC 1500 löste sie ab. Die Ausgabe nennt konkrete Statuswechsel: RFC 1305 zum Network Time Protocol Version 3 stieg auf Draft Standard; der IEEE 802.4 Token Bus MIB (RFC 1230) wechselte zu Historic. Die Tabelle zeigt diese Entscheidungen, ohne eine einzelne Akte zu Implementierung und Interoperabilität mitzuliefern.

Die Antwort des Jahres 1993 war auffallend handfest. Empfehlung, Bestätigung, Zeit und unabhängige Implementierungen mussten zusammenkommen. Schließlich verfiel die Liste selbst. Ihr Datum war Teil der Aussage, nicht Fußnote am Rand.