 Ich bin der Leider, grüße euch. Ich spreche wienerisch, falls es unverständlich sein sollte, bitte irgendwie bemerkbar machen. Ich fixe das Ganze. Wie man meinen Namen schreibt, kann ich euch jetzt leider nicht zeigen, weil mein Display mich nicht mag. Warum auch immer? Ich muss einfach warten, wahrscheinlich, ja. Ja, aber die Maus geht, aber das war es dann auch schon. Ich weiß nicht, warum momentan. Ich kann nichts ändern. Ich gebe mir einfach noch eine Minute. Ich möchte über Standards sprechen. Das wird jetzt also kein großartig technischer Talk. Den Slapstick-Teil haben wir jetzt schon hinter uns. Es ist einfach so ein bisschen Geschichte aus dem, was ich so in meiner Praxis erlebe und welche Standards man sich eigentlich anschauen sollte. Eigentlich sollte ich jetzt da einen XKCD haben. Einmal gebe ich ihm noch. Der eben so sagt, Standards sind ja so ein Ding. Entweder ich habe einen Standard, der mir passt. Wenn ich keinen Standard habe, dann versuche ich mir einen. Wenn ich keinen Standard finde, den ich möchte, dann mache ich mir einfach einen neuen Standard. Standards gibt es wie Sand am Meer. Kann man immer wieder den nehmen, den man braucht oder sich einen neuen machen. Standards sind mühsam, Standards sind lästig. Ebenso wie bei Videobiemmern, die dann nicht wollen. Standards sind aber auch sehr praktisch. Denkt man mal zurück in ein paar Tausend Jahre. Wenn ich mich mit Ock zum Mammutjagen verabreden möchte, braucht man einen gemeinsamen Standard A für die Sprache und B auch für wann wir uns treffen wollen. Klassischer Standard wäre dann eben zu sagen, wir treffen uns bei Sonnenaufgang, weil das ist für uns jetzt in unserer Lokalität, in unserer Höhle, in unserem Tribe ausreichend genau. Jetzt wissen wir alle, die Dr. Hu gesehen haben. Und das mit der Zeit, das ist eher so Timy, Weimie, Wibbley, Wobbley. Es ist ja eher ein dynamisches Ding. Und wenn ich jetzt meine Slides hätte, könnte ich jetzt auch die ganzen Texte dazu noch artikulieren. Dann probieren wir das gleich wieder mit dem Login. Gehen wir ihm noch eine Sekunde. Wir brauchen aber dann in dem Moment, wo wir aus unserem lokalen Tribe, aus unserer lokalen Gruppe, aus unserer Dorfgemeinschaft rausgehen, brauchen wir eigentlich mehr. Da brauchen wir eigentlich einen übergreifenden Standard. Und das erste, wo wir so technologisch dann mit diesem Standard gelandet sind, oder den etablieren konnten, war dann so 18 irgendwas, wo dann eben die Zugsverbindungen, für die Zugsverbindungen ein regionsübergreifendes Zeitmanagement notwendig war. Und dann eben unter anderem die Deutsche Reichsbahn eben eine gemeinsame Zeitzone, die die Mitteleuropäische Sommerzeit für den Fahrplan eingeführt hat. War aber so, dass zwar der Fahrplan dann in der Zeitzone für alle war, das heißt, die Zeiten waren eindeutig für den Fahrplan, waren aber nicht eindeutig für die Lokalzeit, weil die einzelnen Gemeinden hatten noch immer ihre Lokalzeit bzw. gingen nach der Lokalzeit ihre Hauptstadt. Das war halt doch immer um eine halbe Stunde, Stunde irgendwo verschoben und die Fahrpläne mussten umgerechnet werden. Also schon ein leichter Fortschritt, aber noch nicht ganz so, wie man es gerne hätte. Und jetzt habe ich dann langsam... Jetzt bin ich noch überlegen, soll ich es jetzt noch einmal probieren oder soll ich einfach im... Da habe ich keine Speaker nutzen, weiß ich ja nicht mehr, was ich sagen wollte. Nein, ich habe keine Ahnung, was ich da red. Chicken. Huda! So, einschalten. Hallo, Computer. Wie gesagt, Sonnenaufgang, Timewime, Wibliwobli, Tageslänge, Bekanntmachung bezüglich gemeinsamer Uhrzeit für alle Reichsgesetz vom Uhrzeiten um ungefähr 21 Minuten vorzurücken sein. Was dann wichtig war, um irgendwie eine gemeinsame Zeit zu finden, war, den Nullmeridian festzulegen, weil es gab auch bis 18 irgendwas keinen einheitlichen weltweit geltenden Nullmeridian. Paris hatte einen, Russland hatte einen, also jede größere Hauptstadt hatte einen eigenen Nullmeridian und da gab es dann eine Konferenz in Paris, der nahm ich jetzt nicht weiß, weil ich keine Speakernotes habe, den Nullmeridian eben durch das Greenwich Observatorium bei London durchlaufen ließ. Das Schöne an diesem Nullmeridian ist, dass wir ausgehend von dem Nullmeridian dann auch unsere geliebten Zeitzonen definieren können, die immer wieder für Freude und Verwirrung in der IT stiften, das, was uns an der Nullmeridian aber auch gebracht hat, war eben die Universal Time Coordinated, das heißt die UTC, die es seit 1972 gibt, wenn ich mich an meine Speakernotes richtig erinnern kann. Ich merke mir keine Jahreszahlen, habe ich schon in der Schule nicht mögen. Wo hilft mir jetzt diese UTC? Diese UTC hilft mir zum Beispiel bei der Koordination der Arbeit an der ISS. Das sind alles Bodenstationen für die ISS, die mit der ISS koordinieren müssen, die mit der ISS konzentriert und kontrolliert Experimente durchführen müssen. Wenn man da mit jeder Lokalzeit arbeitet, ist das irgendwie ganz, ganz, ganz unpraktisch. Das heißt, worauf sich alle diese Bodenstationen geeinigt haben, von Frankreich in Europa, Deutschland, Houston in den USA, genauso wie die russische Launch Control und Mission Control, hat einfach gesagt, die ISS tickt nach UTC und alle anderen, wo sie sind, gehen den Rhythmus mit. Also diese ganze UTC-Geschichte ist eine sehr praktische. Wenn wir jetzt über Zeitzonen sprechen, dann haben wir diese Zeitzonen auch mit den Tatum versehen. Wenn wir mit Zeit umgehen, haben wir es oft mit US-Kollegen zu tun, die halt das Tatum so schreiben, wie sie es auch sprechen. Das heißt, May 4, 2018. Das heißt, das schaut dann irgendwie so aus. 2.1.13. Ist es jetzt der 2. Jänner 2013 oder ist es der 1. Februar 2013 oder ist es der 3. 1. 2002? Also dieses ganze amerikanische Datumsformat ist schon mal eine Katastrophe. Dann haben die mit dem 24-Stunden-System auch noch so ihr Problem. Die schreiben dann lieber gern EM und PM für Vormittag und Nachmittag hin und hinten dran dann vielleicht noch in der Zeitzone. Also das ist Japan Standard Time. Dafür gibt es eigentlich einen Standard. Den ISO Standard 86.01, wenn ich es jetzt richtig im Kopf habe. Da ist das ganz klar, Monat, Tag und dann die Uhrzeit und dann die Verschiebung der Zeitzone mit plus oder minus ab. Das ist gesehen vom Null-Meridian. Eindeutig, klar, verständlich und ich kann auch danach sortieren. Das sollte es eigentlich sein. Jetzt haben wir es aber öfter mit diesen Zeitzonen zu tun. Auch in der IT. Und diese Zeitzonen ändern sich ja auch. Also jetzt hat ja Nordkorea, hat jetzt angekündigt, jetzt wieder die halbe Stunde Verschiebung von zu Südkorea zurückzunehmen. Das heißt, die sind jetzt dann wieder in der selben Zeitzone. Das heißt, unsere ganzen Zeitzonen-Informationen müssen aktualisiert werden. Zum Glück gibt es da die Timezone-Database von der IANA verwaltet. Die haben sogar eine RFC, zu dem Thema kommen wir dann noch gleich, wie sie das Ganze tun. Und von denen gibt es regelmäßige Updates zu den ganzen Zeitzonen. Zu den Zeitzonen gehören dann auch die Countrycodes. Das heißt, welches Land hat welches Kützel. Das heißt, Österreich wird jetzt nicht mit US oder sonst irgendwas abgekürzt, sondern mit AT. Das ist definiert in der ISO 31-66. Die aus drei Teilen besteht. Wir haben die 31-66-1 mit zwei Lettercodes, also AT, mit drei Lettercodes. Da wäre es dann out. Und auch das Ganze in einer numerischen Variante, wo jedes Land eine dreistellige Zifferkombination hat. Was vor allem in der UNO verwendet wird. Und auch in vielen Ländern, die kein lateinisches Alphabet verwenden, die tun sich halt leichter mit Ziffern-Tippen, als irgendwelche komischen Buchstaben eingeben, die sie auf ihrem Keyboard nicht haben. Wer es dann noch genauer braucht, für den gibt es 31-66-2, wo dann auch noch die Bundesländer drinnen sind. Also da kann man dann noch einmal hinunterbrechen. Und in 31-66-3 werden dann noch die Codes für ehemalige Länder wie Jugoslawien, Sowjetunion und sonstige gesammelt, wenn man da quasi historische Daten braucht. Die Daten kriegte alle, die könnte alle aus dem Internet beziehen. Die links habe ich dann nachher in den Slides drinnen, wenn ich sie hochlade. Was war denn jetzt dann meine nächste? Genau, ISO 8601 wird eben vom ISO Standard, von der ISO verwaltet. Es definiert mir eben dieses Kalenderformat, wenn ich nur Ziffern habe und keine Monats- oder Tagesnamen drinnen habe. Das ist mittlerweile auch ein EU-Standard und damit auch ein Dienststandard, also ein Standard nach der deutschen Industrienorm. Und dieser Standard ist gerade in Überarbeitung. Das heißt, ihr könnt euch derzeit den neuesten Traft anschauen, der nächstes Jahr aktuell werden soll. Ist vielleicht einmal gar nicht uninteressant gibt es, also nicht erschrecken, weil da jetzt Französisch steht, das ist auch für sich alles lesbar. Also, ich spreche nicht Französisch daher, manchmal streitet man mir drüber, ob ich Deutsch spreche, aber ich bin mit mich. Diese ISO 8601 ist dann auch noch in einen anderen Standard Flossen, den normalerweise die Bürokaufleute und so weiter lernen dürfen. Nein, da kommt zuerst noch was anderes. Ich kenne meine eigenen Slides nicht mehr. Wenn man jetzt diesen ISO 8601-Statumsformat haben möchte, unter Linux, sollte man am besten die lokale ENDK verwenden. Ja, das ist ein Heck. Es gibt kein Englisch-Denemark. Aber das ist eine Lokale, die mir alles auf Englisch lässt. Das heißt, ich bekomme meine englischen Fehlermeldungen, ich bekomme meine englischen Status-Messages und alles. Aber das Datumsformat ist gemäß ISO 8601. Sehr, sehr fein. Diese lokale Information wird ebenfalls zentral verwaltet, und zwar vom Unicode Common Locale Data Repository, die das auch regelmäßig updaten und aktualisieren. Deutsch kann ich auch. Und die entsprechende Libraries für alle gängigen Sprachen zur Verfügung stellen. Also, die ICU, the International Components for Unicode for the UC Library, ist in so ziemlich allem drinnen, was ihr verwendet. Also von Android angefangen über Apple OS, über BSDs, über sämtliche Linuxe, die verwenden alle im Prinzip diese Library. Daher funktioniert das eigentlich auch fast überall, sehr, sehr fein und gut. Also, wenn ihr mal Lassen nachlesen wollt, oder eben zum Beispiel eine DEVEE für Deutsch wienerisch erstellen wollt und einbringen wollt, wenn euch langweilig wird, oder schwebisch, oder gibt es ja verschiedene Varianten. Genau, das, wo ich vorhin komme, es gibt dann noch die DEVEE 5008, die beschreibt Schreib- und Gestaltungsregeln für die Textverarbeitung und seit 1996 auch für die PC-Textverarbeitung. Also, Hallo. Definiert eben alles von Satzzeichen, Schriftzeichen, Gliederungen, wie hat ein Brief formatiert zu werden ein Schriftstück vernünftig auszusehen. Also, wenn jemand von euch in Verlegenheit kommt, doch noch einmal ein Snellmelding weggeschicken zu müssen, da würde definiert werden, wie das auszusehen hat. Also, mit Rahmen und wo der Adressblock stehen soll und wo der Startung stehen soll. Und was auch da drinnen stehen soll, weil darüber bin ich gestolpert, das war eigentlich einer meiner Auslöser für den Talk, da ist auch definiert, wie Telefonnummern angegeben werden müssen. Die korrekte Schreibweise nach den 5008 wäre die hier angeführte, wo die Null, die führende Null bei der Ortsvorwahl nicht angegeben wird, auch nicht in Klammern, sondern einfach gar nicht. Also, dieses Beispiel da unten, das muss weg. Weil ich das habe, ich kann in keinem Siebtelefon das Ding einfach anklicken. Ich muss jedes Mal Copy, Pesten und diese Klammer auf Null, Klammer zu rauslöschen, damit das Ding funktioniert. Das bitte einfach wegbekommen. Nehmt das Ding 5008 vor Naht, nehmt von mir das E-183-Format von der ITU. Der einzige Unterschied ist, die haben keinen Binderstrich bei der Durchwahl. Damit kann ich leben. Sogar das Microsoft-Format, das Sie für Ihre Telefonie-API verwendet haben, ist sinnvoller als das, was in einem Großteil des deutschsprachigen Raums verwendet wird. Also, luch mal Sie mal auf der Zunge zergehen lassen. Ja, ich habe hier eine sehr starke Meinung zu dem Thema. Und was es natürlich auch gibt, es gibt natürlich auch eine LFC dazu, mit dem ich eine Telefonie, URI, also eine Uniformer-Resource-Identifier definieren kann. Auch der wäre in Ordnung. Auch der funktioniert, wenn ich ihn anklicke. Dasselbe gibt es nicht nur für internationale Rufnummern, sondern auch für nationale Rufnummern. Auch hier wieder. Die 030 ist in Ordnung, aber der Slash dahinter hat nichts verloren. Das können aber die meisten Telefonanlagen zum Glück rausfiltern. Aber wer das nicht mit den internationalen mit der Vorwahl mitspeichert, hat sowieso am Handy verloren, weil in dem Moment, wo ich mit EU-Roming im Ausland bin und solche Nummern hab, funktionieren sie eh nicht mehr. Also, das ist sowieso hinfällig und unnötig. Das Einzige, was es noch gibt, ist eine eigene DIN-Norm, also eine eigenen Absatz-Inner-DIN-Norm zum Thema Mehrwertdienste, wie die geschrieben haben müssen. Also, wenn ihr was aus diesem Talk mitnehmt, dann bitte nehmt einen dieser vernünftigen Schreibweisen für Telefonnummern, gerade in E-Mail-Futtern und so. Ich rufe den schnell an, klick. Ach nein. Bitte, bitte, bitte, bitte, bitte, bitte. Gut, wenn wir jetzt schon über Telefonie-Uhr des Sprechen, dann reden wir doch gleich einmal über die RFC 3966, Uniform Resource Identifiers Generic Syntax. Ich mach jetzt keine lyrische Lesung des ganzen Teils. Nein, ich habe doch keine Zeit. Ich würde euch aber sehr nahe legen, das Ding zumindest einmal anzusehen, beziehungsweise wenn ne frische Kollegen aus der Schule oder von der Uni habt, gebt denen das mal ausgedruckt zum Lesen oder auch gerne als E-Paper. Das definiert nämlich wieder so ein Uniform Resource Identifier und auch die Untergruppe der Uniform Resource Locators, die dann eben auch angemwo finde ich das Ganze und nicht nur was. Definieren und zwar für alles, was wir in der IT so brauchen von FDP-Urals, HTTB-Urals, LDAPs, Mail-Adressen, Telefonnummern, Telnet. Sollte ich vielleicht mit SSH austauschen, aber die Cisco-Admins brauchen das ja noch immer, oder? Aber wer macht ein Cisco, oder? Das wäre so die eine RFC, wo ich sage so, die sollte Mensch mal gelesen haben, um verstanden zu haben, wie dieses Internet und diese Uris und Urals funktionieren. Überhaupt RFCs zu lesen, empfiehlt sich überhaupt. RFCs sind die Quests für Comments, also eine Bitte zum Kommentar, die durch den RFC-Editor veröffentlicht werden. Das war lange Zeit der John Postel, mittlerweile ist das ein Team an Menschen. Und auch so einem RFC kann, wenn man möchte, ein sogenannt Internet-Standard werden. Das Ganze ist auf rfceditor.org ganz wunderbar beschrieben. Ich durfte im Frühjahr mit der obersten RFC-Editorin ein bisschen plaudern, was ja eine zweite Motivation für mich war, den Talk zu machen, weil es einfach super spannend ist, was alles passiert und was da alles dahinter abläuft. Wie gesagt, rfceditor.org, die Ansprechseite für alle Themen RFC, jede Person auf diesem Planeten darf eine RFC schreiben. Ihr dürft, sollt und könnt, also könnt, ihr könntet, wenn ihr wolltet. Bleiben wir bei dem, don't go into that. Die sind alle total lieb, total hilfreich, wenn man dort hinschreibt, die schreiben auch zu gerne, das vergessen oder macht das noch. Die sind auch gerade im Umbau, also die ganzen RFCs sind derzeit noch in sieben BitSkis geschrieben und in einem ganz starren Text-Format. Das ändert sich heuer. Wir dürfen dann auch im Jahre 2018 Unico-Zeichen und Umlautte verwenden in RFCs. Das kommt irgendwann heuer und schauen wir mal, ob das dann funktioniert und wo es bröselt. Aber es wird funktionieren, sage ich jetzt mal. So eine, ja, diese RFC-Editors gehören eben zu Internet Society, die einen ganzen Haufen an Zeug machen. Da gehört eben dann auch die IETF-Internet-Engineering Taskforce und die ICANN dazu. Also alles, was irgendwie im Internet-Standards-Bereich tätig ist, ist da irgendwie drinnen verkraben. Bisher hab ich, gell? Ja. So ein RFC-Status, ein bisschen mehr drauf, ja, danke. Das kann eben informationell sein, sprich rein zu Info. So, ich hab da was, ich weiß nicht, ob es funktioniert, experimental. Wenn ich dann sage, ja, ich hab was, wo ich denke, das könnte ein vernünftiger Standard sein, kann ich das mal als Proposed-Standard eingeben. Dann wird es irgendwann ein Draft, wenn es reviewed wurde und irgendwann ein Standard. Diese Standards können dann auch required sein. Das heißt, wenn du damit spielen willst, musst du den implementieren sauber. Es kann auch immer eine Empfehlung sein oder elektrifizional, wenn es dich freut, dann mach das halt mal. Wenn die RFCs verwendet werden, das heißt, ich hab eine Version, dann hab ich irgendwas dazugelernt in einem Projekt, dann mach ich eine neue Version von dem Ding und kann sagen, dieser neue RFC löst den alten RFC ab. Zeige ich jetzt dann auch noch gleich her. Eine RFC, die man lesen sollte, als ITLA wäre die RFC 2119, wo eben so Dinge wie Säulen und Müssen und Sollte nicht und muss nicht und könnte und dürfte definiert sind. Unter Technikern sollte diese Nomenklatur üblich sein. Wenn ein Techniker sagt, ich muss, dann ist es dieses muss und nicht das Manager. Na ja, aber wenn man da noch ein bisschen so muss, muss, muss, nicht, schuld. Lesen, lesen ist wirklich, wirklich hilfreich in der Kommunikation. Ebenso die Standard 68, wo ich jetzt die RFC-Nummer in den Speaker-Notes hab und nicht auswendig weiß, der definiert mir eine erweiterte Parkus-Nau-Form, sprich eine Grammatik, für jedes Sündtags, die ich in der RFC hab. Das heißt, ich definiere hier die Sündtags zum Beispiel für das Datumsfeld in einer E-Mail. Genauso die Absendadresse, genauso den Empfänger. Nachdem das eine Grammatik ist, kann ich die Parsons und weiterverarbeiten und dann gibt es so Wahnsinnige, die machen aus einer RFC, Argumented Parkus-Nau-Form, eine Regular Expression, die eine E-Mail-Adresse gemäß dieser RFC parsen kann. Das ist dann natürlich, sag ich einmal, wenig umfangreicher, aber es ist Standard-Conform. Also da kann man jetzt nichts dagegen sagen. Es braucht dann auch vielleicht ein bisschen länger, bis es durchgelaufen ist, aber es tut. In der Praxis nicht benutzbar, aber ich hab hier eine BNF und die kann ich parsen und was draus generieren. Alles fein. Gut, das wäre so Lese-Liste, wenn jemand Zeit hat, ein paar RFCs, die ich empfehlen würde. Was ich auf jeden Fall empfehlen würde, wären die RFC 8252. Das passt sehr gut zu der Märchenstunde, die wir vor drei Stunden hier hatten. O-Auf von Native Apps. Wie mache ich Multifact-Authentifizierung mit O-Auf mit einer mobilen Applikation sauber und ordentlich und in schön? Sehr empfehlenswert setzen, leider die wenigsten Applikationsentwickler derzeit um. Auch sehr empfehlenswert sind dann immer die RFCs vom 1. April. Das ist jetzt eben die RFC 1149. IP über Avian Carrier, sprich IP über Brieftaube. Diese ersten April-RFCs werden genauer kontrolliert als jede andere RFC. Das heißt, wenn ihr eine Idee für eine erste April-RFC habt, reicht sie ein. Ihr lernt sehr, sehr viel dabei über diesen Standardprozess, wenn ihr sowas schreibt. Wie man jetzt links oben hier sieht, steht da auch updated by 2549 und 6214. Die RFC 6214 erweitert den Transmission of IP-Datagrams über Avian Carriers für IPv6. Und die 2549 macht das Ganze dann auch noch mit Quality of Service. Alter, das geht schon. Das ist nicht nur alles trocken. Da kann man auch so viel lernen. Wenn man schon bei Trocken und Daten sind, es gibt natürlich auch eine RFC für das Thema Comma Separated Values, CSV Dateien 4180. Würde so ausschauen. In der Realität schaut es meistens so aus mit dieser einen Zeile dazu, weil sonst sagt Excel, wie Comma Separated Values, also beistrich getrennte Daten. Was ist denn jetzt der Trainer bei dieser beistrich getrennten Datei? Willkommen in der wunderbaren Welt des Standards. Jeder sollte mindestens einen haben. Microsoft spielt da immer sehr gerne mit. Heutzutage macht man natürlich Comma CSV, sondern es macht Jason. Der ECMA Standard 404, von der ECMA definiert eben genau die JSON Data Interchangesyntax. Und eine RFC gibt es auch dazu. Danke schön. Wunderbar, ich habe danach eine Mannerschnitte für dich. Hol sie dir bitte nachher. Es gibt dann natürlich auch noch die Möglichkeit, darauf aufzubauen. Es gibt dann von der IBM JSON-X, um JSON als XML zu repräsentieren. Standards sind was Wunderbares. Jeder sollte mindestens einen haben. Das macht mir dann aus einem wunderbaren JSON ein wunderbares XML. Hallo. Herr Pfann. Geht. Warum macht ihr das? Weil es geht. Meine Empfehlung wäre dann auch noch die 8879er ISO Standard anzuschauen. Das ist SGML. Das ist eine Auszeichnungssprache, um Auszeichnungssprachen zu definieren. Ist quasi der Großvater von XML und HTML. Das ist eine Auszeichnungssprache. Das ist eine Auszeichnungssprache, um Auszeichnungssprachen zu definieren. Bis exklusive Version 5 konnten auch noch als SGML geparzt werden. Die EKMA hat aber nicht nur JSON zum Standard gemacht, sondern auch noch viele andere tolle Dinge. Sie-Sharp und dort Net-Technologie von Microsoft. EKMA-Script hat quasi den Krieg in den Nullerjahren zwischen Net Skip und Microsoft. Und JavaScript befriedet. im Rahmen des Technischen Committees 45 verabschiedet. Das ist das, von diesem OfficeOpenXML gibt es zwei Varianten, einmal die ECMA-Variante und einmal die ISO-Variante, die untereinander nicht kompatibel sind, aber beide die Arbeitsweise von Microsoft Office abbilden. Ich bin gleich durch, du kannst dich entspannen. Der OfficeOpenXML-Standard ist ausgedruckt, übrigens das. Es gibt keine RFC-Disotik ist, also nicht, dass ich wüsste. Wer das implementieren kann, ist ein Wunderwutzi, fallen wir jetzt im Nachhinein. Das Ponton dazu wäre von einer weiteren Standardisierungsorganisation, weil wenn man einen eigenen Standard bei den bestehenden Standardisierungsgremien nicht durchbringt, dann macht man einfach ein neues Standardisierungsgremium. Auch das ist eine Option, in dem Fall ist es die Oasis Group, die dann eben das OpenOffice-Dokument von StarOffice beziehungsweise dann OpenOffice genommen hat und auch einem Standard zugeführt hat, der dann auch in einem ISO-Standard geändert hat. Hurra! Man sieht also, man kann nie genug Standards haben. Wenn man zu viel Standard hat, kann das aber auch so enden. Das war der Maas Surveyor, der mit zwei unterschiedlichen Standards gerechnet hat. Einmal mit Pascal per square inch und einmal mit Newton Sekunden oder so irgendwie was dazu geführt hat, dass dieses schweinitäre Objekt einen großen Krater auf dem Maas gemacht hat. In diesem Sinne sage ich, be liberal in what you accept, be conservative in what you sell, sage vielen herzlichen Dank und ich hoffe, ich habe euch ein bisschen unterhalten. Danke schön. Keine Speakernotes helfen dabei, den Talk hier zu zu machen. Hallo. Vielen Dank für deinen Vortrag. Ist das Videoteam von dem nächsten Talk schon da? Haben wir noch ein paar Minuten? Ja, super. Gibt es Fragen? Einwürfe. Wichtige Standards, die ich vergessen hätte? Ja, immer, aber natürlich. Hier ist eine Frage. Ein ganz wichtigen Standard, RFC7511, Scenic Routing for IPV6. Scenic Routing. Gib ihm mal das Mikro. Ich war jetzt eigentlich fertig. Ich stehe doch mal auf und gestehe. Was tut das? Scenic Routing for IPV6, klang auf, ich habe es geschrieben, klang mal zu. Definiert einen neuen, was war das denn, irgendein Hader im IPV6, wo man sagen kann, ob das Ding über AVN IP Carrier oder Richtfunkstrecken transportiert werden soll, damit es nicht so viel im Kabel ist und was von der Welt sieht. Oh, sehr schön. Wie lange hat das gedauert, bis er durch war? Die Antwort ist eineinhalb Wochen, er war später dran. Also ihr seht, auch einen 1. April RFC kriegt man zügig durch, wenn man mal sich eingelesen hat, wie das auszusehen hat. Die nehmen das sehr, sehr ernst. Das finde ich super schön. Das ist Spaß, aber sehr ernst genommener Spaß. Probiert das mal, ist wirklich schön und lest mal nach, was so schon alles gibt. Sehr schön. Ich habe auch schon IP über Bongos gesehen, aber das war keine RFC. Leider war auch sehr schön. Andere Dinge, die wollen alle schon das Demo. Dass es gerne weitere Fragen gibt, dann ranke ich es bei dir, Leira, für einen tollen Talk. Danke an euch und einen schönen Abend. Dankeschön.