imported>Trustable: linkfix

2025-09-08T14:24:40Z

linkfix

Neue Seite

Die '''{{lang|en|Requests for Comments}}''' ('''{{lang|en|RFC}}'''; [[Englische Sprache|englisch]] für „Bitte um Kommentare“) sind eine Reihe technischer und organisatorischer Dokumente zum [[Internet]] (ursprünglich [[ARPANET]]), die seit dem 7. April 1969 vom [[RFC-Editor]] herausgegeben werden. Handelte es sich ursprünglich um im Wortsinne zur Diskussion gestellte Dokumente, so findet die Diskussion heute während der Erstellung der Entwürfe statt, sodass ein veröffentlichter RFC in der Regel eine begutachtete technische Spezifikation darstellt.<ref name="RFC8700" />

Einige RFCs, jedoch nicht alle, stellen [[Internetstandard]]s dar.<ref name="RFC1796" /> RFCs standardisieren die [[Internetprotokollfamilie]], beispielsweise [[IPv6]] (<nowiki>RFC 8200</nowiki><ref>{{RFC-Internet |RFC=8200 |Titel=Internet Protocol, Version 6 (IPv6) Specification |Datum=2017-07}}</ref>), [[Transmission Control Protocol|TCP]] (<nowiki>RFC 793</nowiki><ref>{{RFC-Internet |RFC=793 |Titel=Transmission Control Protocol |Datum=1981-09}}</ref>), [[User Datagram Protocol|UDP]] (<nowiki>RFC 768</nowiki><ref>{{RFC-Internet |RFC=768 |Titel=User Datagram Protocol |Datum=1980-08-28 |Autor=[[Jon Postel]]}}</ref>), [[Simple Mail Transfer Protocol|SMTP]] (<nowiki>RFC 5321</nowiki><ref>{{RFC-Internet |RFC=5321 |Titel=Simple Mail Transfer Protocol |Datum=2008-10}}</ref>) und [[Hypertext Transfer Protocol|HTTP/2]] (<nowiki>RFC 7540</nowiki><ref>{{RFC-Internet |RFC=7540 |Titel=Hypertext Transfer Protocol Version 2 (HTTP/2) |Datum=2015-05}}</ref>), und bilden damit die technische Grundlage von Internetanwendungen wie [[E-Mail]] oder dem [[World Wide Web]].

Der englischsprachige Begriff „RFC“ wird in deutschsprachigen Texten im Allgemeinen mit männlichem grammatischen Geschlecht verwendet („der RFC“).

== Publikationsverfahren ==
Alle RFCs werden vor der Veröffentlichung einer Begutachtung unterzogen. Der Veröffentlichungsprozess und die darin vorgegebenen Anforderungen unterscheiden sich, je nachdem, ob ein [[Internetstandard]] angestrebt wird oder nicht. Werdende Internetstandards müssen hohe Anforderungen erfüllen und einen Gemeinschaftskonsens der [[Internet Engineering Task Force]] (IETF) darstellen.

{{Anker|Internet-Draft}} Alle eingereichten Entwürfe werden von der IETF unter der Bezeichnung „''Internet-Draft''“ (I-D) im Internet veröffentlicht. Internet-Drafts gelten als unfertig und sollen nicht als Referenz verwendet werden. Sie verfallen nach Ablauf von sechs Monaten (bleiben jedoch weiterhin online archiviert), es sei denn es wird eine neue Entwurfsversion eingereicht oder der Publikationsprozess angestoßen.

Neue RFCs gibt der [[RFC-Editor]] mit einer fortlaufenden Nummerierung als [[American Standard Code for Information Interchange|ASCII]]-[[Textdatei]] sowie in weiteren Dokumentenformaten heraus. Sobald ein RFC veröffentlicht ist, wird der Inhalt nie mehr verändert. Korrekturen von editoriellen oder technischen Fehlern werden als [[Errata (Korrekturverzeichnis)|Errata]] veröffentlicht; das fehlerhafte RFC bleibt jedoch unverändert bestehen. Soll eine veraltete Spezifikation abgelöst werden, so durchläuft die neue Spezifikation den üblichen Prozess und wird unter einer neuen RFC-Nummer veröffentlicht. Das neue Dokument referenziert das alte RFC und erklärt es für obsolet. Ein neues RFC kann auch nur einen Teilaspekt eines bestehenden RFCs aktualisieren oder ergänzen, ohne dabei das gesamte Dokument zu invalidieren.

=== Dokumentenreihen ===
Ausgewählte RFCs werden zugleich in weiteren Dokumentenreihen mit jeweils eigenen Nummerierungen veröffentlicht.

; Internet Standard (STD)
: Internetstandards mit dem höchsten Reifegrad werden zusätzlich in der Dokumentenreihe STD veröffentlicht.
; [[Best Current Practice]] (BCP)
: Die Reihe BCP wurde 1995 für RFCs eingeführt, die technische Informationen oder administrative Vorgaben enthalten, die von der IETF gebilligt werden. Damit unterscheiden sich BCPs von rein informativen RFCs, zu denen die IETF keine Position bezieht. Die Veröffentlichung als Internetstandard scheidet hierbei aus, da es sich bei BCPs nicht um [[Netzwerkprotokoll]]e handelt.<ref>{{RFC-Internet |RFC=1818 |Titel=Best Current Practices |Datum=1995-08 |Errata=1}}</ref>
; For Your Information (FYI)
: Die Reihe FYI wurde 1990 eingeführt, um informative RFCs einem breiten Publikum bekannt zu machen, das ausdrücklich auch Anfänger umfasst.<ref>{{RFC-Internet |RFC=1150 |Titel=FYI on FYI |Datum=1990-03 |Errata=1}}</ref> Die Reihe wurde 2011 eingestellt.<ref name="RFC6360" />

Einzelne ''[[Reseaux Associes pour la Recherche Europeenne|RARE]] Technical Reports (RTR)'' wurden auch als RFC veröffentlicht.<ref>{{Internetquelle |url=https://www.rfc-editor.org/in-notes/museum/RAREreports/rtr-index.txt |titel=RTR Index |hrsg=RFC-Editor |sprache=en |abruf=2019-12-26}}</ref>

=== Genehmigungsverfahren ===
Es gibt unterschiedliche Genehmigungsverfahren für RFCs, je nachdem woher das Dokument stammt. Ein solches Verfahren wird als ''Stream'' bezeichnet. <nowiki>RFC 4844</nowiki> definiert die folgenden Streams:<ref>{{RFC-Internet |RFC=4844 |Titel=The RFC Series and RFC Editor |Datum=2007-07}}</ref>

; IETF
: Das Dokument stammt entweder von einer Arbeitsgruppe der IETF oder von einem Bereichsleiter (''Area Director'') der [[Internet Engineering Steering Group]]. Dieser Stream ist der einzige, der werdende [[Internetstandard]]s und [[Best Current Practice]]s einreichen darf. <nowiki>RFC 2026</nowiki><ref>{{RFC-Internet |RFC=2026 |Titel=The Internet Standards Process – Revision 3 |Datum=1996-10}}</ref> und weitere beschreiben das Verfahren.
; IAB
: Das Dokument stammt vom [[Internet Architecture Board]]. <nowiki>RFC 4845</nowiki><ref>{{RFC-Internet |RFC=4845 |Titel=Process for Publication of IAB RFCs |Datum=2007-07}}</ref> beschreibt das Verfahren.
; IRTF
: Das Dokument stammt von der [[Internet Research Task Force]]. <nowiki>RFC 5743</nowiki><ref>{{RFC-Internet |RFC=5743 |Titel=Definition of an Internet Research Task Force (IRTF) Document Stream |Datum=2009-12}}</ref> beschreibt das Verfahren.
; Independent Submission
: Das Dokument stammt von einem unabhängigen Beitragenden, der es direkt beim RFC-Editor einreicht. Es wird kein technischer Konsens innerhalb der IETF benötigt, wodurch eine Veröffentlichung als Internetstandard ausgeschlossen ist. <nowiki>RFC 4846</nowiki><ref>{{RFC-Internet |RFC=4846 |Titel=Independent Submissions to the RFC Editor |Datum=2007-07}}</ref> beschreibt das Verfahren.

== RFC-Status ==
Jedes RFC besitzt einen Dokumentenstatus, der im Gegensatz zum Inhalt nachträglich verändert werden kann.

; Unknown (unbekannt)
: Dem RFC ist kein Status zugeordnet. Dies trifft auf einige frühe RFCs zu.
; Draft (Entwurf)
: Kein RFC, da noch im Entwurfsstadium.
; Informational (informativ)
: Informatives Dokument jeglicher Art, beispielsweise Terminologie-Erklärungen, Nutzungshinweise, Problemstellungen oder neue Ideen. Vereinzelt kommen auch Antworten auf allgemeine Fragen oder Nachrufe vor.
; Experimental (experimentell)
: Protokollspezifikation, die als Teil eines Forschungs- oder Entwicklungsvorhaben entstand. Der Zweck ist es, innerhalb der Netzgemeinde weitere Erfahrung zu sammeln, um auf dieser Basis in der Zukunft ggf. einen Internetstandard zu entwerfen. Beispielsweise begann das [[Sender Policy Framework]] als experimentelles <nowiki>RFC 4408</nowiki><ref>{{RFC-Internet |RFC=4408 |Titel=Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 |Datum=2006-04}}</ref> und kam mit <nowiki>RFC 7208</nowiki><ref>{{RFC-Internet |RFC=7208 |Titel=Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 |Datum=2014-04}}</ref> in das Standardisierungsverfahren.
; Best Current Practice (beste gegenwärtige Praxis)
: Ein technisches Dokument, das durch Veröffentlichung in der Dokumentenreihe BCP einen verbindlichen Charakter erhält.
; Proposed Standard (vorgeschlagener Standard), Draft Standard (Standardisierungsentwurf) und Internet Standard
: Verschiedene Reifegrade eines [[Internetstandard]]s. ''Proposed Standards'' sind Spezifikationen, die eine rigorose Begutachtung und Konsensfindung der entsprechenden IETF-Arbeitsgruppe durchlaufen haben. ''Draft Standard'' wird nicht länger als Status verwendet.<ref name="RFC6410" /> ''Internet Standards'' haben die höchste Reife und werden zusätzlich in der Dokumentenreihe STD veröffentlicht.
; Historic (historisch) und Obsolete (überholt)
: Veraltete Spezifikationen werden von der IESG als ''Historic'' gekennzeichnet, wenn ihre Verwendung nicht mehr empfohlen ist. Wird eine Spezifikation durch ein neues RFC abgelöst, wird hingegen der Status ''Obsolete'' verwendet. Letzteres hat den Zweck überholte Spezifikationen zu kennzeichnen, die aber weiterhin relevant sind, etwa weil sie noch verbreitet sind.

== Formalismus ==
Die IETF und der RFC-Editor legen einen hohen Wert auf Formalismus:

* Vorschläge für neue oder geänderte RFCs werden in allen Änderungen vor der formellen Veröffentlichung nachvollziehbar dokumentiert.
* Ein einmal abschließend veröffentlichter RFC ist für immer öffentlich und fest. Er kann auch nicht korrigiert, sondern nur durch neuere RFCs abgelöst werden.
* Die Struktur und der Stil eines RFCs sind durch <nowiki>RFC 7322</nowiki> vorgegeben.<ref>{{RFC-Internet |RFC=7322 |Titel=RFC Style Guide |Datum=2014-09}}</ref>
* <nowiki>RFC 2119</nowiki><ref>{{RFC-Internet |RFC=2119 |Titel=Key words for use in RFCs to Indicate Requirement Levels |Datum=1997-03}}</ref> (BCP 14) legt die Terminologie von Anforderungen fest, die in ihrer Bedeutung klar definiert sind, um Missverständnisse in deren Interpretation zu vermeiden.
** ''MUST'' und ''MUST NOT'' (äquivalent: ''SHALL'' und ''SHALL NOT'') geben an, dass eine Anforderung zwingend eingehalten werden muss.
** ''SHOULD'' und ''SHOULD NOT'' (äquivalent: ''RECOMMENDED'' und ''NOT RECOMMENDED'') geben an, dass eine Anforderung empfohlen ist, aber in begründeten Fällen davon abgewichen werden kann.
** ''MAY'' (äquivalent: ''OPTIONAL'') gibt eine Option an, die im eigenen Ermessen des Herstellers umgesetzt werden kann.
* Zeichenketten und ihre Zusammensetzung werden formalistisch mittels der [[Backus-Naur-Form]] (BNF) dargestellt. Dies sorgt für eine eindeutige Interpretation, hilfreich zum Beispiel beim Aufbau von URLs und URIs.

All diese Formalismen sorgen für die Vermeidung von Missverständnissen in der Interpretation und Implementierung und somit für den Erfolg beim Betrieb des Internets. Als Beispiele hierfür und gleichermaßen für ihren Erfolg seien <nowiki>RFC 2822</nowiki><ref>{{RFC-Internet |RFC=2822 |Titel=Internet Message Format |Datum=2001-04}}</ref> (E-Mail) sowie <nowiki>RFC 2616</nowiki><ref>{{RFC-Internet |RFC=2616 |Titel=Hypertext Transfer Protocol – HTTP/1.1 |Datum=1999-06}}</ref> (HTTP) genannt.

== Humor in RFC ==
Zwischen den RFCs, die Internetstandards oder Best Current Practices beschreiben, finden sich auch immer wieder scherzhafte RFCs, die nicht buchstabengetreu genommen werden sollten, oft aus Anlass des [[1. April]].

* Das am 1. April 1996 veröffentlichte <nowiki>RFC 1925</nowiki><ref>{{RFC-Internet |RFC=1925 |Titel=The Twelve Networking Truths |Datum=1996-04-01}}</ref> listet ''The Twelve Networking Truths'' auf, die mit dem fundamentalen Grundsatz ''It Has To Work'' beginnen.
* Als Parodie auf das Routing-Protokoll [[Multiprotocol Label Switching|MPLS]] findet sich in <nowiki>RFC 3251</nowiki><ref>{{RFC-Internet |RFC=3251 |Titel=Electricity over IP |Datum=2002-04-01}}</ref> das ''Mostly Pointless Lamp Switching''.
* <nowiki>RFC 2795</nowiki><ref>{{RFC-Internet |RFC=2795 |Titel=The Infinite Monkey Protocol Suite (IMPS) |Datum=2000-04-01}}</ref> beschäftigt sich mit dem [[Infinite-Monkey-Theorem]] und beschreibt, wie eine unendliche Anzahl von Affen koordiniert werden kann, die die Werke von Shakespeare produzieren sollen.
* Aber auch echte Kunstwerke lassen sich ausmachen, so zum Beispiel eine Lobeshymne auf das [[ARPANET]] (<nowiki>RFC 527</nowiki><ref>{{RFC-Internet |RFC=527 |Titel=ARPAWOCKY |Datum=1973-06-22}}</ref>), Wissenschaftsgeschichte in Versform (<nowiki>RFC 1121</nowiki><ref>{{RFC-Internet |RFC=1121 |Titel=Act One – The Poems |Datum=1989-09}}</ref>) oder ''[[The Twelve Days of Christmas]]'' aus der Sicht eines gestressten Netzwerk-[[Administrator (Rolle)|Admins]] (<nowiki>RFC 1882</nowiki><ref>{{RFC-Internet |RFC=1882 |Titel=The 12-Days of Technology Before Christmas |Datum=1995-12}}</ref>).
* Am 1. April 2001 wurden im <nowiki>RFC 3092</nowiki><ref>{{RFC-Internet |RFC=3092 |Titel=Etymology of “Foo” |Datum=2001-04-01}}</ref> die Kombinationen von [[Metasyntaktische Variable|„foo“ und „bar“ bzw. deren Abarten]] [[Etymologie|etymologisch]] bestimmt.
* Am 1. April 2003 wurde ein RFC (<nowiki>RFC 3514</nowiki><ref>{{RFC-Internet |RFC=3514 |Titel=The Security Flag in the IPv4 Header |Datum=2003-04-01}}</ref>) veröffentlicht, das dazu aufruft, bei [[Internet Protocol|IP-Paketen]], die in irgendeiner Form „evil“ (böse) sind, ein entsprechendes Bit im Header zu setzen, um diese Pakete an [[Firewall]]s leichter ausfiltern zu können. Dies rührt daher, dass in IPv4-Headern ein Bit, das den „Type of Service“ angibt, normalerweise mit 0 gesetzt ist, von einigen modernen Anwendungen jedoch mit 1 gesetzt wird. Einige Firewalls verlassen sich darauf, dass dieses 0 ist, und stufen das Paket eben als böse ein, da es einen nicht-unterstützten Service-Typ darstellt.
* Am 1. April 2004 wurde ein Allwissenheitsprotokoll entwickelt, das es der amerikanischen Regierung ermöglichen sollte, alle Formen der Computerkriminalität zu erkennen und zu verhindern (<nowiki>RFC 3751</nowiki><ref>{{RFC-Internet |RFC=3751 |Titel=Omniscience Protocol Requirements |Datum=2004-04-01 |Autor=Scott Bradner}}</ref>). Nachdem sich die Anforderungen an dieses Protokoll als nicht durchführbar erwiesen hatten, endet der Text mit den Worten: „Good luck.“
* Am 1. April 2005 wurde ein neuer Standard vorgestellt, welcher [[moral]]isch einwandfreies [[Routing]] ermöglicht (<nowiki>RFC 4041</nowiki><ref>{{RFC-Internet |RFC=4041 |Titel=Requirements for Morality Sections in Routing Area Drafts |Datum=2005-04-01}}</ref>). Des Weiteren wurde das schon sehr in die Jahre gekommene [[UTF-8]], das [[8-Bit-Architektur|8 Bit breite Einheiten]] verwendet, durch UTF-9 ersetzt, das 9 [[Bit]]s (3 × 3) pro [[Byte]] erlaubt (<nowiki>RFC 4042</nowiki><ref>{{RFC-Internet |RFC=4042 |Titel=UTF-9 and UTF-18 Efficient Transformation Formats of Unicode |Datum=2005-04-01}}</ref>).
* Am 1. April 2007 wurde eine Methode für die Übertragung von IP über das [[Winkeralphabet]] vorgestellt (<nowiki>RFC 4824</nowiki><ref>{{RFC-Internet |RFC=4824 |Titel=The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) |Datum=2007-04-01}}</ref>).
* Am 1. April 2010 wurde das [[Transmission Control Protocol]] erweitert: Die Laune des übertragenen Segments kann durch [[Emoticon]]s im [[Header]] festgelegt werden. So kann ein Segment beispielsweise fröhlich oder frustriert sein (<nowiki>RFC 5841</nowiki><ref>{{RFC-Internet |RFC=5841 |Titel=TCP Option to Denote Packet Mood |Datum=2010-04-01}}</ref>).

=== Realisierte Aprilscherze ===
Nicht immer jedoch bleibt es bei RFC zum 1. April bei der Theorie.
So wurde am 6. März 2001 eine Implementierung des <nowiki>RFC 1149</nowiki> ''A Standard for the [[Internet Protocol over Avian Carriers|Transmission of IP Datagrams on Avian Carriers]]'' (die Übertragung von IP-Datagrammen per [[Brieftaube]])<ref>{{RFC-Internet |RFC=1149 |Titel=A Standard for the Transmission of IP Datagrams on Avian Carriers |Datum=2001-03-06}}</ref> vorgestellt. Die durchschnittliche [[Antwortzeit]] eines [[Ping (Datenübertragung)|Pings]] betrug jedoch 45 Minuten, sodass nicht mit einer regelmäßigen Nutzung im Echteinsatz zu rechnen sein wird. Allerdings führte dies zu einer Weiterentwicklung <nowiki>RFC 2549</nowiki> ''IP over Avian Carriers with [[Quality of Service]]'',<ref>{{RFC-Internet |RFC=2549 |Titel=IP over Avian Carriers with Quality of Service }}</ref> aber auch dieser Einsatz ist unwahrscheinlich.

Der Editor [[Emacs]] enthält schon seit Jahren eine vollständige Implementierung von <nowiki>RFC 2324</nowiki>:<ref>{{RFC-Internet |RFC=2324 |Titel=Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) |Datum=1998-04-01}}</ref> ''Das [[Hyper Text Coffee Pot Control Protocol]] (HTCPCP)'' dient der Fernsteuerung und -überwachung von Kaffeemaschinen. Am 1. April 2014 wurde das Protokoll mit dem <nowiki>RFC 7168</nowiki><ref>{{RFC-Internet |RFC=7168 |Titel=The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) |Datum=2014-04-01}}</ref> um die Nutzung von Tee erweitert.

Auch für das [[Pi Digit Generation Protocol]] gibt es mit ''gpigen'' eine freie Implementierung für mehrere Plattformen.

== Weblinks ==
* [https://www.rfc-editor.org/ Offizielle Website des RFC-Editors] mit Index aller RFCs (englisch)
* {{RFC-Internet |RFC=8700 |Titel=Fifty Years of RFCs |Datum=2019-12 |Autor=H. Flanagan}}
* [http://www.faqs.org/ Internet FAQ Archives] (englisch)
* [https://requestforcomments.de/ Podcast über RFCs]

== Einzelnachweise ==
<references>
<ref name="RFC1796">
{{RFC-Internet |RFC=1796 |Titel=Not All RFCs are Standards |Datum=1995-04 |Autor=C. Huitema, J. Postel, S. Crocker}}
</ref>
<ref name="RFC6360">
{{RFC-Internet |RFC=6360 |Titel=Conclusion of FYI RFC Sub-Series |Datum=2011-08 |Autor=R. Housley}}
</ref>
<ref name="RFC6410">
{{RFC-Internet |RFC=6410 |Titel=Reducing the Standards Track to Two Maturity Levels |Datum=2011-10 |Autor=R. Housley, D. Crocker, E. Burger}}
</ref>
<ref name="RFC8700">
{{RFC-Internet |RFC=8700 |Titel=Fifty Years of RFCs |Datum=2019-12 |Autor=H. Flanagan}}
</ref>
</references>

{{Normdaten|TYP=w|GND=4813216-0}}

[[Kategorie:Request for Comments| ]]
[[Kategorie:Geschichte des Internets]]

Request for Comments - Versionsgeschichte

imported>Trustable: linkfix