要約

  • RFC 7865はSIPREC記録メタデータのXML文書をapplication/rs-metadata+xmlと定めたが、RFC 7866の手順と例ではapplication/rs-metadataとなっていた。
  • 2024年6月に報告されたErratum 7987の現在の表示はHeld for Document Updateである。2025年6月のRFC 9806はRFC 7866を更新し、古い表記をすべて置き換えた。
  • RFC 9806は、2016年の二文書が行わなかったIANA登録も補った。現行レジストリはapplication/rs-metadata+xmlを掲げ、RFC 7865とRFC 9806を参照する。
  • これで正しい仕様名は確定したが、SRCが何を送信し、SRSが何を受理し、multipart本文やアーカイブがどう扱われたかは証明されない。

文書の整合と実装の整合は別物である

RFC 7865は、参加者などの記録情報をSIPREC固有のXML文書で表し、そのメディアタイプをapplication/rs-metadata+xmlとしている。同じ月に公開されたRFC 7866はSession Recording Protocolの手続きを定義したが、第9節と複数の図で末尾を欠いたapplication/rs-metadataを使った。

二つの文書が異なるXML形式を選んだわけではない。RFC 7866も形式の定義先としてRFC 7865を参照している。食い違いはMIME対応ソフトウェアが処理系を選ぶ識別子にある。受信側が同じXMLバイト列を解析できても、Content-Typeがディスパッチ表に一致しなければ本文に到達しない。送信側も、正しいSIPとXMLを組み立てながら未登録の名前を付けることができる。

Erratum 7987は2024年6月12日にこの矛盾を記録した。ページには旧表記、修正表記、元の二RFCがメディアタイプを登録しなかったことが示されている。現在の状態はHeld for Document Updateであり、Verifiedではない。この区別を崩すと、証拠の状態そのものを書き換えることになる。

RFC 9806が後続の正式な判断を与えた。2025年6月にIETF Standards Trackとして公開され、Updates: 7866を掲げ、Erratum 7987を解決すると説明し、RFC 7866中のapplication/rs-metadataをすべてapplication/rs-metadata+xmlに置換する。現行仕様の読み方は明快になった。配備済みシステムの状態は、なお観測対象である。

更新は過去のページを消さない

RFC 7866の原文を開けば、今も短いラベルが残っている。RFC 9806は古いファイルを密かに改変せず、追跡可能な更新として加わった。この保存方式により、元の主張、問題報告、後の解決をそれぞれ検証できる。

同時に、証拠は複数の場所に分かれる。RFC 7866だけを読んだ開発者は旧表記を実装できる。「RFC 7866対応」とだけ記した資産台帳からは、どちらの解釈か分からない。正誤情報だけを収集する仕組みはHeldの表示を残し、解決を宣言した後続RFCとの関係を逃すかもしれない。IANAだけを調べても、正しい行があることと製品がそれを採用したことは同じではない。

RFC 7865は意図された文書タイプを、RFC 7866は矛盾が通信手順に入った場所を、Erratum 7987は報告と編集上の扱いを、RFC 9806は正式な更新を示す。いずれも稼働中プロセスの棚卸しではない。

IANAが閉じたのは名前空間の穴である

RFC 9806は、2016年の二文書が登録を行わなかったと述べ、登録テンプレートを提示した。タイプはapplication、サブタイプはrs-metadata+xml、必須・任意パラメータはいずれもなし。エンコーディングはRFC 7303のapplication/xmlに沿い、用途はSRCとSRS、利用区分はCOMMON、変更管理はIETFである。

2026年9月20日に取得したIANA Media Typesレジストリにはapplication/rs-metadata+xmlがあり、RFC 7865とRFC 9806を参照している。これは公開名称が調整された強い証拠だが、あるリリースに文字列が入ったか、設定で有効か、プロキシが書き換えたか、アーカイブが受信値を保持したかは示さない。

+xml接尾辞の意味も限定的だ。RFC 7303により、汎用ソフトウェアはXML系MIMEエンティティだと認識できる。SIPRECスキーマへの適合、正しいRecording Sessionとの対応、完全スナップショットと部分更新の整合まで保証するものではない。

修正の成否はMIMEエンベロープの中に現れる

RFC 7866では、SRCがINVITEまたはUPDATEで完全スナップショットや部分更新を送れる。SDP offerとメタデータが同じSIPメッセージに入る場合、外側はmultipart/mixedとなり、一方のパートにSDP、もう一方に記録メタデータを置く。メタデータ側のContent-Dispositionはrecording-sessionである。

したがって「RFC 9806対応」というチェック欄だけでは相互運用を証明できない。SIPメソッドと限定された識別子、外側のContent-Typeとboundary、メタデータパートのContent-TypeとContent-Disposition、XML本文のハッシュとnamespace、完全・部分の別、相手側の解析結果を結び付ける必要がある。

SRSは状態を持つ。部分更新を順序どおり追跡し、内部状態を失えば新しい完全スナップショットを要求できる。メタデータの構文または意味上の誤りを検出した場合はRecording Sessionを終了できる。別の階層で得た2xx応答を、メタデータ処理の成功証明へ読み替えてはならない。

録音ファイルの存在も同じである。保存と再生はRFC 7866の範囲外だ。音声が残っていても、メタデータが拒否、遅延、正規化され、あるいは旧ラベルで索引化された可能性がある。保存ラベル、索引規則、後の再生や出力結果まで確認して初めて経路が閉じる。

互換性は最後の旧実装を隠す

移行中にapplication/rs-metadataとapplication/rs-metadata+xmlの双方を受け入れるのは現実的な選択になり得る。旧来の相手を止めずに、新しい生成側を進められるからだ。ただしRFC 9806がその方針を要求しているわけではない。

両方を無期限に許可すれば、古いSRCは成功率の中に埋もれる。ゲートウェイが旧値を新値へ書き換えると、下流の統計は送信元まで修正済みのように見える。記録前に同じ内部値へ正規化すれば、旧トラフィックを見つける手掛かりが消える。

監査可能な移行には方向と期限が要る。新しい生成器は修正値だけを送信し、解析器の二重受理は名前を付けた相手やコホートに限定する。書き換えは受信値と転送値を別々に残す。例外には所有者と、実測トラフィックに基づく終了条件を持たせる。

修正のカストディー記録

ここで提案する記録はDaniel Kadeによる編集上の統制であり、RFC 9806のフィールドでも、IETF、RFC Editor、IANAの要件でもない。

最初に文書の鎖を固定する。二つの元RFCの該当箇所、Erratum 7987のID・日付・状態・修正内容、RFC 9806の区分・更新関係・置換規則、日付付きIANA行と登録テンプレートのハッシュである。

次に実装を結ぶ。SRCとSRSの製品、バージョン、build、解析器・生成器モジュール、設定世代、方向ごとの受理・送信ラベルを残す。旧別名を拒否、受理、正規化、書換えのどれで扱ったかと、その行動を観測可能にするルールも必要だ。

通信ごとには、メソッド、限定識別子、Accept、Content-Type、multipart boundary、Content-Disposition、本文ハッシュ、namespace、スナップショット状態、SDPとの対応、相手の結果を保存する。拒否、再同期要求、セッション終了を「録音成功」にまとめない。

最後にアーカイブの保存ラベル、索引キー、正規化規則、出力表現、再生結果を接続し、展開コホート、新旧不明の件数、カナリア、互換期間、負試験、ロールバック条件、所有者、別名廃止判断、残存例外を添える。

RFCの発行は規則の存在を証明する。カストディー記録は規則がどこまで届いたかを証明する。

証拠の境界

公開資料は矛盾、正誤情報、更新、登録状態を立証する。一方、SIPREC製品や配備の悉皆調査、ベンダー別対応表、旧・新ラベルの利用比率、差異に起因する事故記録は含まれていない。本稿は特定実装が古い、または非準拠だとは主張しない。

記述したリスク経路は試験可能なシナリオであり、観測済み障害ではない。正確なトークン、multipart構造、XML解析、更新順序、アーカイブ処理という明示された面から導いた。RFC 9806が存在することを実行証拠の代わりにせず、各環境で確認すべきである。

出典