In der Computernetztechnik ist eine Bitte Um Anmerkungen (RFC) ein Vermerk, der durch die Beschreiben-Methoden von Internet Engineering Task Force (IETF), Handlungsweisen, Forschung oder Neuerungen veröffentlicht ist, die auf das Arbeiten des Internets und der internetverbundenen Systeme anwendbar sind.

Durch die Internetgesellschaft können Ingenieure und Computerwissenschaftler Gespräch in der Form eines RFC entweder für die gleichrangige Rezension veröffentlichen oder einfach neue Konzepte, Information oder (gelegentlich) Technikhumor zu befördern. Der IETF nimmt einige der Vorschläge veröffentlicht als RFCs als Internetstandards an.

Die Bitte Um Anmerkungsdokumente wurde von Steve Crocker 1969 erfunden, um zu helfen, inoffizielle Zeichen auf der Entwicklung des ARPANET zu registrieren. Sie sind die amtliche Aufzeichnung für Internetspezifizierungen, Protokolle, Verfahren und Ereignisse seitdem geworden.

Geschichte

Der Beginn des RFC-Formats ist 1969 als ein Teil des Samen-ARPANET-Projektes vorgekommen. Heute ist es der offizielle Veröffentlichungskanal für Internet Engineering Task Force (IETF), Internet Architecture Board (IAB), und — einigermaßen — die globale Gemeinschaft von Computernetzforschern im Allgemeinen.

Die Autoren des ersten RFCs haben ihre Arbeit getippt und haben Hardcopys unter den ARPA Forschern in Umlauf gesetzt. Verschieden vom modernen RFCs waren viele der frühen RFCs wirkliche Bitten um Anmerkungen. Der RFC lässt Fragen offen und wird in einem weniger formellen Stil geschrieben. Dieser weniger formelle Stil ist jetzt für Internetdraftdokumente, der Vorgänger-Schritt typisch, bevor er als ein RFC genehmigt wird.

Im Dezember 1969 haben Forscher begonnen, neuen RFCs über den kürzlich betrieblichen ARPANET zu verteilen. RFC 1, betitelt "Gastgeber-Software", wurde von Steve Crocker von der Universität Kaliforniens, Los Angeles (UCLA) geschrieben, und am 7. April 1969 veröffentlicht. Obwohl geschrieben, durch Steve Crocker ist der RFC aus einer frühen Arbeitsgruppe-Diskussion zwischen Steve Crocker, Steve Carr und Jeff Rulifson erschienen.

In RFC 3, der zuerst die RFC Reihe definiert hat, hat Crocker angefangen, die RFC Reihe der "Netzarbeitsgruppe" zuzuschreiben. Das war nicht soviel ein formelles Komitee wie eine lose Vereinigung von für das ARPANET-Projekt interessierten Forschern. Tatsächlich war es jeder, der sich auf Sitzungen und Diskussionen über das Projekt hat anschließen wollen.

Viele der nachfolgenden RFCs der 1970er Jahre sind auch aus UCLA gekommen, weil UCLA einer der ersten Schnittstelle-Nachrichtenverarbeiter war (STÄRKT) auf ARPANET.

Augmentation Research Center (ARC) am Forschungsinstitut von Stanford, das von Douglas Engelbart geleitet ist, war ein anderer der vier ersten ARPANET Knoten und die Quelle von frühem RFCs.

Der KREISBOGEN ist das erste Netzinformationszentrum geworden, das von Elizabeth J. Feinler geführt wurde, um sie zusammen mit anderer Netzinformation zu verteilen.

Von 1969 bis 1998 hat Jon Postel als der RFC Redakteur gedient. (Auf seinem Tod 1998 wurde seine Todesanzeige als RFC 2468 veröffentlicht.)

Im Anschluss an den Ablauf des ursprünglichen ARPANET verpflichten sich mit der amerikanischen Bundesregierung, der Internetgesellschaft vertraglich (im Auftrag des IETF handelnd), zusammengezogen mit der Netzwerkanschlussabteilung der Universität des Südlichen Kaliforniens (USC) Information Sciences Institute (ISI), die Chefredaktion und das Veröffentlichen von Verantwortungen (unter der Richtung des IAB) anzunehmen.

Sandy Ginoza hat sich USC/ISI 1999 angeschlossen, um am RFC-Redigieren und Alice Hagens 2005 zu arbeiten.

Bob Braden hat die Rolle der RFC-Projektleitung übernommen, während Joyce K. Reynolds fortgesetzt hat, ein Teil der Mannschaft bis zum 13. Oktober 2006 zu sein.

Im Juli 2007 wurden "Ströme" von RFCs definiert, so konnten die Redigieren-Aufgaben geteilt werden. IETF Dokumente sind aus IETF Arbeitsgruppen oder Vorlagen gekommen, die von einem IETF Bereichsdirektor von Internet Engineering Steering Group gesponsert sind. Der IAB kann seine eigenen Dokumente veröffentlichen. Ein Forschungsstrom von Dokumenten kommt aus Internet Research Task Force (IRTF), und und unabhängiger Strom schließt Dokumente von anderen Außenquellen ein.

Ein neues Modell wurde 2008 vorgeschlagen, raffiniert, und im August 2009 veröffentlicht, die Aufgabe in mehrere Rollen spaltend.

Die Ströme wurden auch im Dezember 2009 mit für ihren Stil definierten Standards raffiniert.

Im Januar 2010 wurde die RFC Redakteur-Funktion einem Auftragnehmer, Vereinigungsverwaltungslösungen mit Glenn Kowack bewegt, der als der Zwischenreihe-Redakteur dient.

Produktion und Evolution

Der RFC Redakteur teilt jeden RFC eine einzigartige Seriennummer zu. Einmal zugeteilt eine Zahl und veröffentlicht, ein RFC wird nie aufgehoben oder modifiziert; wenn das Dokument Änderungen verlangt, veröffentlichen die Autoren ein revidiertes Dokument. Deshalb ersetzen einige RFCs andere; wie man sagt, werden die ersetzten RFCs missbilligt, oder obsoleted durch das Ersetzen RFC veraltet. Zusammen setzen die in Fortsetzungen veröffentlichten RFCs eine dauernde historische Aufzeichnung aus der Evolution von Internetstandards und den Methoden zusammen. Für mehr Details über RFCs und den RFC-Prozess, sieh RFC 2026, "Der Internetstandardprozess, Revision 3".

Der RFC Produktionsprozess unterscheidet sich vom Standardisierungsprozess von formellen Standardorganisationen wie ISO. Internettechnologieexperten können einen Internetentwurf ohne Unterstützung von einer Außeneinrichtung vorlegen. Standardspurige RFCs werden mit der Billigung vom IETF veröffentlicht, und werden gewöhnlich von Experten erzeugt, die an Arbeitsgruppen teilnehmen, die zuerst einen Internetentwurf veröffentlichen. Diese Annäherung erleichtert anfängliche Runden der gleichrangigen Rezension vor in RFCs reifen Dokumenten.

Die RFC Tradition von pragmatischen, geErfahrungssteuerten, Nachdem-Tatsache-Standardautorschaft, die von Personen oder kleinen Arbeitsgruppen vollbracht ist, kann im Vorteil gegenüber dem mehr formellen, Komitee-gesteuerten Prozess sein, der für ISO und nationale Standardkörper typisch ist.

Die meisten RFCs verwenden ein Standardset von Begriffen, die "MÜSSEN" und "NICHT EMPFOHLEN" (wie definiert, durch RFC 2119), Augmented Backus-Naur Form (ABNF) (wie definiert, durch RFC 5234) als eine Metasprache und einfache textbasierte Formatierung, um das RFCs konsequente und leichte zu behalten, um zu verstehen.

Subreihe

Die RFC Reihe enthält drei Subreihen für IETF RFCs:

BCP: Beste Aktuelle Praxis; obligatorischer IETF RFCs nicht auf der Standardspur, sieh unten.

FYI: Für Ihre Information; durch den IETF geförderter Informations-RFCs, wie angegeben, RFC 1150 (FYI 1). 2011 RFC 6360 obsoleted FYI 1 und geschlossen diese Subreihe.

STD: Standard; das hat gepflegt, das dritte und höchste Reife-Niveau der IETF Standardspur angegeben RFC 2026 (BCP 9) zu sein. 2011 hat RFC 6410 (ein neuer Teil von BCP 9) die Standardspur auf zwei Reife-Niveaus reduziert.

Ströme

Es gibt vier Ströme von RFCs: (1) IETF, (2) Internet-Forschungssonderdezernat, (3) IAB, und (4) unabhängige Vorlage. Nur der IETF schafft BCPs und RFCs auf der Standardspur. Eine unabhängige Vorlage wird durch den IESG für Konflikte mit der IETF-Arbeit überprüft; die Qualität wird von einem unabhängigen Vorlage-Herausgeberausschuss bewertet. Mit anderen Worten sollen Internet-Forschungssonderdezernat und unabhängiger RFCs relevantes Info oder Experimente für das Internet auf freiem Fuß nicht im Konflikt mit der IETF-Arbeit enthalten, RFC 4846, RFC 5742 und RFC 5744 vergleichen.

Das Erreichen RFCs

Die offizielle Quelle für RFCs im World Wide Web ist der RFC Redakteur. Fast jede Person hat RFC, zum Beispiel RFC 5000 veröffentlicht, kann über die URL-ADRESSE wiederbekommen werden:

Jeder RFC wird als ASCII einfacher Text vorgelegt und wird in dieser Form veröffentlicht, aber kann auch in anderen Formaten verfügbar sein. Jedoch, der endgültige

die Version jeder standardspurigen Spezifizierung ist die ASCII Version.

Für den leichten Zugang zum metadata eines RFC, einschließlich Auszugs, Schlüsselwörter, Autors (En), Erscheinungsdatums, Errata, Status,

und besonders spätere Aktualisierungen, die RFC Redakteur-Seite bietet eine Suchform mit vielen an

Eigenschaften. Eine Wiederrichtung stellt einige effiziente Parameter, Beispiel auf:

Offizielle International Standard Serial Number (ISSN) der RFC Reihe ist 2070-1721.

Status

Nicht alle RFCs sind Standards. Jeder RFC wird eine Benennung hinsichtlich des Status innerhalb des Internetstandardisierungsprozesses zugeteilt. Dieser Status ist einer des folgenden: Informations-, Experimentell, Best Current Practice (BCP), Standardspur, oder Historisch (sic). Standardspurige Dokumente werden weiter in den Vorgeschlagenen Standard, den Draftstandard und die Internetstandard-Unterlagen geteilt. Der Historische Begriff wird auf missbilligte standardspurige Dokumente oder veraltete RFCs angewandt, die veröffentlicht wurden, bevor die Standardspur gegründet wurde. Nur der IETF, der von Internet Engineering Steering Group (IESG) vertreten ist, kann standardspurigen RFCs genehmigen.

Jeder RFC ist statisch; wenn das Dokument geändert wird, wird es wieder vorgelegt und hat eine neue RFC Zahl zugeteilt. Wenn ein RFC ein Internetstandard (STD) wird, wird er eine STD Zahl zugeteilt, aber behält seine RFC Zahl; jedoch, wenn ein Internetstandard aktualisiert wird, bleibt seine Zahl dasselbe, und es bezieht sich einfach auf einen verschiedenen RFC oder Satz von RFCs. Ein gegebener Internetstandard, STD n, kann RFCs x und y zu einem festgelegten Zeitpunkt sein, aber später kann derselbe Standard aktualisiert werden, um RFC z stattdessen zu sein. Zum Beispiel 2007 war RFC 3700 ein Internetstandard — STD 1 — und im Mai 2008 wurde er durch RFC 5000 ersetzt, so ist RFC 3700 geänderte zum Historischen, RFC 5000 ist ein Internetstandard und STD 1 geworden, RFC 5000. Wenn STD 1 wieder aktualisiert wird, wird er sich einfach auf einen neueren RFC beziehen, der die Standardspur vollendet haben wird, aber es wird noch STD 1 sein. Beste Aktuelle Methoden arbeiten auf eine ähnliche Mode; BCP n bezieht sich auf einen bestimmten RFC oder Satz von RFCs, aber welcher RFC sich oder RFCs mit der Zeit ändern können.

Die endgültige Liste von Internetstandards ist selbst ein Internetstandard, STD 1: Internetbeamter-Protokoll-Standards.

"Informations-" Status

Ein Informations-RFC kann sein fast irgendetwas vom 1. April scherzt über Eigentumsprotokolle bis zu weit anerkanntem wesentlichem RFCs wie Domainname-Systemaufbau und Delegation (RFC 1591). Ein Informations-RFCs hat die Subreihe gebildet. Einige alte FYIs sind noch, z.B, das Internetbenutzerwörterverzeichnis RFC 1983 (FYI 18), und Der Tao von IETF RFC 4677 (FYI 17) interessant.

"Experimenteller" Status

Ein experimenteller RFC kann ein IETF Dokument oder eine individuelle Vorlage dem RFC 'Redakteur' sein. Ein Entwurf wird experimentell benannt, wenn es unklar ist, dass der Vorschlag, wie beabsichtigt, oder unklar arbeiten wird, wenn der Vorschlag weit angenommen wird. Experimenteller RFCs kann der Standardspur gefördert werden, wenn es populär wird und gut arbeitet.

Status "beste aktuelle Praxis"

Die Subreihe der besten aktuellen Praxis (BCP) sammelt Verwaltungsdokumente und andere Texte, die betrachtet werden, weil Beamter herrscht und nicht nur Informations-, aber die über die Leitungsdaten nicht betreffen. Die Grenze zwischen Standardspur und BCP ist häufig unklar. Wenn ein Dokument nur den Internetstandardprozess, wie BCP 9, oder IETF Regierung betrifft, ist es klar ein BCP. Wenn es nur Regeln und Regulierungen für Registrierungen von Internet Assigned Numbers Authority (IANA) definiert, ist es weniger klar; die meisten dieser Dokumente sind BCPs, aber einige sind auf der Standardspur.

Die BCP Reihe bedeckt auch technische Empfehlungen dafür, wie man Internetstandards übt; zum Beispiel greift die Empfehlung, Quelle zu verwenden, die durchscheint, um DoS zu machen, schwieriger an (RFC 2827: "Netzeintrittsentstörung: Das Besiegen der Leugnung von Dienstangriffen, die IP Quelladressmanipulation verwenden") ist BCP 38.

"Historischer" Status

Ein historischer RFC ist derjenige, der veraltet durch eine neuere Version gemacht worden ist, dokumentiert ein Protokoll, das interessant im aktuellen Internet nicht betrachtet wird, oder von der Standardspur aus anderen Gründen entfernt worden ist. Einige veraltete RFCs werden als historisch nicht klassifiziert, weil der Internetstandardprozess allgemein normative Verweisungen von nicht erlaubt, verfolgen Standards RFC zu einem anderen RFC mit dem niedrigeren Status. Außerdem interessieren sich wenige für das Arbeiten durch die erforderlichen Verfahrensdetails, RFCs klassifiziert als historisch zu bekommen und den ganzen RFCs normativ abhängig davon zu aktualisieren.

"Unbekannter" Status

Unbekannter Status wird für einen sehr alten RFCs verwendet, wo es unklar ist, welchen Status das Dokument bekommen würde, wenn es heute veröffentlicht würde. Einige dieser RFCs würden überhaupt heute nicht veröffentlicht; ein früher RFC war häufig gerade dass: Eine einfache Bitte um Anmerkungen, nicht beabsichtigt, um ein Protokoll, Verwaltungsverfahren oder irgend etwas anderes anzugeben, für das die RFC Reihe heute verwendet wird.

Siehe auch

• Der Tag von Aprilnarren RFC
• Internetexperiment-Zeichen
• Liste von HTTP Statuskennzeichen
• Liste von RFCs

Links

• RFC Redakteur
• RFC Datenbank
• RFC Errata
• RFC häufig gestellte Fragen
• RFC Index (Text)
• Offizieller RFC Standardisierungsstatus
• Die RFC Seite von IETF
• RFC Index (HTML) Mit dem Text jedes RFC, erwähnt auch, was anderen RFCs dieser "aktualisiert" oder durch "aktualisiert wird".