Zusammenfassung

  • Im von Jonathan Rosenberg mitentwickelten Presence-Modell bedeutet OPEN für Instant Messaging: Die zugehörige Inbox ist bereit, eine Nachricht anzunehmen. Der Wert belegt weder Ort, Identität und Aufmerksamkeit einer Person noch deren Bereitschaft zu antworten.
  • PIDF kann mehrere Tuples enthalten, sogar OPEN und CLOSED für denselben Kontakt. RFC 4479 trennt deshalb Person, Dienst und Gerät nach dem Gegenstand eines Attributs, nicht bloß nach der Quelle, die es meldet.
  • Beobachtungsrecht, Benachrichtigung, Tuple-Provenienz, Dienstannahme, Gerätenutzung, Zustellung, Anzeige, Lesen und Antwort sind eigene Belege. Ein grüner Punkt bleibt hilfreich, solange er keine menschliche Tatsache behauptet, die nie gemessen wurde.

Grün war der Dienst, nicht der Mensch

Eine Leitstelle sucht kurzfristig einen Ansprechpartner. Das Verzeichnis zeigt einen grünen Eintrag, also erhält diese Person den Vorgang. Der Messenger nimmt die Nachricht an, doch es folgt keine Reaktion. Aus der Ereigniskette wird später: „Der verfügbare Mitarbeiter antwortete nicht.“

Der letzte Satz fügt dem Protokoll eine menschliche Eigenschaft hinzu. Der Dienst war womöglich OPEN. Ob die Nachricht gespeichert, an das richtige Gerät geliefert und sichtbar gemacht wurde, bleibt offen. Noch weniger ist bekannt, ob der Mensch anwesend war, die Mitteilung bemerkte oder reagieren konnte.

Presence-Daten sollen die Wahl eines Kommunikationswegs verbessern. Sie werden unzuverlässig, wenn eine Oberfläche ihre begrenzte Aussage in ein Urteil über Verhalten verwandelt.

OPEN begann als Zustand einer Inbox

RFC 2778 von Mark Day, Jonathan Rosenberg und Hiroyasu Sugano ist ein informatives abstraktes Modell. Es schafft Begriffe für Presentity, Presence Service, Watcher, Principal, Instant Message Service und Instant Inbox; ein vollständiges interoperables Protokoll will es nicht sein.

Im Kontext von Instant Messages bedeutet OPEN, dass die angegebene Instant Inbox bereit ist, eine Nachricht anzunehmen. CLOSED bedeutet, dass sie keine annimmt. Für andere Kommunikationsmittel kann es eine verwandte Bedeutung geben, die das Modell aber nicht festlegt.

Das Subjekt der Definition ist die Inbox. Die Aussage erfasst keine körperliche Anwesenheit, keine Tastatureingabe, keinen Blick auf den Bildschirm und keinen Willen zur Antwort. Auch die Abbildung realer Personen, Gruppen oder Software auf die im Modell verwendeten Principals bleibt außerhalb seiner Zuständigkeit.

Annahme ist zudem nicht Zustellung. Nach dem Eingang können Speicherung, Weiterleitung, Client-Benachrichtigung, Darstellung, Lesen und Bearbeitung folgen. Jede Stufe besitzt eigene Fehler und Uhren. Wer OPEN als person_available speichert, ändert nicht nur das Format, sondern den Gegenstand der Behauptung.

Ein PIDF-Dokument darf mehrere Zustände bewahren

RFC 3863 definiert das Presence Information Data Format. Eine Presence kann mehrere Tuples enthalten. Jedes besitzt einen Status und kann Kontakt, Zeitstempel, Notizen und Erweiterungen tragen. Der Basiswert lautet open oder closed.

Die Aufteilung ist nötig, wenn Daten von verschiedenen Geräten, mehreren Anwendungen desselben Geräts oder unterschiedlichen Zeitpunkten stammen. Zwei Tuples dürfen sogar denselben Kontakt führen, während eines OPEN und das andere CLOSED meldet.

Der Watcher braucht dann eine anwendungsspezifische Regel. Welches Tuple änderte sich? Sind die Zeitstempel vergleichbar? Welche Quelle und welcher Compositor waren beteiligt? Ersetzte eine spätere Nachricht die frühere? Der Standard macht aus diesem Konflikt nicht automatisch einen einzigen wahren Personenzustand.

Die id eines Tuples ist eine beliebige Zeichenfolge zur Unterscheidung und Korrelation innerhalb der Presentity. Sie ist keine Personenkennung und kein Gerätezertifikat. Ihre Verwendung als globale Identität würde ihr eine nicht vorhandene Autorität verleihen.

Ein System, das nur die berechnete Farbe speichert, kann seine Entscheidung später nicht erklären. Mindestens gehören Subscription, NOTIFY-Sequenz, Tuple-ID, Komponententyp, Kontakt, Rohwert, Quelle, Veröffentlichungs- und Empfangszeit sowie die Version der Kompositionsregel in den Nachweis.

Eine Beobachtungserlaubnis sagt nichts über Anwesenheit

Rosenbergs RFC 3856 transportiert Presence über SIP SUBSCRIBE und NOTIFY. Der Presence Agent muss Abonnementanfragen authentifizieren und anschließend gesondert autorisieren. Eine Subscription kann erfolgreich, abgelehnt oder ausstehend sein; Notifications tragen sowohl Subscription- als auch Presentity-Zustand.

Die vier Fragen sind unabhängig: Wer ist der Watcher? Was darf er sehen? Besteht die Beobachtungsbeziehung? Welche Presence-Information wurde veröffentlicht? Keine davon misst unmittelbar, ob eine Person ihren Client betrachtet.

Datenschutzregeln können Felder absichtlich ausblenden. Fehlende Gerätenutzung ist nicht automatisch Inaktivität. Das Ende einer Subscription kann den Entzug der Leseberechtigung bezeichnen, nicht das Ende aller Dienste. Wenn die Oberfläche fehlenden Zugriff als „Person offline“ rendert, macht sie aus Datenschutz eine Verhaltensbehauptung.

RFC 4479 ordnet jedes Attribut seinem Gegenstand zu

Jonathan Rosenbergs RFC 4479 gliedert eine Presentity in Person, Service und Device. Entscheidend ist, was ein Attribut beschreibt, nicht nur, welches Element es gemeldet hat.

Ein Mobiltelefon kann melden, dass der Benutzer in einer Besprechung ist. „In einer Besprechung“ gehört dennoch zur Person. Der Akkustand gehört zum Gerät. Ein erreichbarer Kommunikationspunkt gehört zum Dienst. Messquelle und semantisches Objekt müssen getrennte Felder bleiben.

Damit enden mehrere Kurzschlüsse: Ein eingeschaltetes Gerät garantiert keinen funktionierenden Dienst. Ein offener Dienst garantiert keine Gesprächsbereitschaft. Der Standort eines Geräts darf vom Standort der Person abweichen.

Auch die Person-Komponente ist nur eine Modellfassade. Das System kann nicht verifizieren, ob dahinter tatsächlich ein einzelner Mensch steht. Ein Helpdesk mit mehreren Beschäftigten kann wie eine Person modelliert werden. Die Presentity-URI ist ein Koordinationsbezeichner, kein biometrischer oder rechtlicher Identitätsnachweis.

Die Trennung verhindert keine Zusammenfassung. Eine Anwendung kann „Dienst offen“, „Gerät aktiv“ und „Person in Besprechung“ gemeinsam anzeigen. Sie darf nur die Typen und Quellen nicht aus der Akte löschen.

Jüngste Eingabe erhöht höchstens eine Wahrscheinlichkeit

RFC 4480 von Henning Schulzrinne, Vijay Gurbani, Paul Kyzivat und Rosenberg ergänzt Rich Presence. user-input kann anhand einer konfigurierbaren Schwelle active oder idle melden. Die Erfassung kann sich auf eine Anwendung oder das gesamte Gerät beziehen; der genaue letzte Eingabezeitpunkt darf fehlen.

Der Text macht die Grenze sichtbar: Ein länger unbenutztes Tuple kann weiterhin OPEN sein. Ein Watcher kann einen offenen und zugleich kürzlich benutzten Kontakt bevorzugen. Aus Dienstzustand und Aktivität lässt sich die Wahrscheinlichkeit einer Antwort schätzen.

Eine Schätzung bleibt eine Schätzung. Eingabe kann in einem anderen Programm stattfinden, von Automatisierung stammen oder eine wichtige Nachricht übersehen. Passives Lesen erzeugt vielleicht kein erfasstes Ereignis. Unterschiedliche Schwellen machen zwei active-Werte unvergleichbar.

Die Formulierungen „Dienst nimmt Nachrichten an“ und „Aktivität in den letzten zehn Minuten“ zeigen die Entscheidungsgrundlage. „Person verfügbar“ verdeckt, wer die Schlussfolgerung gezogen hat.

Auch die Zuschreibung an Rosenberg braucht Grenzen

Am 9. September 2026 führte Rosenbergs öffentliches IETF-Profil 72 RFCs und keine aktive Rolle. RFC 3856 und RFC 4479 nennen ihn als alleinigen Autor; RFC 2778 und RFC 4480 sind Gemeinschaftsarbeiten. Daraus folgt ein dokumentierter Beitrag, nicht die Kontrolle über IETF-Konsens, Implementierungen oder die Nutzer einer Presence-Anwendung.

Die offizielle Five9-Autorenseite und das öffentliche Porträt liefern die Identitätsprovenienz für das redaktionelle Bild. Ihre ältere Biografie wird nicht als Beleg einer aktuellen Position verwendet. Bildidentität und Beschäftigungsstatus sind verschiedene Aussagen.

Die Kette braucht für jedes Verb einen Beleg

Ein Watcher wurde authentifiziert. Eine bestimmte Ansicht wurde autorisiert. Eine Notification kam an. Ein Service-Tuple meldete OPEN. Ein Gerät zeigte jüngste Eingabe. Der Dienst nahm die Nachricht an. Ein Client stellte sie zu und zeigte sie. Ein Mensch las und antwortete.

Die Ereignisse können auf einer Zeitachse stehen, sind aber nicht dasselbe. Fehlt ein Glied, bleibt es unbekannt. „Dienst offen, Annahme bestätigt, Lesen unbekannt, keine Antwort“ führt zur nächsten Prüfstation. „Verfügbare Person ignorierte die Nachricht“ erfindet Absicht aus einer Farbe.

Der grüne Punkt darf bleiben. Er muss nur wieder dem Dienst gehören, den der Standard tatsächlich beobachtet hat.

Quellen