摘要

  • IESG 9 月 24 日议程保留 IANA #1451183：为三项 OAuth 登记寻找指定专家。9 月 17 日更新的任务表显示，此项自 4 月 30 日起跨越十次例会仍未结案。
  • 4 月 30 日会议纪要明确说的是“增补”专家；IANA 的三张现行表均仍列 Justin Richer。现有材料不支持“无人审查”或“登记冻结”的说法。
  • 读者应将任命记录、专家名录、公开邮件列表的个案审查与最终登记条目分开核对，不能用其中一项代替其余三项。

一行议程摘要有时会遮蔽制度状态。IESG 把这件事列在“需要指定专家”栏下，但行动的原始记录写明要找的是额外专家。IANA 的 OAuth Parameters 页面随后仍为动态客户端注册元数据、令牌端点认证方法、令牌内省响应三张表列出同一位现任专家 Justin Richer。因此，可确认的新闻不是空缺，而是一个跨三张表的审查能力扩充任务尚未在公开行动表里完成。

为什么不能把它当成普通人事公告？因为三张表分别决定不同的共享名称能否进入可依赖的公共目录。第一张涉及客户端注册时可提交的元数据名称；第二张是客户端在令牌端点证明自身的认证方法名称；第三张是资源服务器读取内省响应时可跨域理解的字段名称。一个新名字出现在哪张表，以及谁有权给出审查意见，都会影响其他实现能否把相同字符串解释为相同含义。但登记名称的存在，本身并不强制任何运营者部署该功能。

RFC 7591 和 RFC 7662 给出了更具体的链条：申请在 OAuth 扩展邮件列表经历两周审查，指定专家作出认可或否决并说明理由，IANA 依据专家渠道更新相应登记。邮件列表上的讨论不是已获批准的条目；专家姓名在网页上出现也不是任何个案已经完成的证明。十次例会是 IESG 寻找增补专家这项行动的历时，不能被写成某个申请排队十次例会。公开资料也没有提供积压量或现任专家表现的指标。

下一步的可检验问题非常具体：若 IESG 任命新人，决定适用于三张表的全部还是其中一部分？IANA 何时更新每张表的专家字段？面对正在审查的个案，公开列表、专家意见与最终条目能否按日期连起来？把这些节点做成一份版本化交接记录，是 Daniel Kade 的编辑建议，不是 IETF 新增的规范义务。它既不把机构的寻人流程包装成技术事故，也不让真正的职责变化淹没在笼统的“已经处理”里。

Sources