RFC Request for Comments

1. Warum sind RFCs nötig?

1. Warum sind RFCs nötig?

Die Einführung der Request for Comments (auf Deutsch: Bitte um Kommentare) war notwendig, da der offizielle Standardisierungsprozess langsamer arbeitet als die Weiterentwicklung der Internetprotokolle. So wurden wichtige elementare RFCs erst nachfolgend als offizielle Standards verabschiedet, obwohl sie bereits lange zuvor inoffiziell als solche angewandt wurden.

Nur wenige RFCs erreichen den Standardstatus. Dem liegt zugrunde, dass sich die an einem RFC mitwirkenden Personen beziehungsweise Gruppen in der Regel auf die Verbesserung der Protokolle und nicht auf den langwierigen Standardisierungsprozess konzentrieren. Dennoch wird im Zusammenhang mit Standards aus der Netzwerktechnik immer wieder auf RFCs verwiesen, da diese einen Teil des Standardisierungsprozesses im Internet bilden.

2. Die Systematik der RFCs

2. Die Systematik der RFCs

Seinem Namen entsprechend stellt ein Request for Comments technische Sachverhalte zu Diskussion, allerdings nur während der ersten Prüfungsphase durch die Internet Engineering Task Force. Ist der RFC veröffentlicht und durch allgemeine Anerkennung zu einem inoffiziellen Standard geworden, kann er nicht mehr verändert werden. Kleinere Fehler und Ergänzungen erscheinen als Errata.

Sind größere Änderungen nötig, wird ein neuer RFC geschrieben und eingereicht. Dadurch kann sich die Nummerierung des RFCs ändern. Da die alten RFCs nicht aus dem Verkehr gezogen werden, sondern auf ihnen lediglich die Nummer des neuen RFCs vermerkt wird, kann es passieren, dass zu einer Thematik mehrere RFCs existieren.

2.1 RFC und Veröffentlichungsverfahren

Vor der Veröffentlichung werden alle RFCs ausführlich begutachtet. Wie genau der Veröffentlichungsprozess abläuft und die darin vorgegebenen Anforderungen ausfallen, hängt davon ab, ob ein Internetstandard angestrebt wird oder nicht. So müssen werdende Internetstandards höhere Anforderungen erfüllen und einen einheitlichen Konsens innerhalb der Internet Engineering Task Force (IETF) erreichen.

Jeder eingereichte Entwurf wird von der IETF mit der Bezeichnung Internet-Draft (I-D) markiert und veröffentlicht. Dokumente mit dieser Markierung gelten als unfertig und eignen sich daher nicht als Referenz. Wird innerhalb von sechs Monaten keine neue Entwurfsversion eingereicht oder der Publikationsprozess angestoßen, verfallen die Internet-Drafts, die daraufhin online archiviert werden.

Der RFC-Editor gibt neue RFCs mit einer fortlaufenden Nummerierung als ASCII-Textdatei und in weiteren Dokumentenformaten heraus. Ist ein RFC erst einmal veröffentlicht, kann sein Inhalt nicht mehr verändert werden. Technische oder editorielle Korrekturen werden lediglich als Errata veröffentlicht, während das fehlerhafte RFC an sich unverändert bestehen bleibt.

Wenn ein RFC durch eine neue Spezifikation abgelöst werden soll, durchläuft diese den üblichen Prozess und wird anschließend unter einer neuen Nummer veröffentlicht. Inhaltlich bezieht sich das neue Dokument auf das alte und erklärt es für hinfällig. Dabei ist zu beachten, dass ein neuer RFC nur einen Teilaspekt eines bestehenden RFCs aktualisieren oder ergänzen kann.

Da sogenannte independent Submissions möglich sind, die die Prüfung durch die IETF umgehen, finden sich unter den RFCs auch solche, die scherzhaft gemeint sind. So beschäftigt sich zum Beispiel der RFC 2795 mit dem Infinite-Monkey-Theorem, das eine Möglichkeit zur Koordination einer unendlichen Anzahl von Affen beschreibt, die die Werke von Shakespeare reproduzieren sollen. Independent Submissions können nicht als Internetstandard veröffentlicht werden.

2.2 Formalien der RFCs

Die Gestaltung der RFCs unterliegt strengen Regeln. Der RFC 2223 gibt vor, wie RFCs zu schreiben sind, während im RFC 2119 die Bedeutung einzelner Begriffe festgelegt wird. Durch diese Maßnahmen sollen Fehlinterpretationen verhindert werden.

Des Weiteren gibt die IETF die folgenden Formalien vor:

• Vorschläge für neue oder geänderte RFCs werden vor der formellen Veröffentlichung dokumentiert.
• Ein endgültig veröffentlichter RFC kann nicht mehr zurückgezogen oder verändert, sondern nur durch einen neuen RFC abgelöst werden.

Folgende Begriffe sind in Ihrer Bedeutung festgelegt:

• Must und Must Not bzw. Shall und Shall Not geben an, dass eine Anforderung unbedingt eingehalten werden muss.
• Should und Should Not bzw. Recommended und Not Recommended bedeuten, dass eine Anforderung zwar empfohlen ist, aber in manchen Fällen davon abgewichen werden kann.
• May bzw. Optional gibt eine Option an, über deren Umsetzung der Hersteller selbst entscheiden kann.

2.3 Der Status eines RFCs

Jeder RFC besitzt einen bestimmten Status, der nachträglich geändert werden kann.

Dieser kann folgende Informationen enthalten:

• Informational: Der RFC enthält einen Hinweis oder eine Idee für die Netzgemeinde.
• Experimental: Der RFC ist zum Experimentieren gedacht.
• Draft Standard: Der RFC befindet sich in Begutachtung.
• Proposed Standard: Der RFC enthält einen Vorschlag für einen Standard.
• Standard: Der RFC ist bereits offiziell als Standard anerkannt.
• Historic: Der Standard wird nicht mehr genutzt.
• Requierd: Der RFC ist zwingend anzuwenden.
• Recommended/Suggested: Die Anwendung des RFCs wird empfohlen.
• Elective: Die Anwendung des RFCs ist freigestellt.