HTCPCP 418 – Ich bin eine Teekanne! =^_^=

Der durchschnittliche moderne Mensch benutzt sein Smartphone ungefähr 80 bis 90 Mal am Tag. Ja und Podcastfans, nehme ich mal an, sind überdurchschnittliche moderne Menschen. Du nimmst Dein Handy also öfter in die Hand und jedes Mal, wenn Du irgendwas mit Deinem Handy machst und auch während Du eigentlich nichts mit Deinem Handy machst und es allein vor sich hin tut, laufen in diesem Handy und irgendwo im weltweiten Internet Prozesse ab.

Zum Beispiel: Die Podcastapp, mit der Du das jetzt hier gerade anhörst, die hat wahrscheinlich diesen Podcast irgendwann mal heruntergeladen. Um das zu können musste diese App einen Server im Internet kontaktieren. Nachfragen, ob denn eine neue Datei vorliegt; selbige Datei anfordern. Diese Kommunikation zwischen dem Server und dem Endgerät – in dem Fall dem Handy – die folgt genau beschrieben in einzelnen Schritten, sogenannten Protokollen. Und diese Protokolle wachsen nicht auf den Bäumen, sondern auf die muss man sich einigen. Sonst würden die vielen verschiedenen Geräte da draußen nicht miteinander kommunizieren können.

Damit das klappt müssen schließlich Standards geschaffen werden – also, genaue Beschreibungen dieser Abläufe, an die sich dann auch alle halten können. Dafür müssen es erstmal alle einsehen können und es müssen alle eine Gelegenheit gehabt haben, sich einzubringen und diesen Standard mitzugestalten oder auch weiterzuentwickeln.

Derartige Protokolle gibt es viele. Das fängt beim eigentlichen Netzwerk an. Das sogenannte TCP IP Protokoll ist da das wichtigste, aber auch E-Mails verschicken, Dateien herunterladen, im Internet surfen. Die Protokolle, die Du dabei verwendest wurden alle irgendwann mal niedergeschrieben und zwar in sogenannten RFC Dokumenten.

RFC ist die Abkürzung von Request For Comments. Das beschreibt den Prozess eigentlich auch schon ganz gut, wie diese Standards entstehen. Im Prinzip ist es ein Diskussionsbeitrag. Es setzt sich jemand hin und schreibt einen Entwurf, einen Diskussionsbeitrag für ein Protokoll. Andere können diesen Entwurf überarbeiten und neue Versionen davon schreiben und nach und nach destillieren sich dann Standards heraus.

Jedes RFC Dokument folgt einem ganz bestimmten Schema und hat einen Status, an dem man ablesen kann, ob man es mit einem Standard- oder mit einem reinen Diskussionsbeitrag zu tun hat. RFCs veralten auch mal oder bauen aufeinander auf und deswegen bleiben die erhalten. Sie werden durchlaufend nummeriert und es gibt einige tauschende RFC Dokumente. Aber ein paar Dutzend davon steuern praktisch alles, was wir so im Alltag an Technik benutzen. Es geht einfach nichts mehr ohne Netzwerk und Kommunikation im Netzwerk.

Begonnen hat dieser Prozess der Diskussionen am 7. April 1969 mit dem allerersten RFC-Dokument. Geschrieben und verwaltet werden die RFCs von der Internet Engineering Task Force und der Internet Society und ich würde mal sagen: Beide sind auch ganz schöne Nerdhaufen und Ingenieursclubs. Das führt dazu, dass hin und wieder auch mal eine gehörige Portion Nerdkultur durchschlägt beim Schreiben der RFCs.

Deswegen gibt es auch RFCs, die eher weniger ernst gemeint sind. Insbesondere am 1. April veröffentlichte RFC Dokumente sind mit Vorsicht zu genießen. Auch wenn die manchmal so präzise und detailliert formuliert sind, dass man sie umsetzen kann. So wurde zum Beispiel am 1. April 1990 ein RFC veröffentlicht, das Internet über Brieftauben beschrieben hat. Also, Datenpakete, die über unsere geflügelten Freunde übertragen werden müssen. Da ist dann natürlich die Übertragungsrate nicht mehr so spektakulär. Aber dass wir es mit Nerds zu tun haben, die diese Aprilscherze schreiben, wird dann klar, wenn man die Vorschläge umsetzen kann. Und im Falle von IP over Carrier Pitchens wurde das getan.

Eine Linux Usergroup aus Norwegen hat sich den Spaß gegönnt und die komplette RFC implementiert und durchgetestet. Geht! Gut, ich würde jetzt darüber vielleicht nicht Netflix streamen und man braucht etwas mehr Zeit, um seinen Facebookstaturs zu aktualisieren. Witzig ist es trotzdem irgendwie.

Damit sind wir beim Themenanker für die heutige Folge. Es gibt nämlich eine ganze Reihe solch scherzhaft gemeinter RFCs. Traditionell meistens am 1. April veröffentlicht. Und da hat einer unserer Hörer auf Twitter unter @FryZeit zu erreichen vorgeschlagen, über das HTCPCP zu sprechen. Das Hyper Text Coffe Pot Controll Protocol. Das ist einer dieser Aprilscherz-RFCs, veröffentlicht am 1. April 1998 als RFC 2324. Und HTCPCP, das versuchen wir jetzt mal alle zusammen zu sagen: 1…2…H-T-C-P-C-P.

In diesem Protokoll jedenfalls geht es um die Steuerung einer Kaffeekanne oder in modernen Worten ausgedrückt: Um einen Kaffeevollautomaten mit Internetanbindung. Da merkt man auch, dass manches, was mal witzig und absurd klang – 1998 ist ja jetzt auch nicht so lange her – heute plötzlich völlig realistisch ist. In diesem Kaffeekannenprotokoll jedenfalls wird alles implementiert. Von der Anforderung von Kaffee über die Dosierung der Milch, dem Süßen des Kaffees, sogar die Beigabe von Alkohol war vorgesehen und zwar genau Whisky, Rum, Kahlua oder Aquavit. Aufgerufen sollte  das Protokoll mit coffee:// werden, so wie man Internetadressen mit http://aufruft.

Auch dieses Protokoll wurde von der Wirklichkeit eingeholt. Auf YouTube findet man mehrere Videos von Projekten, die einen solchen Kaffeeautomaten entwickelt haben. Wenn Du zum Beispiel in den Shownotes vorbeischaust, findest Du dort ein Video einer Studentengruppe, die in ein bisschen mehr als einer Minute ihr Hightech-Monster vorstellen – inklusive Sprachsteuerung und vollautomatischer Auswahl des richtigen Bechers usw.

Genauso wie beim http-Protokoll gibt es auch bei diesem Protokoll Fehlercodes und das ist der Themenanker der heutigen Sendung, denn Fehlercode 418 weist auf einen ganz besonders schweren Fehler beim Zugriff auf die Kaffeekanne hin. HTCPCP 418 weist nämlich auf einen Fehler hin, der wirklich schwerwiegende Folgen nach sich ziehen kann – nämlich: Die falsche Kanne zu verwenden. Und sollte Dir das passieren und ein sauber implementierter HTCPCP-Server vorliegen, dann bekommst Du als Meldung zurück: “Code 418 – I’m a teapot” – Ich bin eine Teekanne.

Bis bald.