Requests For Comments: Unterschied zwischen den Versionen
Zeile 80: | Zeile 80: | ||
! Status !! Beschreibung | ! Status !! Beschreibung | ||
|- | |- | ||
| Unknown ||Dem RFC ist kein Status zugeordnet. | | Unknown || Dem RFC ist kein Status zugeordnet. Dies trifft auf einige frühe RFCs zu. | ||
|- | |- | ||
| Draft || Kein RFC, da noch im Entwurfsstadium. | | Draft || Kein RFC, da noch im Entwurfsstadium. | ||
|- | |- | ||
| Informational || Informatives Dokument jeglicher Art, | | Informational || Informatives Dokument jeglicher Art, etwa Terminologie-Erklärungen, Nutzungshinweise, Problemstellungen oder neue Ideen. Vereinzelt kommen auch Antworten auf allgemeine Fragen oder Nachrufe vor. | ||
|- | |- | ||
|- Experimental || Protokollspezifikation, die als Teil eines Forschungs- oder Entwicklungsvorhaben entstand. | |- Experimental || Protokollspezifikation, die als Teil eines Forschungs- oder Entwicklungsvorhaben entstand. | ||
Zeile 92: | Zeile 90: | ||
* Beispielsweise begann das [[Sender Policy Framework]] als experimentelles RFC 4408 und kam mit RFC 7208 ins Standardisierungsverfahren. | * Beispielsweise begann das [[Sender Policy Framework]] als experimentelles RFC 4408 und kam mit RFC 7208 ins Standardisierungsverfahren. | ||
|- | |- | ||
| Best Current Practice || | | Best Current Practice || Technisches Dokument, das durch Veröffentlichung in der Dokumentenreihe BCP einen verbindlichen Charakter erhält. | ||
|} | |} | ||
Version vom 7. Oktober 2022, 19:41 Uhr
RFCs - Requests For Comments - (Bitte um Kommentare) sind eine Reihe technischer und organisatorischer Dokumente zum Internet
Beschreibung
- Seit 1969 vom RFC-Editor herausgegeben
- Heute findet die Diskussion während der Erstellung der Entwürfe statt
- Viele veröffentlichte RFCs sind begutachtete technische Spezifikationen
- Einige RFCs sind Internetstandards
- Standardisieren die Internetprotokollfamilie
- Beschreiben die technische Grundlage von Internetanwendungen, wie
Publikationsverfahren
Begutachtung
- Begutachtung von RFCs 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.
|
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.
|
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.
|
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 jeglicher Art, etwa Terminologie-Erklärungen, Nutzungshinweise, Problemstellungen oder neue Ideen. Vereinzelt kommen auch Antworten auf allgemeine Fragen oder Nachrufe vor. |
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
- MUST, MUST NOT und SHALL, SHALL NOT
Anforderung muss zwingend eingehalten werden
- SHOULD, SHOULD NOT und RECOMMENDED, NOT RECOMMENDED
Eine empfohlene Anforderung, es kann aber in begründeten Fällen davon abgewichen werden
- MAY und OPTIONAL
Anforderung liegt im Ermessen des Herstellers
- 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.
Links
Projekt-Homepage
- Offizielle Website des RFC-Editors mit Index aller RFCs (englisch)
Weblinks
Einzelnachweise
Testfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5