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.
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. 
Inhaltsverzeichnis
Wozu dient der RFC
ein RFC 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 Mailprogrammen immer wieder auf, sei es Thunderbird, K9Mail oder Evolution. Wenn ich jetzt ein neues Mail-Programm erstelle, kann ich mit dem entsprechenden RFC, es so schreiben, dass es mit allen Mailservern auf der Welt kompatibel ist. Daher ist ein RFC eine Vorgabe um mit allen im Netz kompatibel zu sein. 
Wer darf/soll einen RFC schreiben?
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, dass den Prozess definiert. 
Es ist nicht so leicht, wie es aussieht.
Alle RFC sind reine Textdokumente und in Englisch. Also erklärende Bilder, Diagramme, 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. 
Was habe ich davon?
Du hast einen wohldefiniertes Verhalten eines Programm/Netwerkes/Protokolles, das von jedem beachtet wird. Denn nur so funktioniert Internet. Eine Firma aus Redmond musste das bei einem Mailprogramm sehr schnell lernen. 
Nehmen wir z.B. „RFC 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, beschrieben in einem Feld 
Gleichzeitig setzt dieser eine RFC, 10 weitere RFC auf „obsulent“ und einen auf updated.  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  in Form einer  Eingabe, herumgeschlagen.  Jetzt stehen da neben GET und POST noch andere Befehle wie PUT, HEAD etc.  
Vielleicht ist das beim nächsten HTML-Projekt von Vorteil? (Oder  auch nur das DELETE zu sperren?)
Das glaube ich alles nicht?
Du willst es ausprobieren, ohne Programmierung? Dazu solltest du eine Apachestandard-Installation haben. Und du brauchst das gute alte telnet-Programm 
telnet localhost 80
du bekommst dann die Meldungen 
Trying ::1…
Connected to localhost.
Escape character is ‚^]‘.
GET /
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. 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 in Form eines „400 Bad Request“ bekommen. 
Und auch der Errorcode 400 ist im RFC  beschrieben. (Kapitel 15.1)
weitere Links
https://de.wikipedia.org/wiki/RFC-Editor
https://de.wikipedia.org/wiki/Request_for_Comments
https://www.rfc-editor.org/standards
Jon hat auch seinen eigenen persönlichen RFC (2368) bekommen. Hier ist der Nachruf auf ihn.
https://datatracker.ietf.org/doc/html/rfc2468
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.

            
            
Noch keine Reaktion