摘要

  • 10 月 1 日更新的 MOQ 工作组草案仍将位置筛选参数标识为 0x21，但紧随其后的字段由第 21 版的 Length 变成第 22 版的 Location Filter Type。0x00 到 0x05 分别规定后续字段与筛选形态；其他类型值构成 PROTOCOL_VIOLATION。
  • 草案自己的修订记录把这项变化列在会话与控制平面；暂停订阅的重新表述则列作编辑性澄清。文件仍是活跃 Internet-Draft，并非正式 RFC，更不是任何生产故障的调查结论。

先看一条普通请求：订阅者要求从某一组、某一对象开始收取实时内容。QUIC 连接建立成功，只说明双方能交换消息；中继是否从正确位置送出对象，取决于它如何解析那段筛选参数。第 22 版改动的正是这道解析关口。若只拿“连接在线”作为验收凭据，数据范围错位可能被掩盖。

第 21 版的 LOCATION_FILTER 写法是参数类型 0x21，接一个可变长整数 Length，再接零至四个可选整数。长度按字节计算，接收者用它判断后面到底有几个字段。长度为零表示无筛选；两个字段都为零时，又代表“下一个对象”。相对起点、绝对起点和区间范围，则依字段个数及值作区分。这不是视频画质指标，而是控制消息的线路格式。

第 22 版把第二个整数用于直接命名筛选形态。0x00 表示无筛选；0x01 表示相对起点；0x02 是绝对起点；0x03 带组结束边界；0x04 给出完整绝对区间；0x05 表示下一个对象，而且无需再跟随两个零值。类型决定哪些整数合法出现。未定义的类型不是可以随意跳过的扩展，而是协议违规。它没有把对象的内容交给某个新机构裁定，只是消除了对格式形态的隐式猜测。

这个参数可出现在 FETCH、SUBSCRIBE、PUBLISH、订阅的 REQUEST_UPDATE 和 PUBLISH_STATE_NOTIFY 中。中继若一边接受订阅，一边向上游发起请求，至少需要证明两侧按各自协商的草案版本理解同一选择意图。这是一项从规范差异引出的运营建议，而非草案报告了某家中继已发生解析错误。

版本隔离同样不能忽略。草案说明，QUIC 上以 ALPN、WebTransport 上以相应协议机制协商 MOQT 版本，草案版本有各自临时标识。因此不能仅凭两版字段不同，就断言合规端点一定会混发旧新格式。真正该查的是：会话声称使用哪一版、运行的解码器是哪一版、请求选择的对象与收到的对象是否一致。

修订记录还给新闻边界划了线。LOCATION_FILTER 的显式类型是从 21 到 22 版单列的控制平面变化。暂停订阅、FETCH 缺口与命名结构的改善被列在“显著编辑变更”下；它们值得阅读，却不宜写成 10 月才发明的功能。报道这次更新，核心事实应当是位置筛选的线路编码发生了可验证的变动。

来源