Zusammenfassung

  • RFC 7865 bezeichnet das XML-Dokument für SIPREC-Aufzeichnungsmetadaten als application/rs-metadata+xml; RFC 7866 verwendet in Verfahren und Beispielen application/rs-metadata.
  • Erratum 7987 meldete den Widerspruch im Juni 2024 und wird weiterhin als Held for Document Update angezeigt. RFC 9806 aktualisierte RFC 7866 im Juni 2025 und ersetzte jede alte Fundstelle.
  • RFC 9806 holte außerdem die von den Dokumenten aus 2016 versäumte IANA-Registrierung nach. Das heutige Register nennt application/rs-metadata+xml mit Verweisen auf RFC 7865 und RFC 9806.
  • Damit steht die aktuelle Spezifikation fest. Nicht belegt ist, was ein eingesetzter SRC sendet, ein SRS annimmt, ein multipart-Parser verarbeitet oder ein Archiv speichert.

Die Akte ist eindeutig, die laufende Technik nicht zwingend

RFC 7865 beschreibt Teilnehmer und weitere Metadaten einer aufgezeichneten Sitzung in einem SIPREC-spezifischen XML-Dokument. Als Medientyp nennt das Dokument application/rs-metadata+xml. Der im selben Monat veröffentlichte RFC 7866 definiert das Session Recording Protocol, verkürzt die Bezeichnung in Abschnitt 9 und in mehreren Beispielen jedoch zu application/rs-metadata.

Es geht nicht um zwei konkurrierende XML-Formate. RFC 7866 verweist für den Inhalt weiterhin auf RFC 7865. Der Widerspruch steckt in dem MIME-Bezeichner, mit dem Software ihren Verarbeitungspfad auswählt. Ein Empfänger kann dieselben XML-Bytes verstehen und den Body trotzdem ablehnen, weil Content-Type nicht in seiner Dispatch-Tabelle steht. Ein Sender kann korrektes SIP und XML erzeugen und dennoch den falschen Namen ankündigen.

Erratum 7987 hielt den Unterschied am 12. Juni 2024 fest. Die Seite zeigt den alten und den korrigierten Wert sowie den Hinweis, dass keiner der ursprünglichen RFCs den Typ registrierte. Ihr gegenwärtiger Status lautet Held for Document Update. Das ist nicht Verified; eine belastbare Beweiskette behält diese Bezeichnung bei.

RFC 9806 trifft die spätere formelle Entscheidung. Das im Juni 2025 veröffentlichte Standards-Track-Dokument trägt Updates: 7866, erklärt Erratum 7987 für gelöst und ersetzt sämtliche Vorkommen von application/rs-metadata durch application/rs-metadata+xml. Die normative Lesart ist geklärt. Der Zustand installierter Systeme folgt daraus nicht automatisch.

Ein Update überschreibt nicht die frühere Lektüre

Im ursprünglichen Text von RFC 7866 steht die kurze Bezeichnung weiterhin. RFC 9806 schreibt das historische Dokument nicht heimlich um, sondern ergänzt einen sichtbaren Update-Pfeil. Für Prüfer ist das wertvoll: Ausgangsaussage, Fehlermeldung und spätere Entscheidung bleiben getrennt nachvollziehbar.

Die Verteilung birgt aber Leserisiken. Wer nur RFC 7866 öffnet, kann den alten String übernehmen. Ein Inventareintrag „unterstützt RFC 7866“ sagt nicht, welche Variante implementiert wurde. Ein Errata-Collector kann den Held-Status speichern, ohne den späteren RFC zuzuordnen. Und ein Registerabgleich findet zwar den richtigen Namen, zeigt aber nicht, ob ein Release ihn jemals verwendet hat.

RFC 7865 belegt die beabsichtigte Typbezeichnung. RFC 7866 zeigt den Eintrittspunkt des Widerspruchs in den Ablauf. Erratum 7987 bewahrt Meldung und redaktionelle Behandlung. RFC 9806 liefert Update und Registrierung. Keines dieser Artefakte ist ein Verzeichnis laufender Prozesse und aktivierter Konfigurationen.

IANA schließt die Namenslücke

RFC 9806 benennt die fehlende Registrierung und stellt die Vorlage bereit. Typ ist application, Subtyp rs-metadata+xml, erforderliche oder optionale Parameter gibt es nicht. Die Kodierung folgt application/xml nach RFC 7303. Als Anwendungen nennt die Vorlage Session Recording Client und Session Recording Server, als Nutzung COMMON und als Änderungsinstanz die IETF.

Der am 20. September 2026 erfasste IANA-Eintrag enthält application/rs-metadata+xml und verweist auf RFC 7865 sowie RFC 9806. Das ist der passende Nachweis für den öffentlichen Namensraum. Er verrät nicht, ob ein Build das Token enthält, eine Option es aktiviert, ein Vermittler es umschreibt oder ein Archiv den empfangenen Wert erhält.

Auch das Suffix +xml beweist nur einen begrenzten Sachverhalt. Generische Software kann daran eine XML-MIME-Entität erkennen. Daraus folgen weder SIPREC-Schemakonformität noch die Zuordnung zur richtigen Recording Session oder eine konsistente Folge aus vollständigen Snapshots und Teilaktualisierungen.

Der operative Nachweis liegt im MIME-Umschlag

Nach RFC 7866 kann ein SRC einen vollständigen Snapshot oder ein partielles Update per INVITE oder UPDATE senden. Enthält dieselbe SIP-Nachricht zugleich SDP-Angebot und Metadaten, ist der äußere Body multipart/mixed. Ein Teil trägt SDP, der andere die Metadaten mit Content-Disposition: recording-session.

Ein Interoperabilitätsbeleg muss deshalb Methode und begrenzte Bezeichner, äußeren Content-Type und boundary, Content-Type und Content-Disposition des Teils, Hash und Namespace des XML-Bodys, Snapshot-Zustand und Peer-Ergebnis verbinden. Ein Feld „RFC 9806 unterstützt“ kann diese Daten nicht ersetzen.

Der SRS verwaltet Zustand. Er verfolgt partielle Updates in Reihenfolge und kann nach internem Zustandsverlust einen vollständigen Snapshot anfordern. Erkennt er einen syntaktischen oder semantischen Metadatenfehler, kann er die Recording Session beenden. Eine 2xx-Antwort an anderer Stelle des Dialogs beweist nicht, dass diese Kette angenommen wurde.

Auch eine gespeicherte Audioaufnahme reicht nicht. Speicherung und Wiedergabe liegen außerhalb des RFC-7866-Umfangs. Audio kann vorhanden sein, während Metadaten abgelehnt, verzögert, normalisiert oder unter einem Altwert indexiert wurden. Der Nachweis muss gespeichertes Label, Indexregel und späteres Wiedergabe- oder Exportverhalten einbeziehen.

Kompatibilität kann den letzten Altbestand unsichtbar machen

Während einer Umstellung kann es sinnvoll sein, beide Bezeichnungen anzunehmen. Alte Gegenstellen funktionieren weiter, während neue Generatoren auf den korrigierten Namen wechseln. RFC 9806 schreibt diese Politik nicht vor, und ein Erfolg unter Doppelannahme liefert weniger Information.

Akzeptieren alle SRS beide Strings dauerhaft, bleibt ein veralteter SRC unentdeckt. Schreibt ein Gateway alt in neu um, erscheint der Ursprung in nachgelagerter Telemetrie bereits korrigiert. Normalisiert das Logging vor der Aufzeichnung, verschwindet das Signal für verbleibenden Altverkehr.

Eine prüfbare Migration braucht Richtung und Ende. Neue Generatoren senden nur den korrigierten Wert. Parser akzeptieren beide nur für benannte Peers oder Kohorten. Umschreibungen halten Empfangs- und Weitergabewert getrennt fest. Jede Ausnahme hat eine verantwortliche Person und ein anhand beobachteten Verkehrs definiertes Ausstiegskriterium.

Der Korrektur-Custody-Beleg

Der hier vorgeschlagene Beleg ist eine redaktionelle Kontrolle von Daniel Kade. Er ist weder ein Feld von RFC 9806 noch eine Forderung von IETF, RFC Editor oder IANA.

Zuerst fixiert er die Dokumentenkette: konkrete Stellen der ursprünglichen RFCs; ID, Datum, Status und Austauschtext des Erratums; Kategorie, Update-Beziehung und Ersetzungsregel von RFC 9806; datierter IANA-Snapshot und Hash der Registrierungsvorlage.

Danach bindet er die Implementierung: SRC- und SRS-Produkt, Version, Build, Parser- und Generator-Modul, Konfigurationsgeneration sowie pro Richtung akzeptierte und gesendete Labels. Für den Altalias erfasst er Ablehnung, Annahme, Normalisierung oder Umschreibung samt beobachtbarer Regel.

Für die Transaktion hält er Methode, begrenzte IDs, Accept, Content-Type, boundary, Content-Disposition, Dokumenthash, Namespace, Snapshot-Zustand, SDP-Bindung und Peer-Urteil fest. Ablehnung, Snapshot-Anforderung und Sitzungsabbruch bleiben eigenständige Ergebnisse.

Schließlich schließt er das Archiv an: gespeichertes Label, Indexschlüssel, Normalisierungsregel, Exportdarstellung und Wiedergabetest. Hinzu kommen Rollout-Kohorte, Zähler für neu/alt/unbekannt, Canary, Kompatibilitätsfenster, Negativtests, Rollback-Auslöser, Verantwortliche, Alias-Ausstieg und Restnahmen.

Die Veröffentlichung beweist, dass die Regel besteht. Der Custody-Beleg zeigt, wo sie tatsächlich ausgeführt wurde.

Grenze der Beweislage

Die Quellen belegen Widerspruch, Erratum, Update und Registerzustand. Sie enthalten keine Erhebung der SIPREC-Produkte oder -Installationen, keine Anbieter-Matrix, keine Verteilung der beiden Labels und keinen dem Unterschied zugeschriebenen Vorfall. Dieser Artikel bezeichnet keine konkrete Implementierung als veraltet oder regelwidrig.

Die beschriebenen Risikopfade sind prüfbare Szenarien, keine beobachteten Störungen. Sie folgen aus sichtbaren Protokollflächen: exaktes Token, multipart-Struktur, XML-Verarbeitung, Update-Reihenfolge und Archivbehandlung. Jede Umgebung muss sie selbst testen, statt die Existenz von RFC 9806 als Laufzeitnachweis zu verwenden.

Quellen