Anfrage für Kommentare

Für den Wikipedia -Prozess siehe Wikipedia: Anfragen nach Kommentaren.

A Anfrage für Kommentare (RFC) ist eine Veröffentlichung in einer Serie aus der Hauptkörpers für technische Entwicklung und Standards für die Standards für die Internetam prominentesten die Internettechnik-Arbeitsgruppe (IETF). Ein RFC wird von Einzelpersonen oder Gruppen von Ingenieuren verfasst und Informatiker in Form von a Memorandum Beschreibung von Methoden, Verhaltensweisen, Forschung oder Innovationen, die für die Arbeit von Internet- und Internetverbindung anwendbar sind. Es wird entweder für eingereicht Peer Review oder neue Konzepte, Informationen oder gelegentlich technische Humor zu vermitteln.[1]

Das IETF übernimmt einige der als RFCs veröffentlichten Vorschläge als RFCs als Internetstandards. Viele RFCs sind jedoch informativ oder experimenteller Natur und keine Standards.[2] Das RFC -System wurde von erfunden von Steve Crocker 1969 zur Aufzeichnung inoffizieller Notizen zur Entwicklung von Arpanet. RFCs sind seitdem offizielle Dokumente des Internets geworden Spezifikationen, Kommunikationsprotokolle, Verfahren und Ereignisse.[3] Laut Crocker formen die Dokumente "die inneren Funktionsweise des Internets und haben eine wichtige Rolle für den Erfolg gespielt", sind aber außerhalb der Community nicht allgemein bekannt.[4]

Außerhalb der Internet -Community haben auch andere Dokumente genannt Anfragen nach Kommentaren wurden veröffentlicht in US -Bundesregierung Arbeit, wie die National Highway Traffic Safety Administration.[5]

Geschichte

Die Gründung des RFC -Formats trat 1969 als Teil des Samens auf Arpanet Projekt.[4] Heute ist es der offizielle Veröffentlichungskanal für die Internet Engineering Task Force (IETF), die Internet Architecture Board (IAB) und - in gewissem Maße - die globale Community von Computernetzwerkforschern im Allgemeinen.

Die Autoren der ersten RFCs Schreibmaschine ihre Arbeit und zirkulierte Ausdrucke unter den ARPA Forscher. Im Gegensatz zu den modernen RFCs waren viele der frühen RFCs tatsächlich Anfragen nach Kommentaren und wurden als solche bezeichnet, um nicht zu deklarativ zu klingen und die Diskussion zu fördern.[6][7] Die RFC lässt Fragen offen und sind in einem weniger formalen Stil geschrieben. Dieser weniger formale Stil ist jetzt typisch für Internetentwurf Dokumente, der Vorläuferschritt, bevor er als RFC genehmigt wurde.

Im Dezember 1969 begannen die Forscher, neue RFCs über das neu operative Arpanet zu verteilen. RFC 1, mit dem Titel "Host Software", wurde von geschrieben von Steve Crocker des Universität von California, Los Angeles (UCLA) und am 7. April 1969 veröffentlicht.[8] Obwohl der RFC von Steve Crocker geschrieben wurde, war er früh aufgetreten Arbeitsgruppe Diskussion zwischen Steve Crocker, Steve Carr und Jeff Rulifson.

In RFC 3, das erstmals die RFC -Serie definierte, hat Crocker die RFC -Serie der Netzwerkarbeitsgruppe zuzuschreiben. Anstatt ein formelles Komitee zu sein, war es eine lockere Vereinigung von Forschern, die sich für das Arpanet -Projekt interessierten. Tatsächlich umfasste jeder, der sich den Sitzungen und Diskussionen über das Projekt anschließen wollte.

Viele der nachfolgenden RFCs der 1970er Jahre stammten ebenfalls aus der UCLA, weil die UCLA einer der ersten von dem ist, was waren Schnittstellenmeldungsprozessoren (Imps) auf Arpanet. Das Augmentation Research Center (ARC) bei Stanford Research Institute, unter der Regie von Douglas Engelbartist ein weiterer der vier ersten von Arpanet Knoten und die Quelle der frühen RFCs. Der Bogen wurde das erste Netzwerkinformationszentrum (Intern), was von verwaltet wurde von Elizabeth J. Feinler Um die RFCs zusammen mit anderen Netzwerkinformationen zu verteilen.[9] Von 1969 bis 1998,, Jon Postel diente als RFC Editor. Bei seinem Tod im Jahr 1998 wurde sein Nachruf als RFC 2468 veröffentlicht.

Nach dem Ablauf des ursprünglichen Arpanet -Vertrags mit der US -Bundesregierung, der Internet Society, die im Namen der IETF handelt, wurde mit der Networking -Abteilung des Vertrags vertrag Universität von Südkalifornien (USC) Information Sciences Institute (ISI) die Redaktions- und Veröffentlichungsverantwortung unter der Leitung des IAB übernehmen. Sandy Ginoza kam 1999 zu USC/ISI, um an der RFC -Bearbeitung und Alice Hagens 2005 zu arbeiten.[10] Bob Braden übernahm die Rolle der RFC -Projektleiterin während Joyce K. Reynolds Bis zum 13. Oktober 2006 war weiterhin Teil des Teams.

Im Juli 2007, Ströme von RFCs wurden definiert, so dass die Bearbeitungsaufgaben geteilt werden konnten. IETF -Dokumente stammten von IETF -Arbeitsgruppen oder Einsendungen, die von einem IETF -Regionsleiter gesponsert wurden Internet -Engineering -Lenkungsgruppe. Das IAB kann ihre eigenen Dokumente veröffentlichen. Ein Forschungsstrom von Dokumenten stammt von der Internet Research Task Force (IRTF) und ein unabhängiger Strom aus anderen externen Quellen.[11] 2008 wurde ein neues Modell vorgeschlagen, verfeinert und im August 2009 veröffentlicht, um die Aufgabe in mehrere Rollen aufzuteilen.[12] einschließlich der RFC Series Advisory Group (RSAG). Das Modell wurde 2012 aktualisiert.[13] Die Ströme wurden auch im Dezember 2009 verfeinert, wobei Standards für ihren Stil definiert wurden.[14] Im Januar 2010 die RFC -Editor Die Funktion wurde in einen Auftragnehmer, Association Management Solutions, übertragen, wobei Glenn Kowack als Interim -Serien -Editor fungierte.[15] Ende 2011 wurde Heather Flanagan als Editor der permanenten RFC -Serie eingestellt. Auch zu dieser Zeit wurde ein RFC Series Oversight Committee (RSOC) gegründet.[16]

Im Jahr 2020 berief die IAB das ein RFC Editor Future Development Program Erörterung potenzieller Änderungen am RFC -Editor -Modell. Die Ergebnisse des Programms enthielten das RFC -Editor -Modell (Version 3) wie definiert in RFC 9280 Veröffentlicht im Juni 2022. Im Allgemeinen soll das neue Modell Verantwortlichkeiten und Prozesse zur Definition und Implementierung von Richtlinien im Zusammenhang mit der RFC -Serie und der RFC -Editor -Funktion klären. Änderungen im neuen Modell umfassten die Festlegung der Position des RFC -Beratungs -Editors, der Arbeitsgruppe RFC Series (RSWG) und die RFC -Serien -Genehmigungsausschuss (RSAB). Es hat auch einen neuen redaktionellen Stream für die RFC -Serie eingerichtet und den RSOC abgeschlossen.

Anfragen nach Kommentaren wurden ursprünglich in Nichts erstelltreflowabel Textformat. Im August 2019 wurde das Format geändert, sodass neue Dokumente in Geräten mit unterschiedlichen Anzeigengrößen optimal angesehen werden können.[17]

Produktion und Versioning

Der RFC -Editor weist jedem RFC A zu Seriennummer. Sobald eine Nummer zugewiesen und veröffentlicht wurde, wird ein RFC niemals aufgehoben oder geändert. Wenn das Dokument Änderungen erfordert, veröffentlichen die Autoren ein überarbeitetes Dokument. Daher ersetzen einige RFCs andere; Die ersetzten RFCs sollen sein veraltet, obsolet, oder veraltet von Der ersetzende RFC. Zusammen umfassen die serialisierten RFCs eine kontinuierliche historische Aufzeichnung der Entwicklung von Internetstandards und -praktiken. Der RFC -Prozess ist in RFC 2026 (dokumentiertDer Internetstandards -Prozess, Revision 3).[18]

Der RFC -Produktionsprozess unterscheidet sich von der Standardisierung Prozess formeller Standardsorganisationen wie z. Internationale Standardisierungsorganisation (ISO). Internet -Technologie -Experten können eine einreichen Internetentwurf Ohne Unterstützung von einer externen Institution. Standards-Track-RFCs werden mit Genehmigung des IETF veröffentlicht und werden normalerweise von Experten produziert, an denen sich beteiligt IETF -Arbeitsgruppen, die zuerst einen Internetentwurf veröffentlichen. Dieser Ansatz erleichtert die anfänglichen Runden der Peer -Überprüfung, bevor Dokumente zu RFCs reifen.

Die RFC-Tradition der pragmatischen, erfahrungsgetriebenen, nach dem Fakten, die von Einzelpersonen oder kleinen Arbeitsgruppen erreicht wurden, können wichtige Vorteile haben[Klarstellung erforderlich] Über den formelleren, aus dem Ausschuss angetriebenen Prozess typisch für ISO- und National Standards-Stellen.

Die meisten RFCs verwenden eine gemeinsame Reihe von Begriffen wie "Muss" und "nicht empfohlen" (wie durch RFC 2119 und RFC 8174 definiert). Augmented Backus -Naur -Form (ABNF) (RFC 5234) als Metasprach- und einfache textbasierte Formatierung, um die RFCs konsequent und leicht zu verstehen.[18]

Sub-Serie

Die RFC-Serie enthält drei Sub-Serien für Ietf RFCS: BCP, FYI und STD. Best Current Practice (BCP) ist eine Unterrunde von obligatorischen IETF-RFCs, die nicht auf Standardspuren sind. Zu Ihrer Information (FYI) finden Sie eine Unterserie von Informations-RFCs, die vom IETF im RFC 1150 (FYI 1) angegeben wird. Im Jahr 2011 veraltete RFC 6360 das FYI 1 und schloss diesen Sub-Serie ab. Standard (STD) war früher das dritte und höchste Reifegrad der in RFC 2026 (BCP 9) angegebenen IETF -Standardspur. Im Jahr 2011 reduzierte RFC 6410 (ein neuer Teil von BCP 9) die Standardspur auf zwei Reife -Werte.

Ströme

Es gibt vier Streams von RFCs: Ietf, Irtf, Iab, und unabhängige Einreichung.[19] Nur das IETF erstellt BCPS und RFCs auf der Standardstrecke. Ein unabhängige Einreichung wird von der überprüft IESG für Konflikte mit IETF -Arbeit; Die Qualität wird von einem bewertet Redaktionsausschuss für unabhängige Einreichung. Mit anderen Worten, IRTF und unabhängig RFCs sollen relevante Informationen oder Experimente für das Internet enthalten, das nicht im Widerspruch zu IETF -Arbeiten steht. Vergleichen Sie RFC 4846, RFC 5742 und RFC 5744.

RFCs erhalten 

RFC 2046 Medientypen November 1996 A. gesammelte Grammatik ................................ 43 1. Einführung Das erste Dokument in diesem Satz, RFC 2045, definiert eine Reihe von Headerfeldern, einschließlich des Inhaltstyps. Das Feld des Inhaltstyps wird verwendet, um die Art der Daten im Körper einer MIME-Entität anzugeben, indem Medientyp- und Subtyp-Identifikatoren angegeben und Hilfsinformationen bereitgestellt werden, die für bestimmte Medientypen erforderlich sein können. Nach dem
RFC 2046, was den Text/die Ebene definiert Mime Typ, ist selbst ein einfacher Text.

Die offizielle Quelle für RFCs auf der Weltweites Netz ist der RFC -Editor. Fast jeder veröffentlichte RFC kann über a abgerufen werden URL des Formulars http://www.rfc-editor.org/rfc/rfc5000.txt, angezeigt für RFC 5000.

Jeder RFC wird als schlicht eingereicht ASCII Text und wird in dieser Form veröffentlicht, kann aber auch in anderen verfügbar sein Formate.

Für den einfachen Zugriff auf die Metadaten eines RFC, einschließlich Abstract, Schlüsselwörter, Autoren, Veröffentlichungsdatum, Errata, Status und insbesondere spätere Updates, bietet die RFC -Editor -Site ein Suchformular mit vielen Funktionen. Eine Umleitung legt einige effiziente Parameter fest: Beispiel: RFC: 5000.

Das offizielle Internationale Standard -Seriennummer (ISSN) der RFC -Serie ist 2070–1721.[14]

Status

Nicht alle RFCs sind Standards.[20][21] Jedem RFC wird im Hinblick auf den Status im Internet -Standardisierungsprozess eine Bezeichnung zugewiesen. Dieser Status ist einer der folgenden: Information, Experimental, Beste aktuelle Praxis, Standardspur, oder Historisch.

Jeder RFC ist statisch; Wenn das Dokument geändert wird, wird es erneut übermittelt und eine neue RFC -Nummer zugewiesen.

Standardspur

Hauptartikel: Internetstandard § Internetstandards

Standards-Track-Dokumente werden weiter unterteilt in Vorgeschlagener Standard und Internetstandard Unterlagen.[22]

Nur das IETF, dargestellt durch die Internet -Engineering -Lenkungsgruppe (IESG) kann genehmigen Standard-Track RFCs.

Wenn ein RFC zu einem Internet Standard (STD) wird, wird ihm eine STD -Nummer zugewiesen, behält jedoch die RFC -Nummer bei. Die endgültige Liste der Internetstandards sind die offiziellen Internet -Protokollstandards. Zuvor wurde STD 1 verwendet, um einen Schnappschuss der Liste zu verwalten.[23]

Wenn ein Internetstandard aktualisiert wird, bleibt die STD -Nummer gleich und bezieht sich nun auf einen neuen RFC oder eine Reihe von RFCs. Ein gegebener Internetstandard, STD n, kann RFCs sein x und y Zu einem bestimmten Zeitpunkt, aber später kann der gleiche Standard aktualisiert werden, um RFC zu sein z stattdessen. Zum Beispiel war RFC 3700 im Jahr 2007 ein Internetstandard - STD 1 - und im Mai 2008 wurde er durch RFC 5000 ersetzt, sodass RFC 3700 zu veränderte Historisch, RFC 5000 wurde zu einem Internetstandard und ab Mai 2008 STD 1 ist RFC 5000. Ab Dezember 2013 RFC 5000 wird durch RFC 7100 ersetzt und aktualisiert RFC 2026, um STD 1 nicht mehr zu verwenden.

(Die besten aktuellen Praktiken funktionieren ähnlich; BCP n Bezieht sich auf ein bestimmtes RFC oder eine Reihe von RFCs, aber welche RFC oder RFCs sich im Laufe der Zeit ändern können).

Information

Ein Information RFC kann fast alles sein von 1. April Witze zu weithin anerkannte essentielle RFCs wie Domainnamensystem Struktur und Delegation (RFC 1591). Einige Informations -RFCs bildeten die Zu Ihrer Information Sub-Serie.

Experimental

Ein Experimental- RFC kann ein IETF -Dokument oder eine individuelle Einreichung beim RFC -Editor sein. Ein Entwurf wird als experimentell bezeichnet, wenn unklar ist, dass der Vorschlag wie beabsichtigt oder unklar funktioniert, wenn der Vorschlag weit verbreitet ist. Ein experimenteller RFC kann zu Standards befördert werden, wenn er populär wird und gut funktioniert.[24]

Beste aktuelle Praxis

Das Beste aktuelle Praxis Unterserie sammelt Verwaltungsdokumente und andere Texte, die als offizielle Regeln und nicht nur als offizielle Regeln angesehen werden Information, aber die nicht beeinflussen über die Drahtdaten. Die Grenze zwischen Standards und BCP ist oft unklar. Wenn ein Dokument nur den Internetstandard -Prozess wie BCP 9 betrifft,[25] Oder IETF -Administration, es ist eindeutig ein BCP. Wenn es nur Regeln und Vorschriften für definiert Internet zugewiesene Zahlen Autorität (IANA) Registrien Es ist weniger klar; Die meisten dieser Dokumente sind BCPs, einige sind jedoch auf der Standardstrecke.

Die BCP -Serie deckt auch technische Empfehlungen für das Üben von Internetstandards ab. Zum Beispiel die Empfehlung, die Quellfilterung zu verwenden, um sie zu erstellen DOS -Angriffe schwieriger (RFC 2827: "Filterung des Netzwerkeingangs: Besiege der Verweigerung von Serviceangriffen, bei denen die IP -Quelladresse Spoofing verwendet wird") ist BCP 38.

Historisch

A historisch RFC ist eine, die die vom RFC definierte Technologie nicht mehr für die Verwendung empfohlen wird, die sich von "veraltet" -Header in einem Ersatz -RFC unterscheidet. Zum Beispiel RFC 821 (SMTP) selbst wird von verschiedenen neueren RFCs veraltet, aber SMTP selbst ist immer noch "aktuelle Technologie", so dass es nicht im "historischen" Status ist.[26] Aber seit BGP Version 4 hat frühere BGP -Versionen vollständig ersetzt, und die RFCs, die diese früheren Versionen wie RFC 1267 beschreiben, wurden historisch bezeichnet.

Unbekannt

Status Unbekannt wird für einige sehr alte RFCs verwendet, bei denen unklar ist, welchen Status das Dokument erhalten würde, wenn es heute veröffentlicht würde. Einige dieser RFCs würden heute überhaupt nicht veröffentlicht. Ein frühes RFC war oft nur so: eine einfache Anfrage nach Kommentaren, nicht dazu bestimmt, ein Protokoll, ein administratives Verfahren oder irgendetwas anderes anzugeben, für das die RFC -Serie heute verwendet wird.[27]

Urheberrechte ©

Die allgemeine Regel ist, dass ursprüngliche Autoren (oder ihre Arbeitgeber, wenn ihre Beschäftigungsbedingungen so festgelegt sind) das Urheberrecht behalten, es sei denn, sie übertragen ihre Rechte ausdrücklich.[28]

Eine unabhängige Stelle, der IETF -Trust, hält das Urheberrecht für einige RFCs und für alle anderen erhält sie eine Lizenz von den Autoren, die es ihm ermöglicht, RFCs zu reproduzieren.[29] Das Internetgesellschaft wird vor RFC4714 als Urheberrechtsinhaber auf viele RFCs verwiesen, hat jedoch seine Rechte an den IETF -Trust übertragen.[30]

Siehe auch

Verweise

  1. ^ Waitzman, David (1. April 1990). Ein Standard für die Übertragung von IP -Datagrammen auf Vogelbetreiber. Ietf. doi:10.17487/rfc1149. RFC 1149. Abgerufen 29. März, 2017.
  2. ^ Huitema, Christ; Postel, Jon; Crocker, Steve (April 1995). Nicht alle RFCs sind Standards. Ietf. doi:10.17487/rfc1796. RFC 1796. Abgerufen 15. Mai, 2018.
  3. ^ "RFCs, Internetanfrage nach Kommentaren". LivingInternet.com. Abgerufen 3. April, 2012.
  4. ^ a b "Stephen D. Crocker, Wie das Internet seine Regeln erhielt, The New York Times, 6. April 2009 ". Die New York Times. 7. April 2009. Abgerufen 3. April, 2012.
  5. ^ Bekanntmachung und Anfrage nach Kommentaren, in Bundesregister (16. Januar 2018).
  6. ^ Hafner, Katie; Lyon, Matthew (1996). Wo Zauberer spät aufbleiben: Die Ursprünge des Internets.
  7. ^ Metz, Cade (18. Mai 2012). "Treffen Sie den Mann, der die Anweisungen für das Internet erfunden hat". Verdrahtet. Abgerufen 18. Dezember, 2018.
  8. ^ Crocker, Steve (7. April 1969). "RFC 1 ". {{}}: Journal zitieren erfordert |journal= (Hilfe)
  9. ^ Elizabeth J. Feinler (Juli bis September 2010). "Das Netzwerkinformationszentrum und seine Archive". Annalen der Geschichte des Computers. 32 (3): 83–89. doi:10.1109/mahc.2010.54. S2CID 206443021.
  10. ^ Leslie Daigle (März 2010). "RFC -Editor im Übergang: Vergangenheit, Gegenwart und Zukunft". Das Internet Protocol Journal. Vol. 13, nein. 1. Cisco -Systeme. Abgerufen 17. August, 2011.
  11. ^ Daigle, Leslie (Juli 2007). Die RFC -Serie und der RFC -Editor. Ietf. doi:10.17487/rfc4844. RFC 4844.
  12. ^ Kolkman, Olaf (August 2009). RFC -Editor -Modell (Version 1). Ietf. doi:10.17487/rfc5620. RFC 5620.
  13. ^ Kolkman, Olaf; Halpern, Joel (Juni 2012). RFC -Editor -Modell (Version 2). Ietf. doi:10.17487/rfc6635. RFC 6635.
  14. ^ a b Daigle, Leslie; Kolkman, Olaf (Dezember 2009). RFC -Ströme, Header und Kesselplatten. Ietf. doi:10.17487/RFC5741. RFC 5741.
  15. ^ Glenn Kowack (7. Januar 2010). "RFC Editor Transition Ankündigung". Archiviert von das Original am 29. Juni 2011.
  16. ^ "Der Redakteur der RFC -Serie und die Serie -Reorganisation". Abgerufen 5. April, 2013.
  17. ^ "RFC -Format ändern FAQ".
  18. ^ a b "RFC -Index". RFC -Editor. 25. Mai 2008. Abgerufen 26. Mai, 2008.
  19. ^ "Unabhängige Einsendungen". RFC -Editor. Abgerufen 5. Januar, 2018.
  20. ^ "Sind alle RFCS -Internetstandards Dokumente?". RFC -Editor. Abgerufen 16. März, 2018.
  21. ^ Huitema, Christ; Postel, Jon; Crocker, Steve (April 1995). Nicht alle RFCs sind Standards. Ietf. doi:10.17487/rfc1796. RFC 1796. ... Jeder RFC hat einen Status…: Informations-, Versuchs- oder Standard -Track (vorgeschlagener Standard, Entwurfsstandard, Internetstandard) oder historisch.
  22. ^ Housley, Russell; Crocker, Dave; Burger, Eric (Oktober 2011). Reduzierung der Standardspur auf zwei Reife -Ebenen. Ietf. doi:10.17487/rfc6410. RFC 6410.
  23. ^ RFC 7100 Pensionierung des Zusammenfassungsdokuments "Internet Official Protocol Standards"
  24. ^ "7.5. Informations- und experimentelle RFCs", Das Tao von IETF, abgerufen 26. November, 2017
  25. ^ Bradner, Scott O. (Oktober 1996). Der Internetstandards -Prozess - Revision 3. Ietf. BCP 9. Abgerufen 25. Oktober, 2017.
  26. ^ "IESG -Aussage zur Bezeichnung von RFCs als historisch". Ietf. 20. Juli 2014. Abgerufen 14. April, 2016.
  27. ^ IETF -Standards, die von ISC -Mitwirkenden verfasst wurden, Internetsysteme Konsortium, 10. September 2021, archiviert vom Original am 5. April 2022, abgerufen 11. April, 2022, Viele der frühen RFC-Dokumente haben Status „unbekannt“, weil sie aus der lang vergangenen Ära stammen, als ein RFC wirklich nur eine Anfrage nach Kommentaren war.
  28. ^ "Reproduzieren von RFCs".Ietf Trust. Abgerufen 12. August, 2021.
  29. ^ Bradner, Scott;Contreras, Jorge (November 2008). Rechteversorgungsbwirkende sorgen für den IETF -Trust. Ietf. doi:10.17487/rfc5378. RFC 5378.
  30. ^ "Reproduzieren von RFCs".Ietf Trust. Abgerufen 13. August, 2021.

Externe Links