Requests For Comments: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
K Textersetzung - „Man-Pages“ durch „Man-Page“
 
(103 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' kurze Beschreibung
'''Requests For Comment'''s (RFC)s - Technische und organisatorische Dokumente zum Internet


= Beschreibung =
== Beschreibung ==
= Installation =
; Bitte um Kommentare
= Syntax =
* Technischer und organisatorische Dokumente zum [[Internet]]
== Parameter ==
* Seit 1969 vom [[RFC-Editor]] herausgegeben
== Optionen ==
== Umgebungsvariablen ==
== Exit-Status ==


= Konfiguration =
;Diskussion
== Dateien ==
* Heute findet die Diskussion während der Erstellung der Entwürfe statt


= Anwendungen =
;Internetstandards
= Sicherheit =
* Viele veröffentlichte RFCs sind begutachtete technische Spezifikationen
= Dokumentation =
* Einige RFCs sind [[Internetstandard]]s und standardisieren die [[Internetprotokolle]]
== RFC ==
== Man-Pages ==
== Info-Pages ==
== Siehe auch ==


= Links =
; Technische Grundlagen von Internetanwendungen
== Projekt-Homepage ==
* [[E-Mail]]
== Weblinks ==
* [[World Wide Web]]
== Einzelnachweise ==
* [[Internet Protocol|IP]]
<references />
* [[Transmission Control Protocol|TCP]]
 
* [[User Datagram Protocol|UDP]]
= Testfragen =
* [[Simple Mail Transfer Protocol|SMTP]]
<div class="toccolours mw-collapsible mw-collapsed">
* [[Hypertext Transfer Protocol|HTTP/2]]
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>
 
[[Kategorie:RFC]]
 
= TMP =
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öffentlichtes 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 [[Internet Protocol|IPv6]] (RFC 8200), [[Transmission Control Protocol|TCP]] (RFC 793), [[User Datagram Protocol|UDP]] (RFC 768), [[Simple Mail Transfer Protocol|SMTP]] (RFC 5321) und [[Hypertext Transfer Protocol|HTTP/2]] (RFC 7540), und bilden damit die technische Grundlage von Internetanwendungen wie [[E-Mail]] oder dem [[World Wide Web]].


== Publikationsverfahren ==
== Publikationsverfahren ==
===  Begutachtung ===
; Begutachtung vor der Veröffentlichung
* 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.
* 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.


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.
=== Neue RFCs ===
 
*  gibt der [[RFC-Editor]] mit einer fortlaufenden Nummerierung als ASCII-[[Textdatei]] sowie in weiteren Dokumentenformaten heraus.  
{{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.
* 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.  
Neue RFCs gibt der [[RFC-Editor]] mit einer fortlaufenden Nummerierung als 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.
* 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 ===
=== Dokumentenreihen ===
Ausgewählte RFCs werden zugleich in weiteren Dokumentenreihen mit jeweils eigenen Nummerierungen veröffentlicht.
Ausgewählte RFCs werden zugleich in weiteren Dokumentenreihen mit jeweils eigenen Nummerierungen veröffentlicht.


* Internet Standard (STD)
{| class="wikitable sortable"
:Internetstandards mit dem höchsten Reifegrad werden zusätzlich in der Dokumentenreihe STD veröffentlicht.
|-
* [[Best Current Practice]] (BCP)
! Dokumentenreihe !! Kürzel !! Beschreibung
: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)
| Internet Standard || STD || Internetstandards mit dem höchsten Reifegrad werden zusätzlich in der Dokumentenreihe STD veröffentlicht
: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" />
|-
| [[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.
|-
| 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.  
* Die Reihe wurde 2011 eingestellt.
|}


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


=== Genehmigungsverfahren ===
=== Genehmigungsverfahren ===
Es gibt unterschiedliche Genehmigungsverfahren (''streams'') für RFCs, je nachdem, woher das Dokument stammt


Es gibt unterschiedliche Genehmigungsverfahren für RFCs, je nachdem woher das Dokument stammt. Ein solches Verfahren wird als ''Stream'' bezeichnet. RFC 4844 definiert die folgenden Streams:
; RFC 4844 definiert die folgenden Streams
 
* 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. RFC 2026 und weitere beschreiben das Verfahren.
* IAB
:Das Dokument stammt vom [[Internet Architecture Board]]. RFC 4845 beschreibt das Verfahren.
* IRTF
:Das Dokument stammt von der [[Internet Research Task Force]]. RFC 5743 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. RFC 4846 beschreibt das Verfahren.


== RFC-Status ==
{| class="wikitable sortable"
Jedes RFC besitzt einen Dokumentenstatus, der im Gegensatz zum Inhalt nachträglich verändert werden kann.
|-
! Stream !! Beschrieben in  !! Beschreibung
|-
| IETF || RFC 2026, ... || 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.
|-
| IAB || RFC 4845 || Das Dokument stammt vom [[Internet Architecture Board]].
|-
| IRTF || REC 5743 || Das Dokument stammt von der [[Internet Research Task Force]].
|-
| Independent Submission || RFC 4846 || 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.
|}


* ''Unknown'' (unbekannt)
== Status ==
:Dem RFC ist kein Status zugeordnet. Dies trifft auf einige frühe RFCs zu.
Jeder RFC besitzt einen Dokumentenstatus, der im Gegensatz zum Inhalt nachträglich verändert werden kann.
* ''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 RFC 4408 und kam mit RFC 7208 ins 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 ==
{| class="wikitable sortable"
 
|-
Die IETF und der RFC-Editor legen einen hohen Wert auf Formalismus:
! Status !! Beschreibung
|-
| Unknown || Dem RFC ist kein Status zugeordnet. Dies trifft auf einige frühe RFCs zu.
|-
| Draft || Kein RFC, da noch im Entwurfsstadium.
|-
| Informational || Informatives Dokument (Terminologie-Erklärungen, Nutzungshinweise, Problemstellungen, neue Ideen, Antworten auf allgemeine Fragen oder Nachrufe.
|-
|- Experimental || 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 RFC 4408 und kam mit RFC 7208 ins Standardisierungsverfahren.
|-
| Best Current Practice || Technisches Dokument, das durch Veröffentlichung in der Dokumentenreihe BCP einen verbindlichen Charakter erhält.
|}


== Anforderungen ==
* Vorschläge für neue oder geänderte RFCs werden in allen Änderungen vor der formellen Veröffentlichung nachvollziehbar dokumentiert.
* 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.
* Ein einmal abschließend veröffentlichter RFC ist für immer öffentlich und fest.  
* Er kann nicht korrigiert, sondern nur durch neuere RFCs abgelöst werden.
* Die Struktur und der Stil eines RFCs sind durch RFC 7322 vorgegeben.
* Die Struktur und der Stil eines RFCs sind durch RFC 7322 vorgegeben.
* RFC 2119 (BCP 14) legt die Terminologie von Anforderungen fest, die in ihrer Bedeutung klar definiert sind, um Missverständnisse in deren Interpretation zu vermeiden.
* RFC 2119 (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.
Dies sorgt für die Vermeidung von Missverständnissen in der Interpretation und Implementierung und somit für den Erfolg beim Betrieb des Internets.  
:''SHOULD'' und ''SHOULD NOT'' (äquivalent: ''RECOMMENDED'' und ''NOT RECOMMENDED'') geben an, dass eine Anforderungen empfohlen ist, aber in begründeten Fällen davon abgewichen werden kann.
* RFC 2822 (E-Mail)
:''MAY'' (äquivalent: ''OPTIONAL'') gibt eine Option an, die im eigenen Ermessen des Herstellers umgesetzt werden kann.
* RFC 2616 (HTTP)
* 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 RFC 2822 (E-Mail) sowie RFC 2616 (HTTP) genannt.
=== Modalverben===
{{:Modalverben}}


== Humor in RFC ==
<noinclude>


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]].
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Sicherheit ====
==== Dokumentation ====
===== RFC =====
===== Man-Page =====
===== Info-Pages =====
==== Links ====
===== Projekt =====
# https://www.rfc-editor.org/
# https://www.rfc-editor.org/rfc-index.html


* Das am 1. April 1996 veröffentlichte RFC 1925 listet ''The Twelve Networking Truths'' auf, die mit dem fundamentalen Grundsatz ''It Has To Work'' beginnen.
===== Weblinks =====
* Als Parodie auf das Routing-Protokoll [[Multiprotocol Label Switching|MPLS]] findet sich in RFC 3251 das ''Mostly Pointless Lamp Switching''.
# https://de.wikipedia.org/wiki/Request_for_Comments
* RFC 2795 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.
# https://packetlife.net/blog/2008/dec/1/requests-comments/
* Aber auch echte Kunstwerke lassen sich ausmachen, so zum Beispiel eine Lobeshymne auf das [[Arpanet]] (RFC 527), Wissenschaftsgeschichte in Versform (RFC 1121) oder ''[[The Twelve Days of Christmas]]'' aus der Sicht eines gestressten Netzwerk-[[Administrator (Rolle)|Admins]] (RFC 1882).
* Am 1. April 2001 wurden im RFC 3092 die Kombinationen von [[Metasyntaktische Variable|„foo“ und „bar“ bzw. deren Abarten]] [[Etymologie|etymologisch]] bestimmt.
* Am 1. April 2003 wurde ein RFC (RFC 3514) 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 (RFC 3751). 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 (RFC 4041). 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&nbsp;×&nbsp;3) pro [[Byte]] erlaubt (RFC 4042).
* Am 1. April 2007 wurde eine Methode für die Übertragung von IP über das [[Winkeralphabet]] vorgestellt (RFC 4824).
* 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 (RFC 5841).


=== Realisierte Aprilscherze ===
= TMP =
; Wenn man über Netzwerkprotokolle liest, stößt man unweigerlich auf Verweise auf verschiedene RFCs.
* Leider nehmen sich nicht viele Leute die Zeit, diesen Verweisen nachzugehen
* was bedauerlich ist, denn sich mit einem RFC vertraut zu machen, kann beim Entwurf eines komplexen Netzwerks oder bei der Fehlersuche in besonders obskuren Situationen von großem Vorteil sein.


Nicht immer jedoch bleibt es bei RFC zum 1. April bei der Theorie.
; Ein RFC, oder Request For Comment, ist ein Memorandum
So wurde am 6. März 2001 eine Implementierung des RFC 1149 ''A Standard for the [[Internet Protocol over Avian Carriers|Transmission of IP Datagrams on Avian Carriers]]'' (die Übertragung von IP-Datagrammen per [[Brieftaube]]) vorgestellt. Die durchschnittliche [[Antwortzeit]] eines [[Ping (Datenübertragung)|Pings]] betrug jedoch 45 Minuten, so dass nicht mit einer regelmäßigen Nutzung im Echteinsatz zu rechnen sein wird. Allerdings führte dies zu einer Weiterentwicklung RFC 2549 ''IP over Avian Carriers with [[Quality of Service]]'', aber auch dieser Einsatz ist unwahrscheinlich.
* das von einem oder mehreren Netzwerkingenieuren verfasst und von der Internet Engineering Task Force (IETF) veröffentlicht wird, um neue Standards vorzuschlagen oder neue Ideen zu vermitteln.
* Der Begriff "Request for Comment" ist vielleicht etwas irreführend, da viele RFCs de facto als Internet-Gesetze gelten, aber der Begriff geht auf die ursprüngliche Funktion jedes Dokuments als Aufforderung zur Überprüfung durch Fachkollegen zurück.


Der Editor [[Emacs]] enthält schon seit Jahren eine vollständige Implementierung von RFC 2324: Das [[Hyper Text Coffee Pot Control Protocol]] (HTCPCP) dient der Fernsteuerung und -überwachung von Kaffeemaschinen.
; Es gibt vier Kategorien von RFCs
* '''Standard (STD), Draft Standard, oder Proposed Standard''' - offizielle Protokollspezifikationen
* '''Best Current Practice (BCP)''' - Offizielle Richtlinien und Empfehlungen
* '''Informativ (FYI) oder experimentell'''
* '''Historisch'''


Auf der Veranstaltung [[What The Hack|Hacking in Progress]] wurde RFC 2322, ''Management of IP numbers by [[Peg DHCP]]'', formuliert. Es definiert, wie IP-Nummern mit einem Filzstift auf Holzwäscheklammern geschrieben und diese an das zugehörige Kabel geklammert werden. Obwohl dieser RFC als Scherz gedacht war, wird das Verfahren regelmäßig eingesetzt.
; Ein RFC beginnt den Veröffentlichungsprozess als Internet-Entwurf, der einen Zyklus der Bearbeitung und Überprüfung durchläuft.
* Jeder kann einen informativen oder experimentellen Internet-Entwurf zur Überprüfung einreichen, aber Standard-Track- und BCP-Einsendungen müssen von einer IETF-Arbeitsgruppe stammen.
* Ein langwieriger Überprüfungsprozess ist notwendig, da RFCs nach ihrer Veröffentlichung nie mehr geändert werden; geringfügige Fehler werden als separate Errata aufgeführt, während erhebliche Überarbeitungen die Einreichung eines neuen Entwurfs erfordern.


Auch für das [[Pi Digit Generation Protocol]] gibt es mit ''gpigen'' eine freie Implementierung für mehrere Plattformen.
; Jedem RFC wird vom RFC-Editor eine fortlaufende Nummer zugewiesen
* und zwar in loser chronologischer Reihenfolge (aufgrund der unterschiedlichen Dauer der einzelnen Überprüfungen erscheinen die RFCs normalerweise nicht in perfekter Reihenfolge).
* Der gesamte Überprüfungsprozess selbst ist ausführlich in RFC 2026 beschrieben.


== Weblinks ==
; Veröffentlichte RFCs können an verschiedenen Stellen gefunden werden
* [https://www.rfc-editor.org/ Offizielle Website des RFC-Editors] mit Index aller RFCs (englisch)
* aber mein Favorit ist die Website der IETF-Tools.
* [https://tools.ietf.org/html/rfc8700 Fifty Years of RFCs] (englisch)
* [http://www.faqs.org/ Internet FAQ Archives] (englisch)
* [https://requestforcomments.de/ Podcast über RFCs]


== Einzelnachweise ==
; Hier ist jeder RFC mit einem Meta-Header (der Abschnitt mit dem grauen Hintergrund) formatiert, der hilfreiche Zusatzinformationen enthält:
<references>
[[File:RFC_header.png|mini|400px]]
<ref name="rfc1796">{{cite web
# Farbbalken zeigt Status an
|url = https://tools.ietf.org/html/rfc1796
# Ursprünglicher Interne; Zeichenketten
|title = RFC 1796 – Not All RFCs are Standards
Für eine eindeutige Interpretation werden Zeichenketten und ihre Zusammensetzung formalistisch mit der [https://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form] (BNF) dargestellt. Hilfreich zum Beispiel beim Aufbau von URLs und URIs.t-Entwurf
|author = C. Huitema, J. Postel, S. Crocker
# Aktualisierungen zu diesem RFC seit seiner Veröffentlichung
|publisher = IETF
# IETF-Arbeitsgruppe
|date = April 1995
# Seriennummer
|accessdate = 2019-12-26
# Frühere RFCs, die durch diesen Entwurf veraltet und/oder aktualisiert wurden
}}</ref>
# Status
<ref name="rfc6360">{{cite web
# Errata-Liste
|url = https://tools.ietf.org/html/rfc6360
# Autor(en)
|title = RFC 6360 – Conclusion of FYI RFC Sub-Series
# Datum
|author = R. Housley
# Titel
|publisher = IETF
 
|date = August 2011
; Die meisten modernen RFCs beginnen mit einer Statuserklärung
|accessdate = 2019-12-26
* einer abstrakten Erklärung des Zwecks und einem Inhaltsverzeichnis.
}}</ref>
* Das Inhaltsverzeichnis gliedert den Inhalt des RFC wie bei einem Buch nach Abschnitten und Seiten, so dass Sie leicht zu einem bestimmten Thema navigieren können, wenn Sie nach bestimmten Details suchen.
<ref name="rfc6410">{{cite web
* Viele RFCs enthalten zusätzliche Referenzen und einen oder mehrere Anhänge am Ende.
|url = https://tools.ietf.org/html/rfc6410
 
|title = RFC 6410 – Reducing the Standards Track to Two Maturity Levels
; Viele Leute werden die Seiten mit schwarzem und weißem Text abschreckend finden
|author = R. Housley, D. Crocker, E. Burger
* aber das Lesen eines RFCs von Anfang bis Ende ist nicht so trocken, wie Sie vielleicht denken.
|publisher = IETF
* RFCs werden von Ingenieuren für Ingenieure geschrieben und sind in der Regel sehr effizient formuliert.
|date = Oktober 2011
* Denken Sie außerdem daran, dass RFCs in einem Text mit fester Breite formatiert sind; jede Seite ist deutlich weniger dicht als ein durchschnittliches Buch und lässt sich daher viel schneller lesen.
|accessdate = 2019-12-26
 
}}</ref>
; Zeichenketten
<ref name="rfc8700">{{cite web
Für eine eindeutige Interpretation werden Zeichenketten und ihre Zusammensetzung formalistisch mit der [https://de.wikipedia.org/wiki/Backus-Naur-Form Backus-Naur-Form] (BNF) dargestellt. Hilfreich zum Beispiel beim Aufbau von URLs und URIs.
|url = https://tools.ietf.org/html/rfc8700
 
|title = RFC 8700 – Fifty Years of RFCs
[[File:rfcEditor.png|400px]]
|author = H. Flanagan (Hrsg.)
[[File:rfc9293.png|400px]]
|publisher = IETF
[[File:3-s2.0-B9780128110270000011-f01-05-9780128110270.jpg|400px]]
|date = Dezember 2019
[[File:slide_7.jpg|400px]]
|accessdate = 2019-12-26
[[File:Maturity-Levels-of-RFCs.jpg|400px]]
}}</ref>
[[File:16fig03.gif|400px]]
</references>
[[File:stallingscol1_fig1.gif|400px]]
[[File:99CA4D445C8118881E.jpeg|400px]]
[[File:rfc.gif|400px]]
[[File:standards_process.gif|400px]]
 
[[Kategorie:RFC]]


[[Kategorie:Request for Comments| ]]
</noinclude>
[[Kategorie:Geschichte des Internets]]

Aktuelle Version vom 6. November 2024, 12:48 Uhr

Requests For Comments (RFC)s - Technische und organisatorische Dokumente zum Internet

Beschreibung

Bitte um Kommentare
  • Technischer und organisatorische Dokumente zum Internet
  • Seit 1969 vom RFC-Editor herausgegeben
Diskussion
  • Heute findet die Diskussion während der Erstellung der Entwürfe statt
Internetstandards
Technische Grundlagen von Internetanwendungen

Publikationsverfahren

Begutachtung

Begutachtung vor der Veröffentlichung
  • 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.
  • 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 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 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.

Dokumentenreihe Kürzel Beschreibung
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 Netzwerkprotokolle handelt.
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.
  • Die Reihe wurde 2011 eingestellt.

Einzelne RARE Technical Reports (RTR) wurden auch als RFC veröffentlicht.

Genehmigungsverfahren

Es gibt unterschiedliche Genehmigungsverfahren (streams) für RFCs, je nachdem, woher das Dokument stammt

RFC 4844 definiert die folgenden Streams
Stream Beschrieben in Beschreibung
IETF RFC 2026, ... Das Dokument stammt entweder von einer Arbeitsgruppe der IETF oder von einem Bereichsleiter (Area Director) der Internet Engineering Steering Group.
IAB RFC 4845 Das Dokument stammt vom Internet Architecture Board.
IRTF REC 5743 Das Dokument stammt von der Internet Research Task Force.
Independent Submission RFC 4846 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.

Status

Jeder RFC besitzt einen Dokumentenstatus, der im Gegensatz zum Inhalt nachträglich verändert werden kann.

  • 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 RFC 4408 und kam mit RFC 7208 ins Standardisierungsverfahren.
Status Beschreibung
Unknown Dem RFC ist kein Status zugeordnet. Dies trifft auf einige frühe RFCs zu.
Draft Kein RFC, da noch im Entwurfsstadium.
Informational Informatives Dokument (Terminologie-Erklärungen, Nutzungshinweise, Problemstellungen, neue Ideen, Antworten auf allgemeine Fragen oder Nachrufe.
Best Current Practice Technisches Dokument, das durch Veröffentlichung in der Dokumentenreihe BCP einen verbindlichen Charakter erhält.

Anforderungen

  • 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 nicht korrigiert, sondern nur durch neuere RFCs abgelöst werden.
  • Die Struktur und der Stil eines RFCs sind durch RFC 7322 vorgegeben.
  • RFC 2119 (BCP 14) legt die Terminologie von Anforderungen fest, die in ihrer Bedeutung klar definiert sind, um Missverständnisse in deren Interpretation zu vermeiden.

Dies sorgt für die Vermeidung von Missverständnissen in der Interpretation und Implementierung und somit für den Erfolg beim Betrieb des Internets.

  • RFC 2822 (E-Mail)
  • RFC 2616 (HTTP)

Modalverben

Modalverben - beschreiben die Verbindlichkeit einer Anforderung

Beschreibung
MUSS und SOLL
Ausdruck Verbindlichkeit
MUSS, DARF NUR Anforderung muss unbedingt erfüllt werden
DARF NICHT, DARF KEIN Darf in keinem Fall getan werden
SOLLTE Anforderung ist normalerweise zu erfüllt (MUSS, wenn kann). Abweichung in stichhaltig begründeten Fällen möglich.
SOLLTE NICHT, SOLLTE KEIN Dieser Ausdruck bedeutet, dass etwas normalerweise nicht getan werden darf, bei stichhaltigen Gründen aber trotzdem erfolgen kann.
Ausdruck Verbindlichkeit
MUST, MUST NOT, SHALL, SHALL NOT Anforderung muss zwingend eingehalten werden
SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED Empfohlene Anforderung, Abweichung in Begründeten Einelfällen möglich.
MAY, OPTIONAL Anforderung liegt im Ermessen des Herstellers



Anhang

Siehe auch

Sicherheit

Dokumentation

RFC
Man-Page
Info-Pages

Links

Projekt
  1. https://www.rfc-editor.org/
  2. https://www.rfc-editor.org/rfc-index.html
Weblinks
  1. https://de.wikipedia.org/wiki/Request_for_Comments
  2. https://packetlife.net/blog/2008/dec/1/requests-comments/

TMP

Wenn man über Netzwerkprotokolle liest, stößt man unweigerlich auf Verweise auf verschiedene RFCs.
  • Leider nehmen sich nicht viele Leute die Zeit, diesen Verweisen nachzugehen
  • was bedauerlich ist, denn sich mit einem RFC vertraut zu machen, kann beim Entwurf eines komplexen Netzwerks oder bei der Fehlersuche in besonders obskuren Situationen von großem Vorteil sein.
Ein RFC, oder Request For Comment, ist ein Memorandum
  • das von einem oder mehreren Netzwerkingenieuren verfasst und von der Internet Engineering Task Force (IETF) veröffentlicht wird, um neue Standards vorzuschlagen oder neue Ideen zu vermitteln.
  • Der Begriff "Request for Comment" ist vielleicht etwas irreführend, da viele RFCs de facto als Internet-Gesetze gelten, aber der Begriff geht auf die ursprüngliche Funktion jedes Dokuments als Aufforderung zur Überprüfung durch Fachkollegen zurück.
Es gibt vier Kategorien von RFCs
  • Standard (STD), Draft Standard, oder Proposed Standard - offizielle Protokollspezifikationen
  • Best Current Practice (BCP) - Offizielle Richtlinien und Empfehlungen
  • Informativ (FYI) oder experimentell
  • Historisch
Ein RFC beginnt den Veröffentlichungsprozess als Internet-Entwurf, der einen Zyklus der Bearbeitung und Überprüfung durchläuft.
  • Jeder kann einen informativen oder experimentellen Internet-Entwurf zur Überprüfung einreichen, aber Standard-Track- und BCP-Einsendungen müssen von einer IETF-Arbeitsgruppe stammen.
  • Ein langwieriger Überprüfungsprozess ist notwendig, da RFCs nach ihrer Veröffentlichung nie mehr geändert werden; geringfügige Fehler werden als separate Errata aufgeführt, während erhebliche Überarbeitungen die Einreichung eines neuen Entwurfs erfordern.
Jedem RFC wird vom RFC-Editor eine fortlaufende Nummer zugewiesen
  • und zwar in loser chronologischer Reihenfolge (aufgrund der unterschiedlichen Dauer der einzelnen Überprüfungen erscheinen die RFCs normalerweise nicht in perfekter Reihenfolge).
  • Der gesamte Überprüfungsprozess selbst ist ausführlich in RFC 2026 beschrieben.
Veröffentlichte RFCs können an verschiedenen Stellen gefunden werden
  • aber mein Favorit ist die Website der IETF-Tools.
Hier ist jeder RFC mit einem Meta-Header (der Abschnitt mit dem grauen Hintergrund) formatiert, der hilfreiche Zusatzinformationen enthält
  1. Farbbalken zeigt Status an
  2. Ursprünglicher Interne; Zeichenketten

Für eine eindeutige Interpretation werden Zeichenketten und ihre Zusammensetzung formalistisch mit der Backus-Naur-Form (BNF) dargestellt. Hilfreich zum Beispiel beim Aufbau von URLs und URIs.t-Entwurf

  1. Aktualisierungen zu diesem RFC seit seiner Veröffentlichung
  2. IETF-Arbeitsgruppe
  3. Seriennummer
  4. Frühere RFCs, die durch diesen Entwurf veraltet und/oder aktualisiert wurden
  5. Status
  6. Errata-Liste
  7. Autor(en)
  8. Datum
  9. Titel
Die meisten modernen RFCs beginnen mit einer Statuserklärung
  • einer abstrakten Erklärung des Zwecks und einem Inhaltsverzeichnis.
  • Das Inhaltsverzeichnis gliedert den Inhalt des RFC wie bei einem Buch nach Abschnitten und Seiten, so dass Sie leicht zu einem bestimmten Thema navigieren können, wenn Sie nach bestimmten Details suchen.
  • Viele RFCs enthalten zusätzliche Referenzen und einen oder mehrere Anhänge am Ende.
Viele Leute werden die Seiten mit schwarzem und weißem Text abschreckend finden
  • aber das Lesen eines RFCs von Anfang bis Ende ist nicht so trocken, wie Sie vielleicht denken.
  • RFCs werden von Ingenieuren für Ingenieure geschrieben und sind in der Regel sehr effizient formuliert.
  • Denken Sie außerdem daran, dass RFCs in einem Text mit fester Breite formatiert sind; jede Seite ist deutlich weniger dicht als ein durchschnittliches Buch und lässt sich daher viel schneller lesen.
Zeichenketten

Für eine eindeutige Interpretation werden Zeichenketten und ihre Zusammensetzung formalistisch mit der Backus-Naur-Form (BNF) dargestellt. Hilfreich zum Beispiel beim Aufbau von URLs und URIs.


Abgerufen von „https://wiki.foxtom.de/index.php?title=Requests_For_Comments&oldid=114485“