Nicht angemeldeter Benutzer - Bearbeiten von Seiten ist nur als angemeldeter Benutzer möglich.
Request for Comments: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| [unmarkierte Version] | [unmarkierte Version] |
K (In Vorlage:QuelleWikipedia datum, oldid und oldid-lokal setzen) |
K (Interwikilinks anpassen) |
||
| Zeile 1: | Zeile 1: | ||
| − | Die '''{{lang|en|Request for Comments}}''' ('''{{lang|en|RFC}}'''; [[Englische Sprache|englisch]] für ''Bitte um Kommentare'') ist eine Reihe technischer und organisatorischer Dokumente des [[RFC-Editor]]s zum [[Internet]] (ursprünglich [[Arpanet]]), die am 7. April 1969 begonnen wurden. Bei der ersten Veröffentlichung noch im ursprünglichen Wortsinne zur Diskussion gestellt, behalten RFC auch dann ihren Namen, wenn sie sich durch allgemeine Akzeptanz und Gebrauch zum [[Internetstandard|Standard]] entwickelt haben. Hingegen wird die fortlaufende Zählung (Nummerierung) der RFCs weitergeführt und eine neue RFC-Nummer vergeben, wenn eine abschließend geänderte Version durch eine neue Version, gegebenenfalls auch zusammengefasst aus mehreren Vorläufern und mit mehreren Ergänzungen versehen zu einem neuen Dokument zusammengeführt, abgelöst wird. | + | Die '''{{lang|en|Request for Comments}}''' ('''{{lang|en|RFC}}'''; [[Wikipedia:Englische Sprache|englisch]] für ''Bitte um Kommentare'') ist eine Reihe technischer und organisatorischer Dokumente des [[Wikipedia:RFC-Editor|RFC-Editor]]s zum [[Wikipedia:Internet|Internet]] (ursprünglich [[Wikipedia:Arpanet|Arpanet]]), die am 7. April 1969 begonnen wurden. Bei der ersten Veröffentlichung noch im ursprünglichen Wortsinne zur Diskussion gestellt, behalten RFC auch dann ihren Namen, wenn sie sich durch allgemeine Akzeptanz und Gebrauch zum [[Wikipedia:Internetstandard|Standard]] entwickelt haben. Hingegen wird die fortlaufende Zählung (Nummerierung) der RFCs weitergeführt und eine neue RFC-Nummer vergeben, wenn eine abschließend geänderte Version durch eine neue Version, gegebenenfalls auch zusammengefasst aus mehreren Vorläufern und mit mehreren Ergänzungen versehen zu einem neuen Dokument zusammengeführt, abgelöst wird. |
== RFC-Status == | == RFC-Status == | ||
| Zeile 31: | Zeile 31: | ||
<div style="column-width:35em"> | <div style="column-width:35em"> | ||
* RFC 1 (erste RFC von Steve Crocker) | * RFC 1 (erste RFC von Steve Crocker) | ||
| − | * RFC 768 ([[User Datagram Protocol|UDP]]) | + | * RFC 768 ([[Wikipedia:User Datagram Protocol|UDP]]) |
| − | * RFC 791 ([[Internet Protocol|IP]]) | + | * RFC 791 ([[Wikipedia:Internet Protocol|IP]]) |
| − | * RFC 792 ([[Internet Control Message Protocol|ICMP]]) | + | * RFC 792 ([[Wikipedia:Internet Control Message Protocol|ICMP]]) |
| − | * RFC 793 ([[Transmission Control Protocol|TCP]]) | + | * RFC 793 ([[Wikipedia:Transmission Control Protocol|TCP]]) |
| − | * RFC 821 ([[Simple Mail Transfer Protocol|SMTP]]) | + | * RFC 821 ([[Wikipedia:Simple Mail Transfer Protocol|SMTP]]) |
| − | * RFC 822 ([[E-Mail]]-Format) | + | * RFC 822 ([[Wikipedia:E-Mail|E-Mail]]-Format) |
| − | * RFC 950 ([[Subnetting]]) | + | * RFC 950 ([[Wikipedia:Subnetting|Subnetting]]) |
| − | * RFC 959 ([[File Transfer Protocol|FTP]]) | + | * RFC 959 ([[Wikipedia:File Transfer Protocol|FTP]]) |
* RFC 1006 (ISO on TCP – ISO Transport Service on top of the TCP) | * RFC 1006 (ISO on TCP – ISO Transport Service on top of the TCP) | ||
| − | * RFC 1034 ([[Domain Name System|DNS]] – Concepts and Facilities) | + | * RFC 1034 ([[Wikipedia:Domain Name System|DNS]] – Concepts and Facilities) |
* RFC 1035 (DNS – Implementation and Specification) | * RFC 1035 (DNS – Implementation and Specification) | ||
| − | * RFC 1036 ([[Usenet]] – Standard for Interchange of USENET Messages) | + | * RFC 1036 ([[Wikipedia:Usenet|Usenet]] – Standard for Interchange of USENET Messages) |
* RFC 1087 (Ethics and the Internet) | * RFC 1087 (Ethics and the Internet) | ||
| − | * RFC 1094 ([[Network File System|NFS]] Version 2 Protocol Specification) | + | * RFC 1094 ([[Wikipedia:Network File System|NFS]] Version 2 Protocol Specification) |
| − | * RFC 1166 ([[IP-Adresse]]) | + | * RFC 1166 ([[Wikipedia:IP-Adresse|IP-Adresse]]) |
| − | * RFC 1321 ([[MD5]] Message-Digest Algorithm) durch [[RFC:6151|RFC 6151]] überarbeitet | + | * RFC 1321 ([[Wikipedia:MD5|MD5]] Message-Digest Algorithm) durch [[RFC:6151|RFC 6151]] überarbeitet |
| − | * RFC 1436 ([[Gopher]]) | + | * RFC 1436 ([[Wikipedia:Gopher|Gopher]]) |
| − | * RFC 1459 ([[Internet Relay Chat|IRC]]) | + | * RFC 1459 ([[Wikipedia:Internet Relay Chat|IRC]]) |
| − | * RFC 1661 ([[Point-to-Point Protocol|PPP]]) | + | * RFC 1661 ([[Wikipedia:Point-to-Point Protocol|PPP]]) |
* RFC 1700 (Assigned Numbers) | * RFC 1700 (Assigned Numbers) | ||
| − | * RFC 1738 ([[Uniform Resource Locator|URLs]]) | + | * RFC 1738 ([[Wikipedia:Uniform Resource Locator|URLs]]) |
| − | * RFC 1813 ([[Network File System|NFS]] Version 3 Protocol Specification) | + | * RFC 1813 ([[Wikipedia:Network File System|NFS]] Version 3 Protocol Specification) |
| − | * RFC 1939 ([[POP3]]) | + | * RFC 1939 ([[Wikipedia:POP3|POP3]]) |
| − | * RFC 1945 ([[Hypertext Transfer Protocol|HTTP]] 1.0) | + | * RFC 1945 ([[Wikipedia:Hypertext Transfer Protocol|HTTP]] 1.0) |
| − | * RFC 2131 ([[Dynamic Host Configuration Protocol|DHCP]]) | + | * RFC 2131 ([[Wikipedia:Dynamic Host Configuration Protocol|DHCP]]) |
| − | * RFC 2222 ([[SASL]]) | + | * RFC 2222 ([[Wikipedia:SASL|SASL]]) |
| − | * RFC 2440 ([[OpenPGP]]) | + | * RFC 2440 ([[Wikipedia:OpenPGP|OpenPGP]]) |
| − | * RFC 2460 ([[IPv6]]) | + | * RFC 2460 ([[Wikipedia:IPv6|IPv6]]) |
| − | * RFC 2606 (Zu Testzwecken reservierte [[Top-Level-Domain]]s) | + | * RFC 2606 (Zu Testzwecken reservierte [[Wikipedia:Top-Level-Domain|Top-Level-Domain]]s) |
* RFC 2613 ([[Remote Network Monitoring]]) | * RFC 2613 ([[Remote Network Monitoring]]) | ||
| − | * RFC 2616 ([[Hypertext Transfer Protocol|HTTP]] 1.1) veraltet | + | * RFC 2616 ([[Wikipedia:Hypertext Transfer Protocol|HTTP]] 1.1) veraltet |
| − | * RFC 2663 ([[Network Address Translation|NAT]]) | + | * RFC 2663 ([[Wikipedia:Network Address Translation|NAT]]) |
| − | * RFC 2821 ([[Simple Mail Transfer Protocol|SMTP]]) | + | * RFC 2821 ([[Wikipedia:Simple Mail Transfer Protocol|SMTP]]) |
| − | * RFC 2822 ([[E-Mail]]-Format) | + | * RFC 2822 ([[Wikipedia:E-Mail|E-Mail]]-Format) |
| − | * RFC 3174 ([[Secure Hash Algorithm|SHA]]) | + | * RFC 3174 ([[Wikipedia:Secure Hash Algorithm|SHA]]) |
| − | * RFC 3261 ([[Session Initiation Protocol|SIP]]) | + | * RFC 3261 ([[Wikipedia:Session Initiation Protocol|SIP]]) |
| − | * RFC 3501 ([[Internet Message Access Protocol|IMAP]] Version 4 Protocol Specification) | + | * RFC 3501 ([[Wikipedia:Internet Message Access Protocol|IMAP]] Version 4 Protocol Specification) |
| − | * RFC 3530 ([[Network File System|NFS]] Version 4 Protocol Specification) | + | * RFC 3530 ([[Wikipedia:Network File System|NFS]] Version 4 Protocol Specification) |
| − | * RFC 3920 ([[XMPP]] Core, sowie in RFC 3921 IM & Presence) | + | * RFC 3920 ([[Wikipedia:XMPP|XMPP]] Core, sowie in RFC 3921 IM & Presence) |
| − | * RFC 3986 ([[Uniform Resource Identifier|URIs]]) | + | * RFC 3986 ([[Wikipedia:Uniform Resource Identifier|URIs]]) |
| − | * RFC 4122 (UUID, [[Universally Unique Identifier|Universally Unique IDentifier]]) | + | * RFC 4122 (UUID, [[Wikipedia:Universally Unique Identifier|Universally Unique IDentifier]]) |
| − | * RFC 4511 ([[Lightweight Directory Access Protocol|LDAP]]) | + | * RFC 4511 ([[Wikipedia:Lightweight Directory Access Protocol|LDAP]]) |
| − | * RFC 4870 ([[DomainKeys]]) | + | * RFC 4870 ([[Wikipedia:DomainKeys|DomainKeys]]) |
| − | * RFC 5545 ([[iCalendar]]) | + | * RFC 5545 ([[Wikipedia:iCalendar|iCalendar]]) |
| − | * RFC 7230 ([[Hypertext Transfer Protocol|HTTP]] 1.1) | + | * RFC 7230 ([[Wikipedia:Hypertext Transfer Protocol|HTTP]] 1.1) |
</div> | </div> | ||
== Spezielle Dokumententypen bei den RFC == | == Spezielle Dokumententypen bei den RFC == | ||
| − | Einige RFCs sind zugleich ''[[Internetstandard|Internet Standard]] (STD)'', ''For Your Information (FYI)'', ''[[Best Current Practice]] (BCP)'' oder ''[[Reseaux Associes pour la Recherche Europeenne|RARE]] Technical Report (RTR)'' jeweils mit eigener Zählung. | + | Einige RFCs sind zugleich ''[[Wikipedia:Internetstandard|Internet Standard]] (STD)'', ''For Your Information (FYI)'', ''[[Wikipedia:Best Current Practice|Best Current Practice]] (BCP)'' oder ''[[Reseaux Associes pour la Recherche Europeenne|RARE]] Technical Report (RTR)'' jeweils mit eigener Zählung. |
Vereinzelt kommen auch Antworten auf allgemeine Fragen oder Nachrufe vor. | Vereinzelt kommen auch Antworten auf allgemeine Fragen oder Nachrufe vor. | ||
| Zeile 93: | Zeile 93: | ||
| | | | ||
* RFC 2119 = BCP 14 ''Key words for use in RFCs to Indicate Requirement Levels'' | * RFC 2119 = BCP 14 ''Key words for use in RFCs to Indicate Requirement Levels'' | ||
| − | * RFC 2468 ''I REMEMBER IANA'', ein Nachruf von [[Vinton Cerf]] für [[Jon Postel]] | + | * RFC 2468 ''I REMEMBER IANA'', ein Nachruf von [[Wikipedia:Vinton Cerf|Vinton Cerf]] für [[Wikipedia:Jon Postel|Jon Postel]] |
* RFC 5000 = STD 1 ''Internet Official Protocol Standards'', ein Überblick über die wichtigsten Internet Protokolle | * RFC 5000 = STD 1 ''Internet Official Protocol Standards'', ein Überblick über die wichtigsten Internet Protokolle | ||
|} | |} | ||
| Zeile 105: | Zeile 105: | ||
* Wie man RFCs schreibt, ist in RFC 7322 festgelegt. | * Wie man RFCs schreibt, ist in RFC 7322 festgelegt. | ||
* In RFC 2119 ist beschrieben, welche Bedeutung bestimmte Begriffe haben. Selbst Begriffe wie ''MUST'' oder ''MUST NOT'' werden in ihrer Bedeutung klar definiert, um Verwirrung in deren Interpretation zu vermeiden. | * In RFC 2119 ist beschrieben, welche Bedeutung bestimmte Begriffe haben. Selbst Begriffe wie ''MUST'' oder ''MUST NOT'' werden in ihrer Bedeutung klar definiert, um Verwirrung in deren Interpretation zu vermeiden. | ||
| − | * 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. | + | * Zeichenketten und ihre Zusammensetzung werden formalistisch mittels der [[Wikipedia:Backus-Naur-Form|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. | 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. | ||
| Zeile 111: | Zeile 111: | ||
== Humor in RFC == | == Humor in RFC == | ||
| − | Zwischen den offiziellen RFCs, die [[De-facto-Standard|Quasi-Standards]] oder „[[Best Current Practice]]s“ (derzeit beste Vorgehensweisen) beschreiben, finden sich aber auch immer RFCs, die nicht buchstabengetreu genommen werden sollten, oft aus Anlass des [[1. April]]. | + | Zwischen den offiziellen RFCs, die [[Wikipedia:De-facto-Standard|Quasi-Standards]] oder „[[Wikipedia:Best Current Practice|Best Current Practice]]s“ (derzeit beste Vorgehensweisen) beschreiben, finden sich aber auch immer RFCs, die nicht buchstabengetreu genommen werden sollten, oft aus Anlass des [[Wikipedia:1. April|1. April]]. |
* Das am 1. April 1996 veröffentlichte RFC 1925 listet ''The Twelve Networking Truths'' auf, die mit dem fundamentalen Grundsatz ''It Has To Work'' beginnen. | * Das am 1. April 1996 veröffentlichte RFC 1925 listet ''The Twelve Networking Truths'' auf, die mit dem fundamentalen Grundsatz ''It Has To Work'' beginnen. | ||
| − | * Als Parodie auf das Routing-Protokoll [[Multiprotocol Label Switching|MPLS]] findet sich in RFC 3251 das ''Mostly Pointless Lamp Switching''. | + | * Als Parodie auf das Routing-Protokoll [[Wikipedia:Multiprotocol Label Switching|MPLS]] findet sich in RFC 3251 das ''Mostly Pointless Lamp Switching''. |
| − | * RFC 2795 beschäftigt sich mit dem [[Infinite-Monkey-Theorem]] und beschreibt, wie eine unendliche Anzahl von Affen koordiniert werden kann, die die Werke von Shakespeare produzieren sollen. | + | * RFC 2795 beschäftigt sich mit dem [[Wikipedia:Infinite-Monkey-Theorem|Infinite-Monkey-Theorem]] und beschreibt, wie eine unendliche Anzahl von Affen koordiniert werden kann, die die Werke von Shakespeare produzieren sollen. |
| − | * Aber auch echte Kunstwerke lassen sich ausmachen, so zum Beispiel eine Lobeshymne auf das [[Arpanet]] (RFC 527), Wissenschaftsgeschichte in Versform (RFC 1121) oder ''[[The Twelve Days of Christmas]]'' aus der Sicht eines gestressten Netzwerk-[[Administrator (Rolle)|Admins]] (RFC 1882). | + | * Aber auch echte Kunstwerke lassen sich ausmachen, so zum Beispiel eine Lobeshymne auf das [[Wikipedia:Arpanet|Arpanet]] (RFC 527), Wissenschaftsgeschichte in Versform (RFC 1121) oder ''[[Wikipedia:The Twelve Days of Christmas|The Twelve Days of Christmas]]'' aus der Sicht eines gestressten Netzwerk-[[Wikipedia:Administrator (Rolle)|Admins]] (RFC 1882). |
| − | * Am 1. April 2001 wurden im RFC 3092 die Kombinationen von [[Metasyntaktische Variable|„foo“ und „bar“ bzw. deren Abarten]] [[Etymologie|etymologisch]] bestimmt. | + | * Am 1. April 2001 wurden im RFC 3092 die Kombinationen von [[Wikipedia:Metasyntaktische Variable|„foo“ und „bar“ bzw. deren Abarten]] [[Wikipedia:Etymologie|etymologisch]] bestimmt. |
| − | * Am 1. April 2003 wurde ein RFC (RFC 3514) veröffentlicht, das dazu aufruft, bei [[Internet Protocol|IP-Paketen]], die in irgendeiner Form „evil“ (böse) sind, ein entsprechendes Bit im Header zu setzen, um diese Pakete an [[Firewall]]s leichter ausfiltern zu können. Dies rührt daher, dass in IPv4 -Headern ein Bit, das den „Type of Service“ angibt, normalerweise mit 0 gesetzt ist, von einigen modernen Anwendungen jedoch mit 1 gesetzt wird. Einige Firewalls verlassen sich darauf, dass dieses 0 ist, und stufen das Paket eben als böse ein, da es einen nicht-unterstützten Service-Typ darstellt. | + | * Am 1. April 2003 wurde ein RFC (RFC 3514) veröffentlicht, das dazu aufruft, bei [[Wikipedia:Internet Protocol|IP-Paketen]], die in irgendeiner Form „evil“ (böse) sind, ein entsprechendes Bit im Header zu setzen, um diese Pakete an [[Wikipedia:Firewall|Firewall]]s leichter ausfiltern zu können. Dies rührt daher, dass in IPv4 -Headern ein Bit, das den „Type of Service“ angibt, normalerweise mit 0 gesetzt ist, von einigen modernen Anwendungen jedoch mit 1 gesetzt wird. Einige Firewalls verlassen sich darauf, dass dieses 0 ist, und stufen das Paket eben als böse ein, da es einen nicht-unterstützten Service-Typ darstellt. |
* Am 1. April 2004 wurde ein Allwissenheitsprotokoll entwickelt, das es der amerikanischen Regierung ermöglichen sollte, alle Formen der Computerkriminalität zu erkennen und zu verhindern (RFC 3751). Nachdem sich die Anforderungen an dieses Protokoll als nicht durchführbar erwiesen hatten, endet der Text mit den Worten: „Good luck.“ | * Am 1. April 2004 wurde ein Allwissenheitsprotokoll entwickelt, das es der amerikanischen Regierung ermöglichen sollte, alle Formen der Computerkriminalität zu erkennen und zu verhindern (RFC 3751). Nachdem sich die Anforderungen an dieses Protokoll als nicht durchführbar erwiesen hatten, endet der Text mit den Worten: „Good luck.“ | ||
| − | * Am 1. April 2005 wurde ein neuer Standard vorgestellt, welcher [[moral]]isch einwandfreies [[Routing]] ermöglicht (RFC 4041). Des Weiteren wurde das schon sehr in die Jahre gekommene [[UTF-8]], das [[8-Bit-Architektur|8 Bit breite Einheiten]] verwendet, durch UTF-9 ersetzt, das 9 [[Bit]]s (3 × 3) pro [[Byte]] erlaubt (RFC 4042). | + | * Am 1. April 2005 wurde ein neuer Standard vorgestellt, welcher [[Wikipedia:moral|moral]]isch einwandfreies [[Wikipedia:Routing|Routing]] ermöglicht (RFC 4041). Des Weiteren wurde das schon sehr in die Jahre gekommene [[Wikipedia:UTF-8|UTF-8]], das [[Wikipedia:8-Bit-Architektur|8 Bit breite Einheiten]] verwendet, durch UTF-9 ersetzt, das 9 [[Wikipedia:Bit|Bit]]s (3 × 3) pro [[Wikipedia:Byte|Byte]] erlaubt (RFC 4042). |
| − | * Am 1. April 2007 wurde eine Methode für die Übertragung von IP über das [[Winkeralphabet]] vorgestellt (RFC 4824). | + | * Am 1. April 2007 wurde eine Methode für die Übertragung von IP über das [[Wikipedia:Winkeralphabet|Winkeralphabet]] vorgestellt (RFC 4824). |
| − | * Am 1. April 2010 wurde das [[Transmission Control Protocol]] erweitert: Die Laune des übertragenen Segments kann durch [[Emoticon]]s im [[Header]] festgelegt werden. So kann ein Segment beispielsweise fröhlich oder frustriert sein (RFC 5841). | + | * Am 1. April 2010 wurde das [[Wikipedia:Transmission Control Protocol|Transmission Control Protocol]] erweitert: Die Laune des übertragenen Segments kann durch [[Wikipedia:Emoticon|Emoticon]]s im [[Wikipedia:Header|Header]] festgelegt werden. So kann ein Segment beispielsweise fröhlich oder frustriert sein (RFC 5841). |
=== Realisierte Aprilscherze === | === Realisierte Aprilscherze === | ||
Nicht immer jedoch bleibt es bei RFC zum 1. April bei der Theorie. | Nicht immer jedoch bleibt es bei RFC zum 1. April bei der Theorie. | ||
| − | So wurde am 6. März 2001 eine Implementierung des RFC 1149 ''A Standard for the [[Internet Protocol over Avian Carriers|Transmission of IP Datagrams on Avian Carriers]]'' (die Übertragung von IP-Datagrammen per [[Brieftaube]]) vorgestellt. Die durchschnittliche [[Antwortzeit]] eines [[Ping (Datenübertragung)|Pings]] betrug jedoch 45 Minuten, so dass nicht mit einer regelmäßigen Nutzung im Echteinsatz zu rechnen sein wird. Allerdings führte dies zu einer Weiterentwicklung RFC 2549 ''IP over Avian Carriers with [[Quality of Service]]'', aber auch dieser Einsatz ist unwahrscheinlich. | + | So wurde am 6. März 2001 eine Implementierung des RFC 1149 ''A Standard for the [[Wikipedia:Internet Protocol over Avian Carriers|Transmission of IP Datagrams on Avian Carriers]]'' (die Übertragung von IP-Datagrammen per [[Wikipedia:Brieftaube|Brieftaube]]) vorgestellt. Die durchschnittliche [[Wikipedia:Antwortzeit|Antwortzeit]] eines [[Wikipedia:Ping (Datenübertragung)|Pings]] betrug jedoch 45 Minuten, so dass nicht mit einer regelmäßigen Nutzung im Echteinsatz zu rechnen sein wird. Allerdings führte dies zu einer Weiterentwicklung RFC 2549 ''IP over Avian Carriers with [[Wikipedia:Quality of Service|Quality of Service]]'', aber auch dieser Einsatz ist unwahrscheinlich. |
| − | Der Editor [[Emacs]] enthält schon seit Jahren eine vollständige Implementierung von RFC 2324: Das [[Hyper Text Coffee Pot Control Protocol]] (HTCPCP) dient der Fernsteuerung und -überwachung von Kaffeemaschinen. | + | Der Editor [[Wikipedia:Emacs|Emacs]] enthält schon seit Jahren eine vollständige Implementierung von RFC 2324: Das [[Wikipedia:Hyper Text Coffee Pot Control Protocol|Hyper Text Coffee Pot Control Protocol]] (HTCPCP) dient der Fernsteuerung und -überwachung von Kaffeemaschinen. |
| − | Auf der Veranstaltung [[What The Hack|Hacking in Progress]] wurde RFC 2322, ''Management of IP numbers by [[Peg DHCP]]'', formuliert. Es definiert, wie IP-Nummern mit einem Filzstift auf Holzwäscheklammern geschrieben und diese an das zugehörige Kabel geklammert werden. Obwohl dieser RFC als Scherz gedacht war, wird das Verfahren regelmäßig eingesetzt. | + | Auf der Veranstaltung [[Wikipedia:What The Hack|Hacking in Progress]] wurde RFC 2322, ''Management of IP numbers by [[Wikipedia:Peg DHCP|Peg DHCP]]'', formuliert. Es definiert, wie IP-Nummern mit einem Filzstift auf Holzwäscheklammern geschrieben und diese an das zugehörige Kabel geklammert werden. Obwohl dieser RFC als Scherz gedacht war, wird das Verfahren regelmäßig eingesetzt. |
| − | Auch für das [[Pi Digit Generation Protocol]] gibt es mit ''gpigen'' eine freie Implementierung für mehrere Plattformen. | + | Auch für das [[Wikipedia:Pi Digit Generation Protocol|Pi Digit Generation Protocol]] gibt es mit ''gpigen'' eine freie Implementierung für mehrere Plattformen. |
== Siehe auch == | == Siehe auch == | ||
Aktuelle Version vom 21. September 2021, 23:37 Uhr
Die Request for Comments (RFC; englisch für Bitte um Kommentare) ist eine Reihe technischer und organisatorischer Dokumente des RFC-Editors zum Internet (ursprünglich Arpanet), die am 7. April 1969 begonnen wurden. Bei der ersten Veröffentlichung noch im ursprünglichen Wortsinne zur Diskussion gestellt, behalten RFC auch dann ihren Namen, wenn sie sich durch allgemeine Akzeptanz und Gebrauch zum Standard entwickelt haben. Hingegen wird die fortlaufende Zählung (Nummerierung) der RFCs weitergeführt und eine neue RFC-Nummer vergeben, wenn eine abschließend geänderte Version durch eine neue Version, gegebenenfalls auch zusammengefasst aus mehreren Vorläufern und mit mehreren Ergänzungen versehen zu einem neuen Dokument zusammengeführt, abgelöst wird.
RFC-Status
Jeder RFC besitzt einen Status für die Gültigkeit. Hier einige Beispiele:
Informational
- Hinweis, Idee, Nutzung, Mitteilung an die Netzgemeinde
Experimental
- zum Experimentieren, Anfangsstadium eines potenziellen Standards
Proposed Standard
- Vorschlag für Standard
Draft Standard
- Begutachtung von mindestens zwei unabhängigen Implementierungen
Standard
- offizieller Standard STD n
Historic
- nicht mehr benutzt
Hinweise:
Required
- Status ist zwingend anzuwenden
Recommended/Suggested
- Anwendung wird empfohlen
Elective
- Anwendung des Status ist freigestellt
Wichtige RFCs
- RFC 1 (erste RFC von Steve Crocker)
- RFC 768 (UDP)
- RFC 791 (IP)
- RFC 792 (ICMP)
- RFC 793 (TCP)
- RFC 821 (SMTP)
- RFC 822 (E-Mail-Format)
- RFC 950 (Subnetting)
- RFC 959 (FTP)
- RFC 1006 (ISO on TCP – ISO Transport Service on top of the TCP)
- RFC 1034 (DNS – Concepts and Facilities)
- RFC 1035 (DNS – Implementation and Specification)
- RFC 1036 (Usenet – Standard for Interchange of USENET Messages)
- RFC 1087 (Ethics and the Internet)
- RFC 1094 (NFS Version 2 Protocol Specification)
- RFC 1166 (IP-Adresse)
- RFC 1321 (MD5 Message-Digest Algorithm) durch RFC 6151 überarbeitet
- RFC 1436 (Gopher)
- RFC 1459 (IRC)
- RFC 1661 (PPP)
- RFC 1700 (Assigned Numbers)
- RFC 1738 (URLs)
- RFC 1813 (NFS Version 3 Protocol Specification)
- RFC 1939 (POP3)
- RFC 1945 (HTTP 1.0)
- RFC 2131 (DHCP)
- RFC 2222 (SASL)
- RFC 2440 (OpenPGP)
- RFC 2460 (IPv6)
- RFC 2606 (Zu Testzwecken reservierte Top-Level-Domains)
- RFC 2613 (Remote Network Monitoring)
- RFC 2616 (HTTP 1.1) veraltet
- RFC 2663 (NAT)
- RFC 2821 (SMTP)
- RFC 2822 (E-Mail-Format)
- RFC 3174 (SHA)
- RFC 3261 (SIP)
- RFC 3501 (IMAP Version 4 Protocol Specification)
- RFC 3530 (NFS Version 4 Protocol Specification)
- RFC 3920 (XMPP Core, sowie in RFC 3921 IM & Presence)
- RFC 3986 (URIs)
- RFC 4122 (UUID, Universally Unique IDentifier)
- RFC 4511 (LDAP)
- RFC 4870 (DomainKeys)
- RFC 5545 (iCalendar)
- RFC 7230 (HTTP 1.1)
Spezielle Dokumententypen bei den RFC
Einige RFCs sind zugleich Internet Standard (STD), For Your Information (FYI), Best Current Practice (BCP) oder RARE Technical Report (RTR) jeweils mit eigener Zählung. Vereinzelt kommen auch Antworten auf allgemeine Fragen oder Nachrufe vor.
Die Kategorie FYI wurde 1990 eingeführt und richtet sich an ein breites Publikum, das ausdrücklich auch Anfänger umfasst.[1]
Die Kategorie BCP wurde 1995 für RFC eingeführt, die kein Internetstandard werden können, aber relevant sind.[2]
|
|
Erfolg durch Formalismus
RFCs sind extrem formalistisch gestaltet:
- 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.
- Wie man RFCs schreibt, ist in RFC 7322 festgelegt.
- In RFC 2119 ist beschrieben, welche Bedeutung bestimmte Begriffe haben. Selbst Begriffe wie MUST oder MUST NOT werden in ihrer Bedeutung klar definiert, um Verwirrung in deren Interpretation zu vermeiden.
- 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.
Humor in RFC
Zwischen den offiziellen RFCs, die Quasi-Standards oder „Best Current Practices“ (derzeit beste Vorgehensweisen) beschreiben, finden sich aber auch immer RFCs, die nicht buchstabengetreu genommen werden sollten, oft aus Anlass des 1. April.
- Das am 1. April 1996 veröffentlichte RFC 1925 listet The Twelve Networking Truths auf, die mit dem fundamentalen Grundsatz It Has To Work beginnen.
- Als Parodie auf das Routing-Protokoll MPLS findet sich in RFC 3251 das Mostly Pointless Lamp Switching.
- RFC 2795 beschäftigt sich mit dem Infinite-Monkey-Theorem und beschreibt, wie eine unendliche Anzahl von Affen koordiniert werden kann, die die Werke von Shakespeare produzieren sollen.
- Aber auch echte Kunstwerke lassen sich ausmachen, so zum Beispiel eine Lobeshymne auf das Arpanet (RFC 527), Wissenschaftsgeschichte in Versform (RFC 1121) oder The Twelve Days of Christmas aus der Sicht eines gestressten Netzwerk-Admins (RFC 1882).
- Am 1. April 2001 wurden im RFC 3092 die Kombinationen von „foo“ und „bar“ bzw. deren Abarten etymologisch bestimmt.
- Am 1. April 2003 wurde ein RFC (RFC 3514) veröffentlicht, das dazu aufruft, bei IP-Paketen, die in irgendeiner Form „evil“ (böse) sind, ein entsprechendes Bit im Header zu setzen, um diese Pakete an Firewalls leichter ausfiltern zu können. Dies rührt daher, dass in IPv4 -Headern ein Bit, das den „Type of Service“ angibt, normalerweise mit 0 gesetzt ist, von einigen modernen Anwendungen jedoch mit 1 gesetzt wird. Einige Firewalls verlassen sich darauf, dass dieses 0 ist, und stufen das Paket eben als böse ein, da es einen nicht-unterstützten Service-Typ darstellt.
- Am 1. April 2004 wurde ein Allwissenheitsprotokoll entwickelt, das es der amerikanischen Regierung ermöglichen sollte, alle Formen der Computerkriminalität zu erkennen und zu verhindern (RFC 3751). Nachdem sich die Anforderungen an dieses Protokoll als nicht durchführbar erwiesen hatten, endet der Text mit den Worten: „Good luck.“
- Am 1. April 2005 wurde ein neuer Standard vorgestellt, welcher moralisch einwandfreies Routing ermöglicht (RFC 4041). Des Weiteren wurde das schon sehr in die Jahre gekommene UTF-8, das 8 Bit breite Einheiten verwendet, durch UTF-9 ersetzt, das 9 Bits (3 × 3) pro Byte erlaubt (RFC 4042).
- Am 1. April 2007 wurde eine Methode für die Übertragung von IP über das Winkeralphabet vorgestellt (RFC 4824).
- Am 1. April 2010 wurde das Transmission Control Protocol erweitert: Die Laune des übertragenen Segments kann durch Emoticons im Header festgelegt werden. So kann ein Segment beispielsweise fröhlich oder frustriert sein (RFC 5841).
Realisierte Aprilscherze
Nicht immer jedoch bleibt es bei RFC zum 1. April bei der Theorie. So wurde am 6. März 2001 eine Implementierung des RFC 1149 A Standard for the Transmission of IP Datagrams on Avian Carriers (die Übertragung von IP-Datagrammen per Brieftaube) vorgestellt. Die durchschnittliche Antwortzeit eines Pings betrug jedoch 45 Minuten, so dass nicht mit einer regelmäßigen Nutzung im Echteinsatz zu rechnen sein wird. Allerdings führte dies zu einer Weiterentwicklung RFC 2549 IP over Avian Carriers with Quality of Service, aber auch dieser Einsatz ist unwahrscheinlich.
Der Editor Emacs enthält schon seit Jahren eine vollständige Implementierung von RFC 2324: Das Hyper Text Coffee Pot Control Protocol (HTCPCP) dient der Fernsteuerung und -überwachung von Kaffeemaschinen.
Auf der Veranstaltung Hacking in Progress wurde RFC 2322, Management of IP numbers by Peg DHCP, formuliert. Es definiert, wie IP-Nummern mit einem Filzstift auf Holzwäscheklammern geschrieben und diese an das zugehörige Kabel geklammert werden. Obwohl dieser RFC als Scherz gedacht war, wird das Verfahren regelmäßig eingesetzt.
Auch für das Pi Digit Generation Protocol gibt es mit gpigen eine freie Implementierung für mehrere Plattformen.
Siehe auch
- Kategorie:Request for Comments - Artikel in der deutschen Wikipedia
- Request for Comments - Artikel in der deutschen Wikipedia
- Netzwerk - Artikel in der deutschen Wikipedia
- Netzwerkprotokoll - Artikel in der deutschen Wikipedia
- OSI-Schichtenmodell - Artikel in der deutschen Wikipedia
Weblinks
- Hinweise für Autoren von RFCs (englisch, Instructions to RFC Authors)
- Schlüsselworte zur Verwendung in RFCs (englisch, Key words for use in RFCs to Indicate Requirement Levels)
- Offizielle Website (englisch)
- Auflistung der FYI-Dokumente (englisch)
- RFC, FYI, STD und BCP in Formaten .html, .txt, .ps mit verschiedenen Indizes (Memento vom 11. Oktober 2008 im Internet Archive) (englisch)
- Internet FAQ Archives (englisch)
Einzelnachweise
Dieser Artikel basiert (teilweise) auf dem Artikel Request for Comments aus der freien Enzyklopädie Wikipedia in der Fassung 194223185 vom 14. November 2019 und steht unter der GNU Lizenz für freie Dokumentation und der Creative Commons Attribution/Share Alike. Auf Wikipedia ist eine Liste der Autoren verfügbar. Veränderungen seither in Imedwiki. Veränderungen seither in Wikipedia.Weiteres zum Import aus Wikipedia siehe Seite Imedwiki:Import aus Wikipedia.