Requests For Comments

topic kurze Beschreibung

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

TMP

Die Requests for Comments (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.
• Einige RFCs, jedoch nicht alle, stellen Internetstandards dar.
• RFCs standardisieren die Internetprotokollfamilie, beispielsweise IPv6 (RFC 8200), TCP (RFC 793), UDP (RFC 768), SMTP (RFC 5321) und HTTP/2 (RFC 7540), und bilden damit die technische Grundlage von Internetanwendungen wie E-Mail oder dem World Wide Web.

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.
• 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.

• 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 für RFCs, je nachdem woher das Dokument stammt.

• Ein solches Verfahren wird als Stream bezeichnet.
• 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 Internetstandards und Best Current Practices 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

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 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 Internetstandards. 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. 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 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.

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 Anforderungen 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 RFC 2822 (E-Mail) sowie RFC 2616 (HTTP) genannt.

Weblinks

• Offizielle Website des RFC-Editors mit Index aller RFCs (englisch)
• Fifty Years of RFCs (englisch)
• Internet FAQ Archives (englisch)
• Podcast über RFCs