Steve Crocker sitzt mit einem Laptop da
Steve Crocker , der Autor mehrerer Request for Comments-Dokumente, darunter des allerersten RFC.

Ein Request for Comments ( RFC ) ist eine Veröffentlichung aus der Reihe der wichtigsten technischen Entwicklungs- und Standardisierungsgremien für das Internet , allen voran der Internet Engineering Task Force (IETF). [ 1 ] [ 2 ] Ein RFC wird von einzelnen Ingenieuren oder Gruppen von Informatikern in Form eines Memorandums verfasst , das Methoden, Verhaltensweisen, Forschungsergebnisse oder Innovationen beschreibt, die für die Funktionsweise des Internets und internetverbundener Systeme relevant sind. Er wird entweder zur Begutachtung durch Fachkollegen eingereicht oder um neue Konzepte, Informationen oder, gelegentlich, auch technischen Humor zu vermitteln. [ 3 ]

Die IETF übernimmt einige der als RFCs veröffentlichten Vorschläge als Internetstandards . Viele RFCs sind jedoch informativer oder experimenteller Natur und stellen keine Standards dar. [ 4 ] Das RFC-System wurde 1969 von Steve Crocker entwickelt, um inoffizielle Notizen zur Entwicklung des ARPANET festzuhalten . RFCs haben sich seither zu offiziellen Dokumenten für Internetspezifikationen , Kommunikationsprotokolle , Verfahren und Ereignisse entwickelt. [ 5 ] Laut Crocker prägen die Dokumente „die Funktionsweise des Internets und haben maßgeblich zu seinem Erfolg beigetragen“, sind aber außerhalb der Community nicht weit verbreitet. [ 6 ]

Außerhalb der Internet-Community wurden auch andere Dokumente veröffentlicht , die als Aufforderungen zur Stellungnahme bezeichnet werden, beispielsweise in der Arbeit der US-Bundesregierung , wie etwa der National Highway Traffic Safety Administration . [ 7 ]

Geschichte

Die Entstehung des RFC-Formats erfolgte 1969 im Rahmen des wegweisenden ARPANET- Projekts. [ 6 ] Heute ist es der offizielle Publikationskanal der Internet Engineering Task Force (IETF), des Internet Architecture Board (IAB) und – bis zu einem gewissen Grad – der globalen Gemeinschaft der Computernetzwerkforscher im Allgemeinen.

Die Autoren der ersten RFCs tippten ihre Arbeiten und verteilten gedruckte Exemplare an die ARPA- Forscher. Anders als die heutigen RFCs waren viele der frühen RFCs tatsächlich „Requests for Comments“ (Anfragen zur Kommentierung) und wurden entsprechend betitelt, um einen zu deklarativen Klang zu vermeiden und Diskussionen anzuregen. [ 8 ] [ 9 ] RFCs lassen Fragen offen und sind in einem weniger formellen Stil verfasst. Dieser weniger formelle Stil ist heute typisch für Internet-Drafts , die Vorstufe zur Genehmigung als RFC.

Im Dezember 1969 begannen Forscher, neue RFCs über das neu in Betrieb genommene ARPANET zu verbreiten. RFC  1 mit dem Titel „Host Software“ wurde von Steve Crocker von der University of California, Los Angeles (UCLA) verfasst und am 7. April 1969 veröffentlicht. [ 10 ] Obwohl der RFC von Steve Crocker geschrieben wurde, war er aus einer frühen Arbeitsgruppendiskussion zwischen Steve Crocker, Steve Carr und Jeff Rulifson hervorgegangen .

InMit RFC  3 , der die RFC-Reihe erstmals definierte, begann Crocker, die RFC-Reihe der Network Working Group zuzuordnen. Diese war kein formelles Komitee, sondern ein loser Zusammenschluss von Forschern, die am ARPANET-Projekt interessiert waren. Im Prinzip konnte jeder an den Treffen und Diskussionen über das Projekt teilnehmen.

Viele der nachfolgenden RFCs der 1970er Jahre stammten ebenfalls von der UCLA, da die UCLA einer der ersten Interface Message Processors (IMPs) im ARPANET war. Das Augmentation Research Center (ARC) am Stanford Research Institute unter der Leitung von Douglas Engelbart war ein weiterer der vier ersten ARPANET- Knoten und die Quelle früher RFCs. Das ARC wurde zum ersten Netzwerkinformationszentrum ( InterNIC ), das von Elizabeth J. Feinler geleitet wurde, um die RFCs zusammen mit anderen Netzwerkinformationen zu verbreiten. [ 11 ]

Am 1. April 1978 wurde RFC  748 als Parodie auf den TCP/IP -Dokumentationsstil veröffentlicht. Diese Tradition wurde 1989 mit der Veröffentlichung von RFC  1097 fortgesetzt , das eine Option für Telnet- Clients zur Anzeige unterschwelliger Nachrichten beschreibt . Seitdem erscheinen jährlich weitere RFCs zum 1. April , insbesondere RFC  2324 , das das Hypertext-Kaffeekannen-Steuerungsprotokoll beschreibt und den HTTP-Statuscode 418 „Ich bin eine Teekanne“ definiert. Humorvolle RFCs lassen sich bis zu RFC  439 zurückverfolgen , der im Januar 1973 veröffentlicht wurde.

RFC-Editor-Funktion

Von 1969 bis 1998 war Jon Postel als Herausgeber des RFC tätig. Nach seinem Tod im Jahr 1998 wurde sein Nachruf als RFC  2468 veröffentlicht . [ 12 ]

Nach Auslaufen des ursprünglichen ARPANET-Vertrags mit der US-Bundesregierung beauftragte die Internet Society im Auftrag der IETF die Networking Division des Information Sciences Institute (ISI) der University of Southern California (USC ) mit der Übernahme der Redaktions- und Veröffentlichungsaufgaben unter der Leitung des IAB. Sandy Ginoza kam 1999 zu USC/ISI, um an der Bearbeitung der RFCs mitzuarbeiten, Alice Hagens folgte 2005. [ 13 ] Bob Braden übernahm die Projektleitung der RFCs, während Joyce K. Reynolds bis zum 13. Oktober 2006 Teil des Teams blieb.

Im Juli 2007 wurden RFC- Stränge definiert, um die Bearbeitungsaufgaben aufzuteilen. IETF-Dokumente stammten von IETF-Arbeitsgruppen oder von Einreichungen, die von einem IETF-Bereichsleiter der Internet Engineering Steering Group ( IESG) initiiert wurden . Das IAB kann eigene Dokumente veröffentlichen. Ein Forschungsstrang von Dokumenten stammt von der Internet Research Task Force (IRTF), ein unabhängiger Strang von anderen externen Quellen. [ 14 ] 2008 wurde ein neues Modell vorgeschlagen, verfeinert und im August 2009 veröffentlicht, das die Aufgaben in mehrere Rollen aufteilte, [ 15 ] darunter die RFC Series Advisory Group (RSAG). Das Modell wurde 2012 [ 16 ] und 2020 [ 17 ] aktualisiert . Die Stränge wurden im Dezember 2009 weiter verfeinert und Stilstandards definiert. [ 18 ] Im Januar 2010 wurde die Funktion des RFC-Editors an den externen Dienstleister Association Management Solutions übertragen, wobei Glenn Kowack die Position des Interims-Serienherausgebers übernahm. [ 19 ] Ende 2011 wurde Heather Flanagan als ständige Herausgeberin der RFC-Reihe (RFC Series Editor, RSE) eingestellt. Ebenfalls zu dieser Zeit wurde ein Aufsichtsausschuss für die RFC-Reihe (RFC Series Oversight Committee, RSOC) gegründet. [ 20 ]

Im Jahr 2020 berief das IAB das Programm „RFC Editor Future Development“ ein, um mögliche Änderungen am RFC-Editor-Modell zu erörtern. Die Ergebnisse des Programms umfassten das RFC-Editor-Modell (Version 3) gemäß RFC  9280 , veröffentlicht im Juni 2022. [ 1 ] Das neue Modell dient im Allgemeinen der Klärung von Verantwortlichkeiten und Prozessen für die Definition und Umsetzung von Richtlinien im Zusammenhang mit der RFC-Reihe und der Funktion des RFC-Editors. Zu den Änderungen im neuen Modell gehörten die Einrichtung der Position des RFC Consulting Editor, der RFC Series Working Group (RSWG) und des RFC Series Approval Board (RSAB). Außerdem wurde ein neuer redaktioneller Bereich für die RFC-Reihe geschaffen und das RSOC aufgelöst. Die Rolle des RSE wurde in RFC Series Consulting Editor (RSCE) umbenannt. Im September 2022 wurde Alexis Rossi in diese Position berufen. [ 21 ]

Neues Veröffentlichungsformat

Die Anfragen nach Kommentaren wurden ursprünglich im nicht dynamisch anpassbaren Textformat erstellt. Im August 2019 wurde das Format geändert, um eine optimale Darstellung neuer Dokumente auf Geräten mit unterschiedlichen Bildschirmgrößen zu gewährleisten. [ 22 ]

Produktion und Versionierung

Der RFC-Editor vergibt an jeden RFC eine Seriennummer . Einmal vergeben und veröffentlicht, wird ein RFC weder zurückgezogen noch geändert. Sollten Änderungen erforderlich sein, veröffentlichen die Autoren eine überarbeitete Fassung. Daher ersetzen manche RFCs andere; die ersetzten RFCs gelten als veraltet oder durch den ersetzenden RFC überholt . Zusammen bilden die nummerierten RFCs eine kontinuierliche historische Dokumentation der Entwicklung von Internetstandards und -praktiken. Der RFC-Prozess ist in RFC  2026 ( The Internet Standards Process, Revision 3 ) dokumentiert. [ 23 ]

Der RFC-Erstellungsprozess unterscheidet sich vom Standardisierungsprozess formaler Standardisierungsorganisationen wie der Internationalen Organisation für Normung (ISO). Internet-Technologieexperten können ohne Unterstützung einer externen Institution einen Internet-Draft einreichen . Standardisierungsrelevante RFCs werden mit Zustimmung der IETF veröffentlicht und in der Regel von Experten erstellt, die in IETF-Arbeitsgruppen mitwirken , welche zunächst einen Internet-Draft veröffentlichen. Dieser Ansatz ermöglicht erste Peer-Review-Runden, bevor Dokumente zu RFCs reifen. [ 24 ]

Die RFC-Tradition der pragmatischen, erfahrungsbasierten und nachträglichen Normenerstellung durch Einzelpersonen oder kleine Arbeitsgruppen kann wichtige Vorteile gegenüber dem formelleren, komiteeorientierten Prozess bieten, der typisch für ISO und nationale Normungsinstitutionen ist. [ 25 ]

Die meisten RFCs verwenden einen gemeinsamen Satz von Begriffen wie „MUSS“ und „NICHT EMPFOHLEN“ (wie in RFC  2119 und 8174 definiert ), die erweiterte Backus-Naur-Form (ABNF) ( RFC  5234 ) als Metasprache und eine einfache textbasierte Formatierung, um die Konsistenz und Verständlichkeit der RFCs zu gewährleisten. [ 23 ]

Unterserie

Die RFC-Reihe umfasst drei Unterreihen für IETF -RFCs: BCP, FYI und STD. Best Current Practice (BCP) ist eine Unterreihe obligatorischer IETF-RFCs, die nicht Teil des Standardisierungsprozesses sind. For Your Information (FYI) ist eine Unterreihe informativer RFCs, die von der IETF gemäß RFC  1150 (FYI 1) gefördert werden. 2011 wurde FYI 1 durch RFC  6360 ersetzt und diese Unterreihe damit abgeschlossen. Standard (STD) war ursprünglich die dritte und höchste Reifestufe des IETF-Standardisierungsprozesses gemäß RFC  2026 (BCP 9). 2011 reduzierte RFC  6410 (ein neuer Teil von BCP 9) den Standardisierungsprozess auf zwei Reifestufen.

Bäche

Es gibt fünf RFC-Stränge: IETF , IRTF , IAB , unabhängige Einreichungen [ 26 ] und Redaktionell . Nur die IETF erstellt BCPs und RFCs im Rahmen des Standardisierungsprozesses. Das IAB veröffentlicht Informationsdokumente zu Richtlinien oder Architektur. Die IRTF veröffentlicht Forschungsergebnisse, entweder als Informationsdokumente oder als Experimente. Unabhängige Einreichungen werden nach Ermessen des Independent Submissions Editor veröffentlicht. Nicht-IETF-Dokumente werden von der IESG auf Konflikte mit IETF-Arbeiten geprüft. IRTF- und unabhängige  RFCs enthalten in der Regel relevante Informationen oder Experimente für das Internet im Allgemeinen, die nicht im Widerspruch zu IETF-Arbeiten stehen. Vgl. RFC 4846  , 5742 und 5744. [ 27 ] [ 28 ] Der redaktionelle Strang dient der Umsetzung redaktioneller Richtlinienänderungen innerhalb der RFC-Serie (siehe RFC  9280 ). [ 1 ]

Beschaffung von RFCs

RFC 2046 Medientypen November 1996 A. Gesammelte Grammatik .................................... 43 1. Einleitung Das erste Dokument dieser Reihe, RFC 2045, definiert eine Reihe von Header-Dateien. Felder, einschließlich Content-Type. Das Feld Content-Type wird verwendet, um die Art der Daten im Body einer MIME-Entität spezifizieren, indem durch Angabe von Medientyp- und Subtyp-Kennungen und durch Bereitstellung von Hilfsinformationen Informationen, die für bestimmte Medientypen erforderlich sein können. Nach dem
RFC  2046 , das den MIME-Typ text/plain definiert , ist selbst ein Klartext.

Die offizielle Quelle für RFCs im World Wide Web ist der RFC Datatracker . Fast jeder veröffentlichte RFC kann über eine URL der Form https://datatracker.ietf.org/doc/html/rfc5000 abgerufen werden, wie im Beispiel für RFC  5000 gezeigt .

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

Für den einfachen Zugriff auf die Metadaten eines RFC, einschließlich Abstract, Schlüsselwörter, Autor(en), Veröffentlichungsdatum, Errata, Status und insbesondere spätere Aktualisierungen, bietet die RFC-Editor-Website ein Suchformular mit vielen Funktionen. Eine Weiterleitung setzt einige effiziente Parameter, z. B.: rfc:5000. [ 4 ]

Die offizielle internationale Standardseriennummer (ISSN) der RFC-Serie lautet 2070-1721. [ 18 ]

Status

Nicht alle RFCs sind Standards. [ 29 ] Jedem RFC wird hinsichtlich seines Status im Internet-Standardisierungsprozess eine Kennzeichnung zugewiesen. Dieser Status ist einer der folgenden: Informationell , Experimentell , Bewährte Praxis , Standardisierungspfad oder Historisch . [ 4 ]

Sobald ein RFC eingereicht, angenommen und veröffentlicht wurde, kann er nicht mehr geändert werden. Errata können eingereicht werden und werden separat veröffentlicht. Umfangreichere Änderungen erfordern eine neue Einreichung, die eine neue Seriennummer erhält. [ 30 ]

Standards Track

Die Dokumente des Normenprozesses werden weiter in vorgeschlagene Normen und Internetnormen unterteilt . [ 31 ]

Nur die IETF, vertreten durch die Internet Engineering Steering Group (IESG), kann standardbasierte RFCs genehmigen.

Wird ein RFC zu einem Internetstandard (STD), erhält er eine STD-Nummer, behält aber seine RFC-Nummer. Die maßgebliche Liste der Internetstandards sind die offiziellen Internetprotokollstandards. Früher wurde STD 1 verwendet, um eine Momentaufnahme dieser Liste zu verwalten. [ 32 ]

Wird ein Internetstandard aktualisiert, bleibt seine STD-Nummer gleich und bezieht sich nun auf einen neuen RFC oder eine Gruppe von RFCs. Ein bestimmter Internetstandard (STD n ) kann zu einem bestimmten Zeitpunkt die RFCs x und y umfassen , später jedoch auf RFC z aktualisiert werden . Beispielsweise war RFC  3700 im Jahr 2007 ein Internetstandard (STD 1) und wurde im Mai 2008 durch RFC  5000 ersetzt . RFC  3700 wurde daraufhin als historisch eingestuft , RFC  5000 wurde zum Internetstandard, und ab Mai 2008 war RFC  5000 die STD 1. Im Dezember 2013 wurde RFC  5000 durch RFC  7100 ersetzt , wodurch RFC  2026 aktualisiert wurde und STD 1 nicht mehr verwendet wird.

(Die Best Current Practices funktionieren nach einem ähnlichen Prinzip; BCP n bezieht sich auf einen bestimmten RFC oder eine Gruppe von RFCs, wobei sich dieser oder diese RFCs im Laufe der Zeit ändern können).

Informations

Ein informativer RFC kann nahezu alles sein, von Aprilscherzen bis hin zu allgemein anerkannten, grundlegenden RFCs wie Domain Name System Structure and Delegation ( RFC  1591 ). Einige informative RFCs bildeten die Unterreihe „FYI“ .

Experimental

Ein experimenteller RFC kann ein IETF-Dokument oder eine individuelle Einreichung beim RFC-Editor sein. Ein Entwurf wird als experimentell eingestuft, wenn unklar ist, ob der Vorschlag wie beabsichtigt funktioniert oder ob er breite Akzeptanz finden wird. Ein experimenteller RFC kann in den Standardisierungsprozess aufgenommen werden, wenn er sich bewährt und erfolgreich ist. [ 33 ]

Aktuelle Best Practice

Die Unterreihe „Best Current Practice“ (BCP ) sammelt Verwaltungsdokumente und andere Texte, die als offizielle Regeln gelten und nicht nur informativen Charakter haben, aber keinen Einfluss auf die Datenübertragung über das Netzwerk ausüben. Die Grenze zwischen Standardisierungsprozess und BCP ist oft fließend. Betrifft ein Dokument ausschließlich den Internet-Standardisierungsprozess, wie beispielsweise BCP 9 [ 34 ] , oder die IETF-Verwaltung, handelt es sich eindeutig um ein BCP. Definiert es hingegen nur Regeln und Vorschriften für die Registrierungsstellen der Internet Assigned Numbers Authority (IANA), ist die Grenze weniger eindeutig; die meisten dieser Dokumente sind BCPs, einige befinden sich jedoch im Standardisierungsprozess.

Die BCP-Reihe umfasst auch technische Empfehlungen zur Umsetzung von Internetstandards; beispielsweise ist die Empfehlung, Quellfilterung zu verwenden, um DoS-Angriffe zu erschweren ( RFC  2827 : " Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing ") BCP 38 .

Historisch

Ein historischer RFC ist ein RFC, dessen definierte Technologie nicht mehr zur Verwendung empfohlen wird. Dies unterscheidet sich vom „Obsoletes“-Header eines Nachfolge-RFCs. Beispielsweise ist RFC  821 ( SMTP ) selbst durch verschiedene neuere RFCs überholt, SMTP selbst gilt jedoch weiterhin als „aktuelle Technologie“ und hat daher keinen „historischen“ Status. [ 35 ] Da BGP Version 4 jedoch frühere BGP-Versionen vollständig ersetzt hat, wurden die RFCs, die diese früheren Versionen beschreiben, wie beispielsweise RFC  1267 , als historisch eingestuft.

Unbekannt

Der Status „unbekannt“ wird für einige sehr alte RFCs verwendet, bei denen unklar ist, welchen Status das Dokument bei einer heutigen Veröffentlichung erhalten würde. Einige dieser RFCs würden heute überhaupt nicht mehr veröffentlicht werden; ein früher RFC war oft genau das: eine einfache Anfrage nach Kommentaren, die nicht dazu gedacht war, ein Protokoll, ein Verwaltungsverfahren oder etwas anderes zu spezifizieren, wofür die RFC-Reihe heute verwendet wird. [ 36 ]

Grundsätzlich behalten die Urheber (oder ihre Arbeitgeber, falls dies in ihren Anstellungsbedingungen vorgesehen ist) das Urheberrecht, es sei denn, sie übertragen ihre Rechte ausdrücklich. [ 37 ]

Eine unabhängige Organisation, der IETF Trust, besitzt das Urheberrecht an einigen RFCs und erhält für alle anderen von den Autoren eine Lizenz zur Vervielfältigung. [ 38 ] Die Internet Society wird in vielen RFCs vor RFC 4714 als Urheberrechtsinhaberin genannt, hat ihre Rechte jedoch an den IETF Trust übertragen. [ 39 ]

Siehe auch

Referenzen

  1. ^ a b c P. Saint-Andre, Hrsg. (Juni 2022). RFC Editor Model (Version 3) . Internet Architecture Board . doi : 10.17487/RFC9280 . ISSN 2070-1721 . RFC 9280 . Informationell. Ersetzt durch RFC  9920. Aktualisiert durch RFC  9720. Ersetzt RFC  8728. Aktualisiert RFC  7841 , 8729 und 8730 .
  2. ^ "RFCs" . IETF . Abgerufen am 5. November 2023 .
  3. ^ Waitzman, David (1. April 1990). Ein Standard für die Übertragung von IP-Datagrammen auf Vogelträgern . IETF . doi : 10.17487/RFC1149 . RFC 1149. Abgerufen am 29. März 2017 .
  4. ^ a b c C. Huitema ; J. Postel ; S. Crocker (April 1995). Nicht alle RFCs sind Standards . Network Working Group. doi : 10.17487/RFC1796 . RFC 1796 .Informativ.
  5. ^ „RFCs, Internet Request For Comments“ . Livinginternet.com . Abgerufen am 3. April 2012 .
  6. ^ a b „Stephen D. Crocker, How the Internet Got Its Rules , The New York Times, 6. April 2009“ . The New York Times . 7. April 2009. Abgerufen am 3. April 2012 .
  7. ^ „Bekanntmachung und Aufforderung zur Stellungnahme“ . Bundesanzeiger . 16. Januar 2018.
  8. ^ Hafner, Katie; Lyon, Matthew (1996). Where Wizards Stay Up Late: The Origins of the Internet . Ein Touchstone-Buch. Simon & Schuster. ISBN 978-0-684-81201-4Die
  9. ^ Metz, Cade (18. Mai 2012). „Lernen Sie den Mann kennen, der die Anleitung für das Internet erfunden hat“ . Wired . Abgerufen am 18. Dezember 2018 .
  10. ^ S. Crocker , Hrsg. (7. April 1969). Host-Software . Network Working Group. doi : 10.17487/RFC0001 . RFC 1 .Status unbekannt.
  11. ^ Elizabeth J. Feinler (Juli–September 2010). „Das Network Information Center und seine Archive“ . Annals of the History of Computing . 32 (3): 83–89 . doi : 10.1109/MAHC.2010.54 . S2CID 206443021 . 
  12. ^ V. Cerf (17. Oktober 1998). Ich erinnere mich an die IANA . Network Working Group. doi : 10.17487/RFC2468 . RFC 2468 .Informativ.
  13. ^ Leslie Daigle (März 2010). „RFC Editor in Transition: Past, Present, and Future“ . The Internet Protocol Journal . Band 13, Nr. 1. Cisco Systems. Archiviert vom Original am 20. September 2010. Abgerufen am 17. August 2011 .
  14. ^ L. Daigle (Hrsg.). (April 2007). Die RFC-Reihe und der RFC-Editor . Network Working Group. doi : 10.17487/RFC4844 . RFC 4844 .Veraltet. Ersetzt durch RFC  8729. Aktualisiert durch RFC  5741 .
  15. ^ O. Kolkman, Hrsg. (August 2009). RFC-Editor-Modell (Version 1) . Internet-Architektur-Board . doi : 10.17487/RFC5620 . RFC 5620 .Veraltet. Ersetzt durch RFC  6635 und 6548 .
  16. ^ O. Kolkman; J. Halpern, Hrsg. (Juni 2012). RFC Editor Model (Version 2) . Internet Architecture Board . doi : 10.17487/RFC6635 . RFC 6635 .Veraltet. Ersetzt durch RFC  8728. Ersetzt RFC  5620 .
  17. ^ O. Kolkman; J. Halpern; R. Hinden (Hrsg.). (Februar 2020). RFC Editor Model (Version 2) . Internet Architecture Board . doi : 10.17487/RFC8728 . RFC 8728 .Informationell. Durch RFC  9280 überholt . Ersetzt RFC  6635 .
  18. ^ a b A. Falk (Dezember 2009). RFC Streams, Headers, and Boilerplates . Internet Research Task Force . doi : 10.17487/RFC5741 . ISSN 2070-1721 . RFC 5741 . Veraltet. Ersetzt durch RFC  7841. Aktualisiert RFC  2223 , 4844 .
  19. ^ Glenn Kowack (7. Januar 2010). „Ankündigung des Übergangs der RFC-Redaktion“ . Archiviert vom Original am 29. Juni 2011.
  20. ^ „Der Herausgeber der RFC-Reihe und die Neuorganisation der Reihe“ . Archiviert vom Original am 5. April 2013. Abgerufen am 5. April 2013 .
  21. ^ „Alexis Rossi zum beratenden Redakteur der RFC-Reihe ernannt“ . 1. September 2022. Abgerufen am 19. August 2023 .
  22. ^ „FAQ zur Änderung des RFC-Formats“ . RFC Editor . 27. Januar 2021. Archiviert vom Original am 11. Mai 2026.
  23. ^ a b „RFC-Index“ . RFC Editor. 25. Mai 2008. Abgerufen am 26. Mai 2008 .
  24. ^ Richtlinien und Verfahren der IETF-Arbeitsgruppen . IETF . doi : 10.17487/RFC2418 . RFC 2418 .
  25. ^ Dieser Artikel basiert auf Material, das vor dem 1. November 2008 aus der Rubrik „Request for Comments“ des Free On-line Dictionary of Computing entnommen und unter den „Relicensing“-Bedingungen der GFDL , Version 1.3 oder später, übernommen wurde.
  26. ^ „Unabhängige Einreichungen“ . RFC-Redaktion . Abgerufen am 5. Januar 2018 .
  27. ^ Klensin, John; Thaler, David (Juli 2007). Unabhängige Einreichungen an den RFC-Editor . IAB . doi : 10.17487/RFC4846 . RFC 4846 .>
  28. ^ Alvestrand, Harald; Housley, Russ (Dezember 2009). IESG-Verfahren für die Bearbeitung unabhängiger und IRTF-Stream-Einreichungen . IETF . doi : 10.17487/RFC5742 . RFC 5742 .
  29. ^ „Sind alle RFCs Internetstandarddokumente?“ . RFC Editor . Abgerufen am 16. März 2018 .
  30. ^ Nottingham, Mark (31. Juli 2018). „Wie man einen RFC liest“ . Abgerufen am 18. September 2023. RFCs sind eine Archivreihe von Dokumenten; sie können nicht geändert werden.
  31. ^ Housley, Russell; Crocker, Dave; Burger, Eric (Oktober 2011). Reduzierung des Standards Track auf zwei Reifegrade . IETF . doi : 10.17487/RFC6410 . RFC 6410 .
  32. ^ Rücknahme des „Internet Official Protocol Standards“ Summary Document . IETF . doi : 10.17487/RFC7100 . RFC 7100 .
  33. ^ „7.5. Informationelle und experimentelle RFCs“ . The Tao of IETF . Abgerufen am 26. November 2017 .
  34. ^ Bradner, Scott O. (Oktober 1996). Der Internet-Standardisierungsprozess – Revision 3. IETF . BCP 9. Abgerufen am 25. Oktober 2017 .
  35. ^ „IESG-Erklärung zur Kennzeichnung von RFCs als historisch“ . IETF. 20. Juli 2014. Abgerufen am 14. April 2016 .
  36. ^ „IETF-Standards, verfasst von ISC-Mitwirkenden“ . Internet Systems Consortium . 10. September 2021. Archiviert vom Original am 5. April 2022. Abgerufen am 11. April 2022. Viele der frühen RFC-Dokumente haben den Status „unbekannt“, da sie aus der längst vergangenen Zeit stammen, als ein RFC tatsächlich nur eine Aufforderung zur Kommentierung war.
  37. ^ „Reproducing RFCs“ . IETF Trust . Abgerufen am 12. August 2021 .
  38. ^ Bradner, Scott; Contreras, Jorge (November 2008). Rechte, die Beitragende dem IETF Trust einräumen . IETF . doi : 10.17487/RFC5378 . RFC 5378 .
  39. ^ „Urheberrecht und IETF-Urheberrechtsrichtlinien“ . IETF Trust . Abgerufen am 13. August 2021 .