Request for Comments

Wesen und Bedeutung

Requests for Comments (RFC; englisch für „Bitte um Kommentare“) sind technische und organisatorische Dokumente zum Internet, ursprünglich zum ARPANET. Sie werden seit dem 7. April 1969 vom RFC-Editor herausgegeben. Ursprünglich waren sie zur öffentlichen Diskussion gedachte Dokumente; heute findet die Diskussion meist während der Erstellung der Entwürfe statt. Ein veröffentlichter RFC ist daher in der Regel eine begutachtete technische Spezifikation.

Nicht jeder RFC ist ein Internetstandard. RFCs standardisieren jedoch die Internetprotokollfamilie und bilden damit die technische Grundlage vieler Internetanwendungen. Beispiele sind IPv6 (RFC 8200), TCP (RFC 793), UDP (RFC 768), SMTP (RFC 5321) und HTTP/2 (RFC 7540).

Veröffentlichung und Dokumentenreihen

Alle RFCs werden vor der Veröffentlichung begutachtet. Die Anforderungen unterscheiden sich danach, ob ein Internetstandard angestrebt wird. Künftige Internetstandards müssen besonders hohe Anforderungen erfüllen und einen Konsens der Internet Engineering Task Force (IETF) darstellen.

Vor der Veröffentlichung werden Vorschläge als „Internet-Draft“ (I-D) online bereitgestellt. Internet-Drafts gelten als unfertig und sollen nicht als Referenz verwendet werden. Sie verfallen nach sechs Monaten, bleiben aber archiviert, sofern keine neue Entwurfsversion eingereicht oder der Publikationsprozess angestoßen wird.

Der RFC-Editor veröffentlicht neue RFCs mit fortlaufender Nummer als ASCII-Textdatei sowie in weiteren Formaten. Nach der Veröffentlichung wird ein RFC niemals verändert. Fehler werden als Errata dokumentiert, während das ursprüngliche Dokument unverändert bleibt. Eine neue, ersetzende Spezifikation wird nach dem üblichen Verfahren unter einer neuen RFC-Nummer veröffentlicht und erklärt das alte RFC für obsolet. Ein RFC kann auch nur einen Teil eines älteren Dokuments aktualisieren oder ergänzen.

Ausgewählte RFCs erscheinen zusätzlich in weiteren Reihen: STD enthält Internetstandards mit dem höchsten Reifegrad. BCP („Best Current Practice“) umfasst seit 1995 von der IETF gebilligte technische Informationen oder administrative Vorgaben, die keine Netzwerkprotokolle sind. FYI („For Your Information“) machte seit 1990 informative RFCs einem breiten Publikum einschließlich Anfängern zugänglich; die Reihe wurde 2011 eingestellt. Einzelne RARE Technical Reports (RTR) wurden ebenfalls als RFC veröffentlicht.

Genehmigungswege

Der Herkunft eines Dokuments entsprechend gibt es verschiedene Genehmigungsverfahren, sogenannte Streams. RFC 4844 definiert vier Streams:

• IETF: Das Dokument stammt von einer IETF-Arbeitsgruppe oder einem Area Director der Internet Engineering Steering Group. Nur dieser Stream darf künftige Internetstandards und Best Current Practices einreichen. Das Verfahren wird unter anderem in RFC 2026 beschrieben.
• IAB: Das Dokument stammt vom Internet Architecture Board; das Verfahren beschreibt RFC 4845.
• IRTF: Das Dokument stammt von der Internet Research Task Force; maßgeblich ist RFC 5743.
• Independent Submission: Ein unabhängiger Beitragender reicht das Dokument direkt beim RFC-Editor ein. Dafür ist kein technischer Konsens innerhalb der IETF erforderlich. Eine Veröffentlichung als Internetstandard ist deshalb ausgeschlossen. RFC 4846 beschreibt dieses Verfahren.

Status eines RFC

Jeder RFC besitzt einen Dokumentenstatus. Anders als der Inhalt kann dieser Status nachträglich geändert werden.

„Unknown“ bedeutet, dass kein Status zugeordnet ist; dies betrifft einige frühe RFCs. „Draft“ bezeichnet einen Entwurf und ist noch kein RFC. „Informational“ steht für informative Dokumente, etwa Terminologie-Erklärungen, Nutzungshinweise, Problemstellungen oder neue Ideen; gelegentlich gehören auch Antworten auf allgemeine Fragen und Nachrufe dazu. „Experimental“ bezeichnet eine Protokollspezifikation aus einem Forschungs- oder Entwicklungsvorhaben. Sie soll Erfahrungen sammeln, auf deren Grundlage später möglicherweise ein Internetstandard entsteht. Das Sender Policy Framework begann beispielsweise als experimentelles RFC 4408 und gelangte mit RFC 7208 in das Standardisierungsverfahren.

Ein Dokument mit dem Status „Best Current Practice“ erhält durch die Veröffentlichung in der BCP-Reihe verbindlichen Charakter. „Proposed Standard“ bezeichnet eine Spezifikation, die eine rigorose Begutachtung und Konsensfindung der zuständigen IETF-Arbeitsgruppe durchlaufen hat. „Draft Standard“ wird nicht länger als Status verwendet. „Internet Standard“ ist der höchste Reifegrad und wird zusätzlich in der STD-Reihe veröffentlicht.

„Historic“ kennzeichnet eine veraltete Spezifikation, deren Verwendung die IESG nicht mehr empfiehlt. „Obsolete“ wird verwendet, wenn eine Spezifikation durch ein neues RFC abgelöst wurde. Das alte Dokument kann dennoch weiterhin relevant sein, etwa weil es noch verbreitet ist.

Formaler Aufbau und Anforderungssprache

Die IETF und der RFC-Editor legen großen Wert auf nachvollziehbare und eindeutige Regeln. Änderungen an Vorschlägen werden bis zur formellen Veröffentlichung dokumentiert. Ein abschließend veröffentlichter RFC bleibt dauerhaft öffentlich und unverändert; er kann nur durch neuere RFCs abgelöst werden. Struktur und Stil sind durch RFC 7322 vorgegeben.

RFC 2119, zugleich BCP 14, definiert eine einheitliche Sprache für Anforderungen:

• MUST und MUST NOT, gleichbedeutend mit SHALL und SHALL NOT, sind zwingende Anforderungen.
• SHOULD und SHOULD NOT, gleichbedeutend mit RECOMMENDED und NOT RECOMMENDED, bezeichnen Empfehlungen, von denen in begründeten Fällen abgewichen werden kann.
• MAY, gleichbedeutend mit OPTIONAL, bezeichnet eine Option, deren Umsetzung dem Ermessen des Herstellers überlassen bleibt.

Zeichenketten und ihre Zusammensetzung werden häufig mit der Backus-Naur-Form (BNF) formal beschrieben. Dadurch lassen sich beispielsweise URLs und URIs eindeutig aufbauen. Der Formalismus soll Missverständnisse bei Interpretation und Implementierung vermeiden. Als Beispiele für diese Bedeutung nennt der Artikel RFC 2822 für E-Mail und RFC 2616 für HTTP.

Humor und praktisch umgesetzte Scherze

Neben technischen Standards und Best Current Practices gibt es scherzhafte RFCs, die nicht buchstabengetreu verstanden werden sollten, häufig zum 1. April. RFC 1925 vom 1. April 1996 nennt „The Twelve Networking Truths“ und beginnt mit „It Has To Work“. RFC 3251 parodiert MPLS als „Mostly Pointless Lamp Switching“. RFC 2795 behandelt das Infinite-Monkey-Theorem und die Koordination unendlich vieler Affen zur Erzeugung von Shakespeares Werken. Weitere Beispiele sind eine Lobeshymne auf das ARPANET (RFC 527), Wissenschaftsgeschichte in Versform (RFC 1121) und „The Twelve Days of Christmas“ aus der Sicht eines gestressten Netzwerk-Administrators (RFC 1882).

RFC 3092 vom 1. April 2001 bestimmte die Kombinationen von „foo“ und „bar“ etymologisch. RFC 3514 vom 1. April 2003 schlug ein „evil“-Bit in IP-Headern vor, damit Firewalls böse Pakete ausfiltern könnten. RFC 3751 vom 1. April 2004 beschrieb ein angeblich allwissendes Protokoll zur Erkennung und Verhinderung aller Formen von Computerkriminalität und endete wegen nicht erfüllbarer Anforderungen mit „Good luck.“ RFC 4041 stellte 2005 moralisch einwandfreies Routing vor, RFC 4042 ersetzte scherzhaft UTF-8 durch UTF-9 mit 9 Bits (3 × 3) pro Byte. Weitere Scherze waren IP über das Winkeralphabet (RFC 4824, 2007) und ein Transmission Control Protocol mit durch Emoticons festgelegter Laune des Segments (RFC 5841, 2010).

Einige Scherze wurden teilweise praktisch umgesetzt. Am 6. März 2001 wurde RFC 1149 zur Übertragung von IP-Datagrammen per Brieftaube implementiert. Ein Ping benötigte durchschnittlich 45 Minuten; eine regelmäßige Nutzung im Echteinsatz war daher nicht zu erwarten. Daraus entstand RFC 2549 „IP over Avian Carriers with Quality of Service“.

Emacs enthält eine vollständige Implementierung von RFC 2324, dem „Hyper Text Coffee Pot Control Protocol“ (HTCPCP) zur Fernsteuerung und Überwachung von Kaffeemaschinen. RFC 7168 erweiterte es am 1. April 2014 um die Nutzung von Tee. Für das „Pi Digit Generation Protocol“ gibt es außerdem mit gpigen eine freie Implementierung für mehrere Plattformen.