Vorlesung Multimediakommunikation 2. XMPP. Dr.-Ing. Daniel Schuster Fakultät Informatik, Professur Rechnernetze

Transkript

1 Vorlesung Multimediakommunikation 2. Dr.-Ing. Daniel Schuster Fakultät Informatik, Professur Rechnernetze

2 Grundprinzip Instant Messaging und Presence Presence = Verfügbarkeit der Teilnehmer kommunizieren Instant Messaging = Zustellung von Nachrichten in Echtzeit Professur Rechnernetze Multimediakommunikation 2. 2

3 1. Presence: Definition Presence = Status-Indikator eines potentiellen Kommunikationspartners Ist er/sie in der Lage und willens zu kommunizieren? Generalisierung des Presence-Begriffs: Presentity beliebige Entities können Presence- Informationen bereitstellen (Beispiel Machine2Machine Communication) eindeutige, weltweite Identifizierung des Presentity à URI Presence-Informationen Basis: Offline, Online, Away, Busy beliebig erweiterbar: Location, Aktivitäten, Privacy-Policies nötig (Presence-Informationen selektiv verteilen) Quelle: Presence_information Professur Rechnernetze Multimediakommunikation 2. 3

4 SPOP vs. MPOP SPOP - Single Point of Presence Nutzer wird nur durch ein Presentity repräsentiert muss sich bei jeweils genutztem Gerät immer wieder neu einloggen Lokalisierung einfach MPOP - Multiple Points of Presence Nutzer wird durch mehrere Presentities (=Geräte) gleichzeitig repräsentiert Lokalisierung schwierig - auf welches Gerät soll die Nachricht zugestellt werden? Presence Service Professur Rechnernetze Multimediakommunikation 2. 4

5 Formalisierung: Presence Service nach RFC 2778 Presence UA Presentity Presence Protocol Access Rules Presence Service Visibility Rules Presence Protocol Watcher UA Fetcher Watcher UA Presence Information Watcher Information Subscriber Presence Service: speichert und verteilt Presence Information Presence Information: Menge von Presence-Tupeln Access Rules: wer darf auf Presence Information zugreifen? Presentity: stellt Presence Information zur Verfügung Watcher: bezieht Presence Information oder Watcher Information Watcher Information: wer sieht meine Presence Information? Visbility Rules: welche Watcher-Informationen sind sichtbar? Professur Rechnernetze Multimediakommunikation 2. 5

6 Presence Information (nach RFC 3863) Entity URI <presence xmlns="urn:ietf:params:xml:ns:pidf" <tuple id="sg89ae"> <status> <basic>open</basic> <local:location>home</local:location> </status> <contact priority="0.8">tel: </contact> </tuple> </presence> Kontaktadresse mit Priorität einfacher Status: open / closed erweiterter Status ein oder mehrere Tupel (MPOP) 2. 6

7 Rich Presence (nach RFC 4480) <dm:person id="p1"> <rpid:activities from=" t12:00:00+05:00" until=" t17:00:00+05:00"> <rpid:note>far away</rpid:note> <rpid:away/> </rpid:activities> <rpid:class>calendar</rpid:class> <rpid:mood> <rpid:angry/> <rpid:other>brooding</rpid:other> </rpid:mood> <rpid:place-is> <rpid:audio> <rpid:noisy/> </rpid:audio> </rpid:place-is> place-type activity mood device place-is privacy relationship user-input <rpid:place-type><lt:residence/></rpid:place-type> <rpid:privacy><rpid:unknown/></rpid:privacy> <rpid:sphere>bowling league</rpid:sphere> <rpid:status-icon> <rpid:time-offset>-240</rpid:time-offset> <dm:note>scoring 120</dm:note> <dm:timestamp> t16:09:44+05:00</dm:timestamp> </dm:person> status-icon 2. 7

8 2. Instant Messaging: Abgrenzung Web / HTTP Kommunikation Web-Client à Web-Server keine direkte Kommunikation mit anderen Web-Clients keine echten Push-Nachrichten Web-Server à Web-Client direkte Nachrichtenzustellung -Client zu -Client Routing über mehrere -Server kein Echtzeitverhalten à Mails werden periodisch vom Client abgerufen Instant Messaging permanent offene Verbindung zwischen Client und IM-Dienst direkte Zustellung von Messages in Echtzeit Professur Rechnernetze Multimediakommunikation 2. 8

9 Instant Message Service (RFC 2778) Delivery Rules Sender UA Sender IM Protocol Instant Message Service IM Protocol Inbox UA Instant Inbox Sender: Quelle von Instant Messages, übergibt Messages mit bestimmter Adresse Instant Inbox: Empfänger von Instant Messages Instant Message Service: liefert Instant Messages aus erfordert meist Authentisierung kann aus mehreren Servern und Proxies bestehen Delivery Rules: Filterung von Instant Messages Professur Rechnernetze Multimediakommunikation 2. 9

10 Instant-Messaging-Architekturen: direkt direkte Zustellung (a) Adresse des Empfängers muss bekannt sein keine Pufferung von Nachrichten Probleme Adresse von Bob darf sich nicht ändern à Mobilität? ungewünschte Kommunikation möglich (keine Authentisierung) Anwendung Setup von Ad-hoc-Verbindungen in lokalen Netzen, z.b. Bonjour- Protokoll Professur Rechnernetze Multimediakommunikation 2. 10

11 Instant-Messaging-Architekturen: ein Server 1-Server-Architektur ohne Zwischenspeicherung 1-Server-Architektur mit Zwischenspeicherung Clients melden ihre aktuelle Adresse an Server Messages werden immer an Server geschickt Sender kann Adresse des Empfängers abfragen Anwendung: die meisten kommerziellen IM-Dienste Clients müssen sich authentisieren Professur Rechnernetze Multimediakommunikation 2. 11

12 Instant-Messaging-Architekturen: mehrere Server Mehr-Server-Architektur ohne Zwischenspeicherung Registrierung bei lokalem Server Requests werden weitergeleitet Lokalisierung und Authentisierung zwischen Servern benötigt Mehr-Server-Architektur mit Zwischenspeicherung Messages werden immer an den lokalen Server geschickt Anwendung: gut skalierbar Professur Rechnernetze Multimediakommunikation 2. 12

13 Instant Messaging: verbreitete Systeme Proprietär Standardisiert - extensible Instant Messaging and Presence Protocol SIP/SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions Quelle: statista.com Professur Rechnernetze Multimediakommunikation 2. 13

14 Zusammenfassung Presence Instant Messaging Presentity SPOP vs. MPOP Presence Service nach RFC 2778 Presence Information Instant Message Service nach RFC 2778 direkt Architekturen Rich Presence Ein-Server Mehr-Server 2. 14

15 3. - Was ist? extensible Messaging and Presence Protocol ist ein offenes XML-Protokoll für Echtzeit-Messaging <message> Presence <presence> Request-Response-Dienste <iq> auch bekannt als Jabber ß à Jabber = HTTP+HTML ß à WWW definiert in IETF RFC 6120 Core (2011) IETF RFC 6121 Instant Messaging and Presence (2011) Erweiterungen: Extension Protocols (XEPs) auf.org

16 Architektur dezentrale Client-Server-Architektur permanente TCP-Verbindungen zwischen Client und Server Inter-Server-Kommunikation mit Hilfe des DNS direkte Föderation 2. 16

17 DNS-Konfiguration SRV-Records _xmpp-client._tcp.a.de IN SRV xmpp.a.de. _xmpp-server._tcp.a.de IN SRV xmpp.a.de. Client-Server SRV-Records für Subdomains Server-Server _xmpp-client._tcp.conference.a.de IN SRV xmpp.a.de. _xmpp-server._tcp.conference.a.de IN SRV xmpp.a.de. A-Records xmpp.a.de IN A Multi-User Chat IP-Adresse des Servers TXT-Records (optional) HTTP (BOSH) _xmppconnect IN TXT "_xmpp-client-xbosh= _xmppconnect IN TXT "_xmpp-client-websocket=wss://xmpp.a.de:443/ws" WebSockets 2. 17

18 JIDs JID: Jabber Identifier = Adresse der Instant Inbox user@domain/resource Domain: registrierte Domain des -Servers, z.b. a.de User: Nutzername auf -Server, z.b. alice Resource: wenn ein Client sich einloggt, bindet er sich an einen Resource Identifier Client auf Handy JID: alice@a.de/mobile Client auf PC JID: alice@a.de/pc verbunden mit Jabber-Server Domain: a.de URI: xmpp1.a.de IP:

19 Kommunikationskonzept grundlegendes Kommunikationskonzept: 1. XML Streams = Container für den Austausch von XML-Entitäten zwischen Client und Server 2. XML Stanzas = XML-Elemente mit den Nachrichten: <message/>, <presence/>, <iq/> Ablauf 1. Öffnen einer langlebigen TCP-Verbindung 2. Authentisierung, Aushandlung, Verschlüsselung 3. Streams öffnen: <stream> (in beide Richtungen) 4. Stanzas übertragen / empfangen 5. Streams schließen: </stream> Client <stream/> stanza stanza <stream> <stream> stanza stanza </stream> Server Streams zu anderen Clients 2. 19

20 Beispiel-Streams (vereinfacht) Client > Server <stream:stream> <presence/> <iq type="get"> <query xmlns="jabber:iq:roster"/> </iq> <message from= to= > <body>hallo!</body> </message> <presence type="unavailable"/> </stream:stream> <stream:stream> Server > Client <iq type="result"> <query xmlns="jabber:iq:roster"> <item <item </query> </iq> <message from= to= > <body>hi!</body> </message> </stream:stream> 2. 20

21 Stanzas message, presence, iq from, to type payload <child1> </child1> <child2> </child2> Stanza message - fire and forget presence - publish/subscribe iq - request/response Bare JID (bob@b.de) - mindestens eine Ressource von Bob Full JID (bob@b.de/s4) - genau diese Ressource Untertyp des Stanza, z.b. bei Presence: subscribe, subscribed, available, unavailable,... XML-Inhalt (mit namespace): Erweiterbarkeit Daniel Schuster for Pervasive Computing 21

22 Stanzas: Typen Client message Server message Client Push-Semantik - fire and forget presence/subscribe Client presence/notify Server presence/notify Client Push-Semantik - PubSub - 1:n-Verteilung iq/get Client iq/result Server Client Pull / RPC - Semantik (zuverlässiger Transport) Professur Rechnernetze Multimediakommunikation 2. 22

23 Verbindungsaufbau Client-Server Client 1. SRV _xmpp-client._tcp.a.de. xmpp1.a.de Server DNS 2. A xmpp1.a.de. Verbindung = Session Client und Server authentisiert alice@a.de/phone Buddy list 3. TCP-Verbindung / XML-Streams öffnen 4. Login, TLS upgrade 5. Ressource binden 6. Roster abrufen (buddy list) 7. presence = available 8. presence probe 8. Presence updates Buddy list mit Verfügbarkeit 2. 23

24 Stream-Features (Schritt 3) <stream:features> <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"> <optional/> TLS-Verschlüsselung ist </starttls> optional <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> <mechanism>plain</mechanism> SASL-Authentisierung ist <mechanism>digest-md5</mechanism> erforderlich, entweder über <required/> PLAIN oder DIGEST-MD5 </mechanisms> <compression xmlns=" <method>zlib</method> </compression> </stream:features> TLS Transport Layer Security SASL Simple Authentication and Security Layer Stream Compression wird angeboten (auch optional, wenn nicht <required> steht) 2. 24

25 Zusammenfassung Core + Extensions (XEPs) JIDs DNS direkte Föderation Streams + Stanzas Verbindungsaufbau Client-Server IQ Presence Message 2. 25

26 4. IQs (Info/Query) Mechanismus für Anfragen und Dienstaufrufe (Beispiel: Roster des Nutzers abrufen) Client: <iq from= id= rr82a1z7 to= type="get"> <query xmlns="jabber:iq:roster"/> </iq> Server: <iq from= id= rr82a1z7 to= type="result"> <query xmlns="jabber:iq:roster"> <item <item <item </query> </iq> 2. 26

27 IQ-Stanzas - Definition Nachrichten werden über Namespaces identifiziert à Erweiterbarkeit IQ-Typen: "get, "set, "result und error auf get/set muss immer result oder error gesendet werden einfacher RPC-Mechanismus (Remote Procedure Call) get/set kann auch vom Server an den Client oder von einem Client an einen anderen Client geschickt werden nur an Full JIDs(kein Priority-Routing) iq-get Requester (-Client oder Server) iq-result iq-set iq-error Responder (-Client oder Server) 2. 27

28 Beispiel: vcards (XEP-0054) Client <iq id="pw91nf84" type="get"> <vcard xmlns="vcard-temp"/> </iq> Server <iq id="pw91nf84" type="result"> <vcard xmlns="vcard-temp"> <N> <GIVEN>Alice</GIVEN> </N> <URL> <PHOTO> <EXTVAL> andrew03a.gif</extval> </PHOTO> </vcard> </iq> 2. 28

29 Beispiel für IQ-Set Client Server <iq id= pw91nf85" type="set"> <vcard xmlns="vcard-temp"> <N> <GIVEN>Alice</GIVEN> </N> <URL> </vcard> </iq> <iq id="pw91nf85" to= type= result"/> 2. 29

30 5. Messaging Client xmpp1.a.de Server Client message message <message type="chat"> <body>anyone home?</body> </message> Daniel Schuster for Pervasive Computing 30

31 Message-Zustellung föderiert xmpp1.a.de jabber.b.de Client message Server DNS SRV _xmpp-server. _tcp.b.de. Server Client A jabber.b.de. Verbindungsaufbau (TLS handshake) message to=bob@b.de message to=bob@b.de Daniel Schuster for Pervasive Computing 31

32 Aufbau von Message-Stanzas Push-Mechanismus für Messages und andere Inhalte Fire-and-Forget -Semantik, d.h. keine Bestätigung durch den Empfänger Verschiedene Typen (type) normal (normale Messages), chat (Nachrichten in IM-Session), groupchat (im Chatraum), headline (Warnungen und Benachrichtigungen), error (Fehlermeldung) <message type="chat"> <body>wer bist du?</body> <subject>query</subject> </message> Type-Attribut hier Textnachricht (chat) Elementname des Stanzas (message) Payload des Stanzas hier Nachricht (body) und Betreff (subject) 2. 32

33 Full JID vs. Bare JID bei Messages Client xmpp1.a.de Server Client Bare JID = irgendeine Ressource von Bob message from=alice@a.de/phone to=bob@a.de message from=bob@a.de/s4 to=alice@a.de/phone message from=alice@a.de/phone to=bob@a.de/s4 message from=bob@a.de/s4 to=alice@a.de/phone Full JID - Ressource durch Server zugeordnet 2x Full JID = bestehende Chat Session bleibt bei Full JID bis Presence-Änderung empfangen Professur Rechnernetze Multimediakommunikation 2. 33

34 Offline Messages (XEP-0203) <message type='chat'> <body> O blessed, blessed night! I am afeard. Being in night, all this is but a dream, Too flattering-sweet to be substantial. </body> <delay xmlns='urn:xmpp:delay' from='capulet.com' stamp=' t23:08:25z'> Offline Storage </delay> </message> delay - zeigt verzögerte Zustellung an 2. 34

35 Chat State Notifications (XEP-0085) <message type="chat"> <composing xmlns=" </message> Start Active Inactive Gone Composing Paused 2. 35

36 Formatierte Messages I love this movie I saw last night, it s awesome! <message from="alice@a.de/home" to="bob@b.de" type="chat"> <body>i love this movie I saw last night, it's awesome!</body> <html xmlns=" <body xmlns=" <p> I <em>love</em>, this new movie I saw last night, it's <strong>awesome</strong>! </p> </body> </html> </message> <body>: Plain-Text- Version für Kompatibilität <html>: formatierte Version in XHTML 2. 36

37 6. Presence Handling Austausch von Presence-Informationen und Management von Subscriptions des Presence-Dienstes type: (kein Type=available), unavailable, subscribe, subscribed, unsubscribe, unsubscribed, probe (Status abfragen), error <show> (optional): away, chat (verfügbar), dnd (do not disturb), xa (extended away) <status> (optional): Text-Beschreibung des Presence-Status <presence <show>xa</show> <status>bin im Urlaub!</status> </presence> Presence- Update xa extended away 2. 37

38 Presence Subscription Handshake (1) Client Server Client Anzeige im Roster - warte auf Antwort presence subscribe to=andrew@a.de iq set roster item jid=andrew@a.de ask=subscribe subscription=none presence subscribed from=andrew@a.de to=alice@a.de presence subscribe from=alice@a.de to=andrew@a.de presence subscribed to=alice@a.de Nutzer fragen iq set roster item jid=andrew@a.de subscription=to Online-Status wird angezeigt presence available from=andrew@a.de to=alice@a.de 2. 38

39 Presence Subscription Handshake (2) Client presence subscribe presence subscribed Server presence subscribe iq set roster item ask=subscribe subscription=from presence subscribed Client iq set roster item subscription=both presence available

40 Verteilung der Presence-Informationen Client <presence/> <presence from= to= /> <presence from= to= /> Server <presence from= to= /> Client eigene Presence wird an alle angemeldeten Ressourcen gespiegelt erhält Presence von allen Kontakten (Server kennt letzten Online-Status) 2. 40

41 Presence Probe xmpp.a.de xmpp.b.de Client <presence/> Server <presence from= to= type= probe /> Server Client <presence from= to= /> <presence from= to= /> Presence Probe an Kontakte auf anderen Servern Server b.de teilt Online- Status mit 2. 41

42 Priority Routing erlaubt, dass ein Nutzer mit mehreren Devices gleichzeitig angemeldet ist wohin Message schicken, die an adressiert ist? Presence-Prioritäten (-127 bis +127) Methode: an Gerät mit höchster Priorität zuerst schicken an Geräte mit negativer Priorität nie schicken (nur wenn direkt adressiert Full JID) <presence <priority>7</priority> </presence> <presence <priority>3</priority> </presence> <presence <priority>-1</priority> </presence> 2. 42

43 Temporary Presence Problem: manchmal nur kurze Interaktionen, möchte nicht jeden Kommunikationspartner zur Kontaktliste hinzufügen Lösung: Temporary Presence = direkte Presence-Nachrichten (Client-Client) wird auch über -Server verschickt, aber dort nur weitergeleitet alice@a.de/ Notebook bob@b.de/ TV <presence from="alice@a.de/notebook" to= bob@b.de/tv /> <presence from="bob@b.de/tv" to= alice@a.de/notebook type= unavailable /> 2. 43

44 7. -Sicherheit Client 1 jules@abc.com Server 1 abc.com Server 2 xyz.com Client 2 vinc@xyz.com Man in the middle zwischen Server und Client Verschlüsselung der Client-Server- Kommunikation TLS und SASL Server Vertrauenswürdig? TLS nutzlos, da nur Verbindung geschützt Ende-zu-Ende- Verschlüsselung mittels OTR Man in the middle Attacke zwischen Servern Verschlüsselung der Server-Server Kommunikation TLS TLS Transport Layer Security TCP-Verbindung absichern SASL Simple Authentication and Security Layer Authentisierung (arbeitet mit TLS zusammen) OTR Off-the-Record Messaging (AES und sichere Hash-Funktion) 2. 44

45 SASL - Simple Authentication and Security Layer standardisiertes Sicherheits-Framework für Verbindungs-orientierte Protokolle durch IETF standardisiert (RFC 4422) viele freie Implementierungen verfügbar neben z.b. auch in -Protokollen benutzt Authentisierungs-Mechanismen PLAIN - Übertragung des Passworts im Klartext (nur möglich, wenn Verbindung schon durch TLS abgesichert) DIGEST-MD5 - gehashte Übertragung des Passworts (128 Bit) - gilt nicht mehr als sicher SCRAM - Salted Challenge Response Authentication Mechanism - empfohlene Methode, verbesserte Sicherheit (u.a. gesalzene Hashes) aber noch nicht von allen Servern unterstützt EXTERNAL - Authentisierung mit Zertifikaten während der TLS- Aushandlung (für Server-zu-Server-Verbindungen) ANONYMOUS - keine Authentisierung (z.b. für Call-Center- Szenarios) 2. 45

46 TLS - Transport Layer Security hybrides Verschlüsselungsprotokoll kombiniert asymmetrische und symmetrische Verfahren 5 bei HTTP: Standard-Verbindung über Port 80, sichere Verbindung (HTTPS) über Port 443 TLS 4 bei : keine separaten Ports sondern Upgrade der bestehenden Verbindung (Port 5222) TCP <starttls/>-kommando IP 3 Ethernet

47 Beispiel für TLS- Upgrade bei -Verbindungsaufbau (Client-Server) Client <stream:stream from= a.de id= d1r3ht0n4 version= 1.0 xmlns= jabber:client xmlns:stream= > <stream:features> <starttls xmlns= urn:ietf:params:xml:ns:xmpp-tls > <required/> </starttls> </stream:features> <starttls xmlns= urn:ietf:params:xmls:ns:xmpp-tls /> <proceed xmlns= urn:ietf:params:xmls:ns:xmpp-tls /> Server TLS-Handshake <stream:stream to= a.de version= 1.0 xmlns= jabber:client xmlns:stream= > (verschlüsselt) 2. 47

48 TLS-Handshake (vereinfacht) client_hello Zufallszahl Client, Liste von Cipher Suites server_hello Zufallszahl Server, ausgewählte Cipher Suite (z.b. TLS_DHE_RSA_WITH_AES_256_CBC_SHA) Client client_key_exchange Pre-Master-Secret (verschl. mit Public Key des Servers) certificate Server-Zertifikat(e) server_hello_done Server change_cipher_spec ab jetzt alle Nachrichten verschlüsselt finished symmetrisch verschlüsselt (z.b. AES) finished symmetrisch verschlüsselt (z.b. AES) 2. 48

49 Blockieren und Filtern von Nachrichten Simple Communications Blocking - XEP-0191 <iq from="alice@a.de/pc" id="yu4er81v" to="alice@a.de" type="set"> <block xmlns="urn:xmpp:blocking"> <item jid="userx@evil.org"/> </block> </iq> Nutzer X bekommt keine Presence-Updates mehr IQ-get oder set von Nutzer X wird geblockt eingehende <message> und <presence> Stanzas von Nutzer X werden ignoriert (nicht weitergeleitet) jede ausgehende Nachricht an Nutzer X wird vom Server geblockt (Error: <not-acceptable/>) auch Blockieren ganzer Domains möglich 2. 49

50 Abruf der Blocklist Client <iq id="92h1nv8f" type="get"> <blocklist xmlns="urn:xmpp:blocking"/> </iq> <iq id="92h1nv8f" type="result"> <blocklist xmlns="urn:xmpp:blocking"> <item <item jid="spammers.lit"/> </blocklist> </iq> Server 2. 50

51 Erweitertes Filtern Privacy Lists - XEP-0016 feingranulares Blockieren und Filtern von Nachrichten <list name="mylist"> <item type="jid" value="userx@evil.org" action="deny" order="1"> <iq/> <message/> <presence-out/> </item> <item type="group" value="work" action="deny" order="2"> <presence-in/> </item> <item action="allow" order="3"/> </list> Eingehende Nachrichten und IQs von User X werden blockiert; Presence nur outgoing geblockt kein Presence von Arbeits-Kontakten alles andere erlaubt 2. 51

52 OTR - Off-the-record Messaging PGP: asymmetrische Verschlüsselung + digitale Signatur Problem: private Key gestohlen = alle vergangenen und künftigen Nachrichten lesbar, Sender-Identität beweisbar OTR: 1. Verschlüsselung mit Perfect Forward Secrecy - Diffie-Hellman- Schlüsselaustausch für kurzlebige Keys (werden regelmäßig verworfen und erneuert) 2. Digitale Signatur - mit Public/Private Key aber nur für das DH Shared Secret 3. Message Authentication Codes - MAC Key wird aus DH Shared Secret generiert - nach Benutzung veröffentlicht > Repudiability / Abstreitbarkeit 4. Malleable Encryption - Strom-Chiffre > Modifikation einer Nachricht nicht nachweisbar (nur für Empfänger durch MAC) OTR in den meisten -Clients als Verschlüsselung verfügbar verschlüsselt nur den Payload der Nachricht! 2. 52

53 Zusammenfassung Presence Presence Service, Presentity Watcher - Fetcher/Subscriber Presence Information, Watcher Information Access Rules, Visibility Rules Instant Messaging Sender, Instant Message Service, Instant Inbox, Delivery Rules Architekturen: direkt, Server, Mehr-Server allgemein Architektur (permanente Verbindung), direkte Föderation DNS, JIDs Verbindungsaufbau Message Message Formatierung Chat State Notifications Full JID vs. Bare JID Presence Subscription Handshake Priority Routing Temporary Subscriptions IQ get/set result/error Beispiele: Roster, vcard Security SASL, TLS, Blockieren/Filtern, OTR 2. 53

54 Navigator 1. Einführung Erweiterungen 4. Codierung und Transport 5. Internettelefonie 6. Videokonferenzen 7. Streaming 8. SIP 9. SIP-Erweiterungen 10.Data Sharing 11.Shared Editing 12.WebRTC 2. 54

55 Literatur : The Definitive Guide, Building Real-Time Applications with Jabber Technologies, By Peter Saint-Andre, Kevin Smith, Remko Tronçon (Kapitel 1-4) Standards Foundation - P. Saint-Andre [Ed.], Extensible Messaging and Presence Protocol (): Core, P. Saint-Andre [Ed.], Extensible Messaging and Presence Protocol (): Instant Messaging and Presence, XEP-0085: Chat State Notifications, xep-0085.html XEP-0203: Delayed Delivery, Nikita Borisov, Ian Goldberg, Eric Brewer, Off-the-record Communication, or, why not to use PGP, ACM Workshop on Privacy in the Electronic Society,