Zusammenfassung

  • RFC 5365 definiert einen SIP-Dienst für Pager-Mode-Instant-Messaging. Ein MESSAGE trägt eine flache URI-Liste und den Payload; ein spezialisierter B2BUA erzeugt daraus je Empfänger eine neue MESSAGE-Anfrage.
  • SIP-URIs dürfen Header-Komponenten tragen, die der Dienst einzeln berücksichtigen kann. Ein besonderes body-hname liefert keinen alternativen Payload, und ein Methodenparameter darf den Dienst nicht zu INVITE oder einer anderen Methode machen: Er sendet ausschließlich MESSAGE.
  • Führung braucht deshalb eine Autoritätsgrenze zwischen Eingabedaten und ausführbarem Dienstvertrag. Ebenso getrennt bleiben Payload, neue Transaktion, Privacy, P-Asserted-Identity, Credential-Realm, kryptographische Zielgruppe, Empfängerhistorie und Zustellung.

Daten durften Verhalten beschreiben, nicht Autorität schaffen

Eine URI ist mehr als eine Zeichenkette. Sie kann Komponenten enthalten, die eine Verarbeitung präzisieren. Gerade deshalb muss ein Dienst entscheiden, welche Teile in seinem Vertrag liegen und welche keine Wirkung entfalten dürfen.

Der Client von RFC 5365 sendet einen multipart MESSAGE mit flacher Liste nach RFC 4826 und dem eigentlichen Nachrichtenteil. Er verlangt Unterstützung für recipient-list-message. Der Server expandiert die kanonischen Ziele und erzeugt für jedes eine eigene Anfrage.

Eine URI kann nach dem Fragezeichen Header-Komponenten enthalten. Ein Accept-Contact-Wunsch lässt sich etwa zielbezogen berücksichtigen. Der Dienst darf solche Komponenten einzeln prüfen; ihre bloße Anwesenheit ist keine Garantie, dass sie übernommen werden.

Das spezielle hname body darf keinen zweiten, versteckten Nachrichtentext einschleusen. Ein Dienst kann es verwerfen. Andernfalls hätte ein Listeneintrag die Macht, den vom Absender geprüften multipart Payload zu überlagern.

Die Methode gehörte dem Dienstvertrag

Noch schärfer ist die Regel für den method-Parameter einer URI. Selbst wenn dort eine andere SIP-Methode genannt ist, erzeugt der MESSAGE-Listendienst nur MESSAGE und muss den Parameter ignorieren.

Das schützt nicht nur Implementierungsreinheit. Eine INVITE-, SUBSCRIBE- oder andere Aktion hätte andere Folgen, Berechtigungen und Missbrauchsflächen. Wer eine Empfängerliste liefern darf, erhält dadurch nicht die Befugnis, beliebige Aktionen gegen diese Empfänger auszulösen.

Die Ausführung sollte deshalb für jede Komponente festhalten: gesehen, normalisiert, zugelassen, abgelehnt oder ignoriert, mit der angewandten Regel. Nur die fertige Anfrage zu speichern verschleiert, ob ein Header aus Listendaten, Dienstpolitik oder einem späteren Proxy stammt.

Diese Grenze folgt dem Prinzip minimaler Autorität. Das gemeinsame Format bleibt erweiterbar, ohne dass unbekannte oder bösartige Parameter die semantische Kontrolle übernehmen.

Der B2BUA schuf eine neue Protokollhandlung

RFC 5365 nennt den Dienst einen spezialisierten B2BUA. Eingangsseitig ist er Server, ausgangsseitig Client. Er verlängert nicht transparent eine Transaktion, sondern originiert eine neue Handlung für jeden Empfänger.

Er sollte einen neuen To-Wert, eine neue Call-ID und einen getrennten CSeq-Zähler erzeugen. Er initialisiert Max-Forwards und setzt sein eigenes Via. Die Request-URI bezeichnet nun den konkreten Empfänger statt des Listendienstes.

Diese Felder belegen, dass Dienstautorität praktisch ausgeübt wurde. Call-ID und CSeq identifizieren und ordnen, Via führt Antworten zurück, Max-Forwards setzt ein neues Schleifenbudget. Gleicher Payload bedeutet nicht gleiche Transaktion.

Eine interne Execution-ID verbindet Eingang, kanonische Empfänger und Versuche. Die eingehende Call-ID darf nicht als universeller Schlüssel missbraucht werden; die ausgehenden IDs dürfen zugleich ihre gemeinsame Ursache nicht verlieren.

Sichtbarer Absender und behauptete Identität blieben verschieden

Der From-Wert soll unter Beachtung von Privacy erhalten bleiben. Das From-Tag wird nicht so kopiert, als bliebe derselbe Dialog-Endpunkt bestehen. Ein gemeinsam betriebener Privacy-Dienst hat Vorrang.

Damit kann Bob Alice als Gesprächsautorin sehen, obwohl der Listendienst die konkrete Anfrage erzeugte. Die Anzeige beweist keine Ende-zu-Ende-Authentisierung.

P-Asserted-Identity folgt einer anderen Regel. Kam die Behauptung aus vertrauenswürdiger Quelle und ist der erste Ausgangshop ebenfalls vertrauenswürdig, muss sie weitergegeben werden. Führt der Weg bei verlangter Privacy zu einem nicht vertrauenswürdigen Hop, darf sie nicht enthalten sein.

Der Dienst kann selbst eine PAI erzeugen, wenn er authentifiziert und die Identität auf eine SIP- oder SIPS-URI abbilden kann. Dann ist er Behauptender. Ein Audit benötigt Quelle, Authentisierung, Mapping, Privacy, Eingangs- und Ausgangsvertrauen sowie die konkrete Entscheidung.

Credentials folgten dem Realm, nicht dem Text

Authorization und Proxy-Authorization beantworten eine Challenge eines Realms. Gehört dieser Realm zum MESSAGE-Listendienst, sollen die Werte nicht in die Anfrage an Bob kopiert werden. Das Secret öffnete die Grenze des Vermittlers, nicht jede folgende Grenze.

Bezieht sich das Feld auf einen anderen Realm, verlangt RFC 5365 die entsprechende Kopie. Die Entscheidung ist weder allgemeines Löschen noch allgemeines Durchreichen.

Logs sollten keine rohen Credentials enthalten. Typ, Realm-Klassifikation, nicht umkehrbare Referenz, Entscheidung und Zielkontext reichen. So bleibt die Entscheidung beweisbar, ohne ein neues Secret-Archiv zu schaffen.

Der Payload kann identisch bleiben, während Authentisierungsautorität endet oder neu beginnt. Genau diese Unabhängigkeit muss das Datenmodell bewahren.

Ein Sicherheitskörper hatte seinen eigenen Adressaten

Ein multipart MESSAGE kann einen S/MIME- oder anderen Sicherheitskörper enthalten, der für den Listendienst verschlüsselt ist. Empfänger können ihn nicht notwendigerweise entschlüsseln. Der Dienst darf ihn deshalb nicht in die Ausgangsanfrage kopieren.

Übrige Text- oder Bildkörper werden grundsätzlich kopiert. Bleibt nach Entfernen von Liste und dienstbezogenem Sicherheitsmaterial nur ein Körper, wird der multipart/mixed-Wrapper entfernt.

Die semantische Nachricht kann gleich sein, obwohl Gesamtbytes, MIME-Grenzen und Dispositionen wechseln. Prüfen muss man je Teil: Medientyp, Hash, Zielgruppe, erlaubte Transformation und Grund für Entfernung oder Ergänzung.

Eine Vollpaket-Prüfung würde normgerechte Rekonstruktion ablehnen. Ein reiner Textvergleich würde Anhänge oder Sicherheitsbeziehungen übersehen.

Empfängerhistorie war eine erzeugte Sicht

Der Dienst kann recipient-list-history nach den Regeln von RFC 5364 erzeugen. To, Cc, Bcc und anonymisierte Einträge werden unterschiedlich behandelt. Die Historie ist daher keine unveränderte Ursprungsliste.

Sie wird für einen konkreten Empfänger konstruiert und sollte für ihn verschlüsselt werden. Bobs Sicht kann korrekt sein, während Carols Sicht andere zulässige Informationen enthält. Die Zustellung des Textes beweist nicht die Vertraulichkeit der Teilnehmerbeziehungen.

Zu speichern sind Listenstand, Copy-Control-Regel, sichtbare und ausgeschlossene Einträge, View-Hash, Empfänger und Schutz. Das ist ein eigener Beleg neben Payload und Transaktion.

202 bestätigte nur Annahme und Versuch

Auf die Eingabe antwortet der Dienst mit 202 Accepted. RFC 5365 warnt ausdrücklich, dass dieser Status nichts über erfolgreiche Zustellung der erzeugten MESSAGE-Anfragen aussagt. Er bestätigt Eingang und die Absicht, es zu versuchen.

Nachgelagerte Routen, SIP-Antworten, Anwendungsquittungen und Nutzerwirkung benötigen eigene Beobachtungen. Den 202-Zähler als Zustellquote zu beschriften, macht aus einer korrekten asynchronen Antwort eine falsche Behauptung.

RFC 5363 behandelt die Mehrzahl von Ergebnissen benachbart. Hier liegt die eigene These davor: Der Dienst entscheidet bereits Methode, Header, Identität, Credentials und Körper, bevor ein individuelles Ergebnis entstehen kann.

Der Registry-Eintrag verlieh keine Laufzeitautorität

IANA registriert recipient-list-message und verwandte Dispositionen. Gemeinsame Namen ermöglichen Aushandlung und Parsing. Sie belegen nicht, dass eine Instanz Eingabeparameter sicher begrenzt, Privacy respektiert oder Nachrichten zustellt.

RFC 5365 erschien im Oktober 2008 auf dem Standards Track. RFC 3851 wurde in der S/MIME-Linie einschließlich RFC 8551 abgelöst. Aktuelle Implementierungen brauchen aktuelle Kryptographie, während die Grenze zwischen geschütztem Objekt und Zielgruppe bleibt.

Lu Hengs Minimum Initial Specification dient als offengelegte Linse: Nur der kleinste gemeinsame Vertrag wird standardisiert; lokale Entscheidungen bleiben bei Akteuren mit lokaler Information. Reality Layers erinnert daran, dass ein Symbol wie URI-Parameter, Hash oder 202 nicht selbst die operative Realität ist. Protokollfakten stammen aus RFCs und IANA.