Requests For Comments

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

• Viele veröffentlichte RFCs sind begutachtete technische Spezifikationen
• Einige RFCs sind Internetstandards und standardisieren die Internetprotokolle

Technische Grundlagen von Internetanwendungen

• E-Mail
• World Wide Web
• IP
• TCP
• UDP
• SMTP
• HTTP/2

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. Dieser Stream ist der einzige, der werdende Internetstandards und Best Current Practices 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.

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

• Requests For Comments

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.