{"id":20638,"date":"2025-11-03T20:06:15","date_gmt":"2025-11-03T19:06:15","guid":{"rendered":"https:\/\/linux-bibel.at\/?p=20638"},"modified":"2025-11-03T20:06:16","modified_gmt":"2025-11-03T19:06:16","slug":"rfc","status":"publish","type":"post","link":"https:\/\/linux-bibel.at\/index.php\/2025\/11\/03\/rfc\/","title":{"rendered":"RFC"},"content":{"rendered":"\n

Eine einfache und geniale Methode, Dinge, Protokolle in der IT-Welt zu definieren und für jedermann nutzbar zu machen. Ein netter und von mir geschätzter Diskussionspartner namens Jon Postel rufte dieses System in die Welt.<\/p>\n\n\n\n

Er sagte eine Definition kann überholt sein, aber sie bleibt immer noch bestehen. d.h. sie wird nur „veraltet“ und durch eine Neuere ersetzt. Wenn man das Auto als Beispiel heranzieht, dann hätte Herr Benz oder Herr Otto eine Beschreibung geschrieben, die im Prinzip immer noch gültig wäre. Aber durch Beschreibungen von 6, 8, oder 12 Zylinder erneuert wäre.
<\/p>\n\n\n\n

Wozu dient der RFC<\/h2>\n\n\n\n

ein RFC<\/a> beschreibt einen Vorgang, ein Protokoll oder auch nur ein Verfahren wie etwas abzuwickeln ist, damit jedermann es nutzen kann und seine eigen Lösung darauf aufbauen kann.
Um sich etwas darunter vorstellen zu können, wieder ein Beispiel: Das E-Mail! Beim Einrichten seid ihr sicher schon auf die Begriffe POP und IMAP gestoßen. Die tauchen in allen Mailprogram<\/a>men immer wieder auf, sei es Thunderbird, K9Mail oder Evolution. Wenn ich jetzt ein neues Mail-Program<\/a>m erstelle, kann ich mit dem entsprechenden RFC<\/a>, es so schreiben, dass es mit allen Mailserver<\/a>n auf der Welt kompatibel ist. Daher ist ein RFC<\/a> eine Vorgabe um mit allen im Netz kompatibel zu sein. <\/p>\n\n\n\n

Wer darf\/soll einen RFC schreiben?<\/h2>\n\n\n\n

Auch das ist leicht gesagt: Im Prinzip, jeder.
Man reicht diesen ein, es erfolgt eine Begutachtung. Wenn es ihn noch nicht gibt und er als gut empfunden wird, dann geht die Begutachtung los. Dazu sollte man sich klar sein „was“ man einreichen will. Für jeden Status gibt es einen eigenen RFC<\/a>, dass den Prozess definiert. <\/p>\n\n\n\n

Es ist nicht so leicht, wie es aussieht.<\/h2>\n\n\n\n

Alle RFC<\/a> sind reine Textdokumente und in Englisch. Also erklärende Bilder, Diagram<\/a>me, Schaltungen müssen beschrieben werden. Wenn man dann damit fertig ist, kann man es einreichen. Nach der anschließenden Begutachtung dürfen andere Mitglieder ihren Kommentar abgeben, Änderungen vorschlagen oder was auch immer. Das alles ist mit teilweise eng definierten Fristen verbunden.
Also braucht man auch einige Resourcen um hier mitzuspielen. Ich glaube nicht, dass eine einzelne Person es jemals geschafft hat einen solchen bis zum Ende zu bringen. <\/p>\n\n\n\n

Was habe ich davon?<\/h2>\n\n\n\n

Du hast einen wohldefiniertes Verhalten eines Program<\/a>m\/Netwerkes\/Protokolles, das von jedem beachtet wird. Denn nur so funktioniert Internet. Eine Firma aus Redmond musste das bei einem Mailprogram<\/a>m sehr schnell lernen.
Nehmen wir z.B. „RFC<\/a> 9110 HTTP Semantics“. Er beschreibt wie HTTP funktioniert unabhängig ob es über eine verschlüsselte oder unverschlüsselte Verbindung genutzt wird. Es ist auch egal. ob ein Bild, Text oder Zip transferiert wird. Diese 200 Seiten beschreiben nur diese eine Ebene. BILD, Text etc sind einfach Daten<\/a>, beschrieben in einem Feld <\/p>\n\n\n\n

Gleichzeitig setzt dieser eine RFC<\/a>, 10 weitere RFC<\/a> auf „obsulent“ und einen auf update<\/a>d. Ihr seht man muss ein bisschen was von HTTP verstehen um hier mitreden\/schreiben zu können.
Auf der anderen Seite: Wer auch immer einen HTML Seite erzeugt hat , der hat sich schon mit einem GET oder POST Befehl<\/a> in Form einer Eingabe, herumgeschlagen. Jetzt stehen da neben GET und POST noch andere Befehl<\/a>e wie PUT, HEAD etc.
Vielleicht ist das beim nächsten HTML-Projekt von Vorteil? (Oder auch nur das DELETE zu sperren?)<\/p>\n\n\n\n

Das glaube ich alles nicht?<\/h2>\n\n\n\n

Du willst es ausprobieren, ohne Program<\/a>mierung? Dazu solltest du eine Apachestandard-Installation haben. Und du brauchst das gute alte telnet-Program<\/a>m
<\/p>\n\n\n\n

telnet localhost 80<\/code><\/pre>\n\n\n\n
du bekommst dann die Meldungen 
Trying ::1…
Connected to localhost<\/a>.
Escape character is ‚^]‘.
<\/p>\n\n\n\n
GET \/<\/code><\/pre>\n\n\n\n

und dir wird die gesamte Default-HTML-Seite des Apachen ausgegeben.  Wenn du die beiden Aus- und Eingabe analysiert entsprechen sie genau den Vorgaben des RFC<\/a>. Also dürftest du mit deinem GET und der Apache mit seinem Response es richtig gemacht haben.  Du kannst ja statt get mal „JUHU \/“ ausprobieren. Du wirst eine Empörung vom Server<\/a> in Form eines „400 Bad Request“ bekommen. 
Und auch der Errorcode 400 ist im RFC<\/a>  beschrieben. (Kapitel 15.1)


<\/p>\n\n\n\n


weitere Links<\/h2>\n\n\n\n
https:\/\/de.wikipedia.org\/wiki\/RFC-Editor<\/a><\/p>\n\n\n\n
https:\/\/de.wikipedia.org\/wiki\/Request_for_Comments<\/a><\/p>\n\n\n\n
https:\/\/www.rfc-editor.org\/standards<\/a><\/p>\n\n\n\n
Jon hat auch seinen eigenen persönlichen RFC<\/a> (2368) bekommen. Hier ist der Nachruf  auf ihn.<\/p>\n\n\n\n
https:\/\/datatracker.ietf.org\/doc\/html\/rfc2468<\/a> <\/p>\n\n\n\n
<\/p>\n\n\n\n
Ich hoffe, euch mit diesen paar Zeilen, ein bisschen das Grusseln in der Thematik der Standard und Best Practice genommen habe. Gleichzeitig gebe ich euch ein Werkzeug in die Hand, wo man genau definieren kann, dass sich jemand nicht an die Standards hält. Ob man dann  die Aussage „It’s not an error, it’s a feature“ gelten lässt, steht auf einem anderen Blatt Papier.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n
\r\n    
\r\n    \r\n                            \"Gef\u00e4llt\r\n            <\/a>\r\n    2    <\/span>\r\n<\/div>
\r\n    \r\n                            \"Gef\u00e4llt\r\n            <\/a>\r\n    <\/span>\r\n<\/div><\/div>","protected":false},"excerpt":{"rendered":"
Eine einfache und geniale Methode, Dinge, Protokolle in der IT-Welt zu definieren und f\u00fcr jedermann nutzbar zu machen. Ein netter und von mir gesch\u00e4tzter Diskussionspartner namens Jon Postel rufte dieses System in die Welt. Er sagte eine Definition kann \u00fcberholt sein, aber sie bleibt immer noch bestehen. d.h. sie wird nur „veraltet“ und durch eine […]<\/p>\n","protected":false},"author":52,"featured_media":21074,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-20638","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-allgemein"],"_links":{"self":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/20638","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/users\/52"}],"replies":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/comments?post=20638"}],"version-history":[{"count":9,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/20638\/revisions"}],"predecessor-version":[{"id":21075,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/20638\/revisions\/21075"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/media\/21074"}],"wp:attachment":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/media?parent=20638"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/categories?post=20638"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/tags?post=20638"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}