要約

  • 10月1日付の第22草案では、パラメーター番号0x21のLOCATION_FILTERで、従来のLengthに代わりLocation Filter Typeを送る。0x00から0x05までが許容される構成を指定し、未知の値はPROTOCOL_VIOLATIONとなる。
  • 改訂履歴はこの変更をセッション・制御面の変更として明記する。一方、購読の一時停止に関する記述などは編集上の整理として扱う。文書はなお作業部会のInternet-Draftであり、成立済みのRFCでも障害報告でもない。

「次のオブジェクトから」と要求したつもりの購読者に、リレーが別の位置からのデータを渡すとしたら、接続監視だけでは違いを見つけにくい。第22草案が可視化したのは、この選択範囲の解釈に関わる箇所だ。QUICのセッションが開いたことと、制御メッセージの意味が保たれたことは別に検証しなければならない。

第21草案では、0x21の後に可変長整数のLengthがあり、さらに最大四つの可変長整数が続く。バイト長を見て、後続する項目が何個あるかを判断する構造だった。長さゼロならフィルターなし、二つの項目がともにゼロなら「次のオブジェクト」を指す。相対的な開始点や絶対的な範囲も、後続項目の数と値から意味づけられた。

新しい記述では、同じパラメーター番号の直後に型を置く。0x00はフィルターなし、0x01は相対開始、0x02は絶対開始、0x03はグループの終端を伴う指定、0x04は絶対範囲、0x05は次のオブジェクトである。型に応じて必要な項目だけが続き、0x05に旧来のゼロ二個は不要だ。別の値を受けた場合はプロトコル違反になる。これは六種類のメディアを作る変更ではなく、六種類の要求形式を識別する変更だ。

影響範囲を過大にも過小にも見積もるべきではない。フィルターはFETCH、SUBSCRIBE、PUBLISHのほか、購読の更新や状態通知にも使える。一つのリレーが要求を上流へつなぐ構成なら、各区間で合意した版とパーサーの組み合わせを確かめる価値がある。ただし草案には、実際の製品で取り違えが起きたという調査結果はない。

そもそもMOQTは、QUICではALPN、WebTransportでは対応する仕組みで版を交渉する。草案番号ごとの暫定識別子も説明されている。したがって「旧版と新版の符号化が違う」ことから直ちに、適合した両端が混在した符号を無防備に交換すると断定できない。検証対象は、交渉した版、実際に使った読取処理、最終的に選ばれたオブジェクトの三点である。

付録の改訂履歴も読み分けが必要だ。位置フィルターの明示型は第21版からの制御面の項目として挙げられるが、一時停止やFETCHの説明改善は別の編集項目だ。後者を今回初めて追加された機能として報じれば、仕様の変化を誤認させる。今回の独立したニュースは、位置を指定する制御メッセージの符号化が変わった点にある。

出典