Zusammenfassung

  • RFC 5196 erweitert PIDF um dynamische Dienst- und Gerätefähigkeiten, damit ein Watcher vor dem Kontakt besser wählen kann. Die Erweiterung ersetzt ausdrücklich keine Medienaushandlung wie SDP.
  • Wer Merkmale zwischen Person, Dienst und Gerät vererbt oder mehrere Quellen glättet, muss Subjekt, Herkunft, Gültigkeit, Autorisierung und Konfliktentscheidung erhalten; die Live-Sitzung beginnt eine eigene Beweiskette.

Eine Eigenschaft braucht ein Subjekt

Die Motivation ist unspektakulär und wichtig. Eine Kontakt-URI in PIDF verrät nicht immer, ob ein Tuple Sprache, Video, Nachrichten oder einen anderen Dienst bezeichnet. RFC 5196 übernimmt Fähigkeitsmerkmale aus RFC 3840 und ordnet sie in das Personen-, Dienst- und Gerätemodell von RFC 4479 ein.

Gerade diese Ordnung verhindert die bequeme Vererbung. Eine Dienstfähigkeit beschreibt einen Dienst. Eine Gerätefähigkeit beschreibt ein Gerät. Keine davon beweist automatisch, welches Endgerät die nächste Einladung annimmt. Wird das Subjekt entfernt, sieht ein Merkmal allgemeiner aus, als es je veröffentlicht wurde.

Ein Videomerkmal darf daher nicht über die Person an alle Geräte verteilt werden. Umgekehrt bedeutet ein Gerät ohne veröffentlichtes Video nicht, dass kein anderer Dienst des Presentity Video anbieten kann. Das Datenmodell ist keine Zierde; es ist die Grenze, die falsche Universalität verhindert.

Sichtbar für wen?

Auch innerhalb desselben Subjekts gibt es nicht zwingend eine globale Wahrheit für alle Beobachter. Ein Presentity kann eine tatsächlich vorhandene Fähigkeit nicht veröffentlichen. RFC 5196 nennt den Fall, dass Sprache unterstützt wird, der Nutzer dies aber nicht offenlegen möchte. Autorisierungsregeln oder ein Presence-Server können Informationen begrenzen oder verändern.

Eine fehlende Angabe ist deshalb keine ausdrückliche Ablehnung. supported enthält eine positive Aussage, notsupported eine negative. Das Dokument rät davon ab, irrelevante Negativlisten vollständig auszuschreiben. Steht derselbe Wert in beiden Gruppen, darf der Watcher Unterstützung annehmen.

Diese Konfliktregel macht die Ansicht nutzbar, aber nicht vollständig. Ein Client, der fehlende Werte in false umwandelt, erfindet eine Aussage. Ein Cache, der die für Watcher A gefilterte Ansicht an Watcher B weitergibt, trennt den Wert von der Autorisierung, die ihn hervorgebracht hat.

Aggregation ist eine Entscheidung

Mehrere Publication Agents können Beiträge liefern: Schreibtischtelefon, Mobiltelefon, Desktop-Client und Policy-Dienst. RFC 5196 weist darauf hin, dass die Kombination mehrerer Presence-Quellen Informationen verlieren oder Abweichungen erzeugen kann.

Die Vereinigung aller Merkmale konstruiert möglicherweise ein Gerät, das es nicht gibt. Der Schnitt verbirgt möglicherweise genau das Endgerät, das antworten würde. „Neuester Wert gewinnt“ setzt vergleichbare Uhren und dasselbe Subjekt voraus. Der Aggregator muss deshalb zu jedem Ausgabewert seine Eingaben, deren Subjekte, Versionen, Veröffentlichungs- und Ablaufzeiten sowie die angewandte Konfliktregel erhalten.

Nur das Endergebnis zu speichern, verschiebt Autorität zum Aggregator. Später lässt sich nicht mehr unterscheiden, ob eine falsche Auswahl von der Quelle, einer Datenschutzregel, einer Servertransformation, der Komposition oder einem Watcher-Cache stammt.

Hinweis vor der Sitzung, nicht Ergebnis der Sitzung

Der Geltungsbereich des RFC beschreibt die Information als Hinweis auf Präferenzen, Bereitschaft und Fähigkeiten vor dem Kontakt. Er stellt ebenso klar, dass sie SIP-Medienverhandlung wie SDP nicht ersetzt. Presence darf eine Einladung beeinflussen. SIP-Antwort, SDP-Offer und -Answer bestimmen, was die konkrete Sitzung vereinbart.

Die Zeit kann die beiden Aussagen weiter trennen. Ein Gerät wird ersetzt, ein Client startet neu, eine Policy ändert sich oder ein Dokument bleibt im Cache. RFC 5196 verlangt keine vollständige Übereinstimmung von Presence und tatsächlicher Fähigkeit; Watcher sollen diese auch nicht erwarten.

Unvollständige oder falsche Information kann daher eine mögliche Kommunikation unterdrücken oder einen unmöglichen Versuch auslösen. Das sind symmetrische Fehler. Sie entstehen, wenn aus einer begrenzten Prognose entweder ein Verbot oder eine Zusage wird.

Der minimale Nachweis

Für einen Presence-Wert sollten Presentity, Watcher und Subscription, Tuple/Dienst/Gerät, Publication Agent, Quellversion, Veröffentlichung, Ablauf, exakter Wert sowie positiver, negativer oder nicht offengelegter Zustand feststehen. Hinzu kommen Autorisierungsregel, Servertransformation, Kompositionseingaben, Konfliktentscheidung und Hash der tatsächlich gelieferten Ansicht.

Danach beginnt eine zweite Kette: Welche Anzeige beeinflusste die Einladung? Welche URI und welches Endgerät wurden gewählt? Was ergaben SIP-Anfrage und -Antwort, SDP-Offer und -Answer, ausgehandeltes Medium, menschliche Bereitschaft und beobachtetes Resultat? Die Ketten werden verknüpft, nicht ineinander überschrieben.

Dieser Nachweis ist eine betriebliche Folgerung, keine neue Drahtanforderung an RFC 5196. Er folgt Heng Lus Disziplin der Realitätsebenen: Ein Symbol muss dem laufenden System untergeordnet bleiben. Dienst- und Gerätefähigkeit helfen bei der Auswahl, solange das Inventar nicht so tut, als habe es bereits verhandelt.

Sources

  1. RFC 5196 als HTML
  2. RFC 5196 als Text
  3. Informationsseite zu RFC 5196
  4. IETF Datatracker: RFC 5196
  5. Historie von RFC 5196
  6. Referenzen von RFC 5196
  7. Errata zu RFC 5196
  8. RFC 3840
  9. RFC 3863
  10. RFC 4479
  11. RFC 3859
  12. RFC 4566
  13. RFC 3261
  14. RFC 2778
  15. RFC 3856
  16. RFC 3903
  17. RFC 5025
  18. Heng Lu — Realitätsebenen und symbolische Macht
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — Vorrang laufenden Codes