Kurz erklärt: Request for Comments
Kommentarisch
Wer mehr über ein Netzprotokoll wie TCP erfahren möchte, wird im Usenet und anderswo immer wieder auf Dokumente mit der Bezeichnung RFC verwiesen: Das Akronym steht für Request for Comments.
Die Geschichte der Requests for Comments (RFCs) beginnt – wie vieles aus der Anfangszeit des Internets – mit dem Projekt ARPANET, einem dezentralen paketvermittelnden Computernetz. 1969 beschlossen die Beteiligten, technische Spezifikationen und Dokumente mit der Community zu teilen. Es handelte sich dabei um eine Anwendung des später als Linus’ Law bekannt gewordenen Grundsatzes der Softwareentwicklung: Wer ein Problem mit genug Augen betrachtet, findet jeden Fehler.
RFCs liegen als Textdateien im ASCII-Format vor. Die bei manchen Protokollen angebotenen PDFs mit zusätzlichen Grafiken sind im Zweifelsfall nicht bindend, sie können gegenüber der Textdatei veraltet sein. Derzeit stellt die IETF (Internet Engineering Task Force) auf ein XML-basiertes Format um: Zukünftige RFCs dürfen demnach Bilder enthalten.
Lebenszyklus einer RFC
Das Leben jeder RFC beginnt als Internet-Draft (I-D), einem von der IETF bereitgestellten Arbeitsdokumentformat. I-Ds lassen sich mit dem Upload-Tool unter datatracker.ietf.org/submit hochladen. Werden die Dateien nicht innerhalb von 185 Tagen durch eine neue Version ersetzt, verfallen sie.
Vom Internet Architecture Board, der IETF oder der Internet Research Task Force stammende I-Ds werden bei Bedarf automatisch zur RFC erhoben. Von Dritten hochgeladene I-Ds nimmt der RFC-Editor per E-Mail entgegen: Bei Wohlgefallen werden die RFCs zur Kommentierung und Diskussion online gestellt.
Alle als Internetstandard vorgesehenen Spezifikationen durchlaufen einen mehrstufigen Prozess. Proposed Standards stehen am Anfang der Entwicklung: Laut RFC 2026 ist für diese Bezeichnung nicht einmal eine funktionierende Implementierung notwendig.
Draft-Standards unterscheiden sich davon insofern, als sie das Vorhandensein von mindestens zwei Implementierungen unterschiedlicher Hersteller voraussetzen. Die beiden Stacks müssen zudem zusammenarbeiten. Ist sie technisch ausgereift, bekommt die RFC eine STD-Nummer zugewiesen und ist fortan ein offizieller Standard. In RFC 2026 findet sich dazu folgende Passage:
„An Internet Standard … is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.“
Neben als Standard vorgesehenen Spezifikationen gibt es experimentelle, informatorische und historische Dokumente. Experimentelle RFCs beschreiben Protokolle, die im Rahmen eines Forschungsprozesses entstanden und für die Community interessant sind. Informational Specifications beschreiben meist „nicht implementierbare“ Produkte oder Informationen (siehe „Alle Links“).
RFCs sind in amerikanischem Englisch geschrieben. RFC 7322 spezifiziert stilistische Richtlinien und Ansprüche an die Formatierung: Unter anderem ist der Aufbau des Inhaltsverzeichnisses vorgegeben. In RFC 2119 finden sich Definitionen von Wörtern wie Must und Should – hält ein Autor diese Richtlinien nicht ein, riskiert seine Spezifikation die Disqualifizierung.
Eine veröffentlichte RFC ändert sich nicht mehr. Dies ist von der IETF gewünscht, schließlich handelt es sich um ein Archivierungsformat. Fehler werden entweder durch Veröffentlichen eines Erratums oder einer neuen RFC korrigiert. Die unter www.rfc-editor.org/standards einsehbare Liste bietet einen Überblick über aktuelle Versionen von RFCs, die verbreitete Protokolle beschreiben.
Wer eine RFC einreichen oder kommentieren wollte, kontaktierte (bis zu dessen Tod 1998) Jonathan Postel. Seitdem wechselte das Amt mehrfach: Derzeit liegt es beim Beratungsunternehmen Association Management Solution LLC (AMS), das im Auftrag der IETF handelt.
Das Unternehmen AMS betreibt zwei separate Datenströme: Von der IETF kommende Spezifikationen bearbeitet es selbst, während die Arbeit an Dokumenten von Dritten (Independent Submissions) im ersten Schritt externe Bearbeiter übernehmen. In beiden Fällen bekommt der Autor des Dokuments Feedback – erst nach seiner Bearbeitung wird die RFC hochgeladen.
Diese Organisation ist zudem für das Vorhalten der RFCs zuständig. Wer eine RFC herunterladen möchte, kann dies unter www.rfc-editor.org/retrieve/ tun. Die Dokumentennummer dient als eindeutige Identifikation, die sich in URLs einbauen lässt. (tiw)