版本治理与标准演进策略

版本：v0.1　日期：2026-08-06　状态：策略定案 目的：解决"IETF 草案每 6 个月需更新 vs AIC 规范相对冻结"的矛盾。

1. 核心原则

• 规范冻结、语义演进：wire format（ASN.1 核心结构）冻结，新语义经 schemeId 注册表演进；
• I-D 快照制：提交给 IETF 的草案只放冻结快照，不追内部规范的 minor 改进；
• 版本脱钩：内部语义版本（v1.7.1）与标准版本（I-D -00/-01）各自独立，互不拖累。
• 解释性工作独立演进：实现指南、安全考量、部署剖面、注册表条目等解释性内容持续加深、独立更新，不触发核心版本变更；核心规范（ASN.1）保持最小必要内容，解释加深走伴生文档（如企业剖面、覆盖度分析、治理策略等编号系列）。

2. 版本体系

轨道	版本形式	约束	说明
内部规范	语义版本 vX.Y.Z（当前 v1.7.1）	无过期概念	唯一事实源（dev-docs/aic），自有节奏
标准提交	IETF I-D 版本（-00/-01/…）	发布后 185 天过期	只放冻结快照，独立修订周期

3. I-D 6 个月规则的应对（二选一）

1. 刷新版：到期前约 5 个月发布下一版，内容仅限澄清/编辑性修订 + 注册表条目登记，核心 ASN.1 一字不动——6 个月更新从"设计负担"变为"行政任务"；
2. 自然过期：安静期不养草案，让 I-D 过期（过期 ≠ 失败，只是从追踪器消失），需要时重新提交。

4. 语义演进路径

• 新增能力类型 / 约束类型 → schemeId 注册表演进，不修改 I-D 核心结构；
• 确需结构性变更（如预留的 agentKeyHash）→ 通过 AIC/TBS version 字段向后兼容扩展，经内部规范 major 版本评审后，再决定是否进入 I-D 新版本；
• 注册表由内部规范维护，I-D 引用注册表（命名空间/URL），不内联全部条目。

4.1 需求承接决策规则（外部需求如何落位）

收到外部需求时，按下述顺序判定，默认不修改核心结构：

1. 语义类需求（新能力类型、新约束类型、新参数语义）→ 注册表演进（新增 schemeId / capabilityId 及参数定义），不进结构；
2. 元数据类需求（附加属性、控制信息、深度/开关等）→ extensions [1] 扩展槽（如 chainDepth/maxDepth 先例）；
3. 结构类需求——仅当"容器语义"与"扩展槽"均无法承载、确需新增顶层字段时 → 经 AIC/TBS version 门控新增可选字段（向后兼容，旧证书/旧实现不受影响）。

判据：修改核心结构前，必须书面论证"Capability 容器语义与 extensions 扩展槽均无法表达该需求"；论证不成立则按 1 或 2 承接。

5. 发布纪律

1. 先完成知识产权审查，再提交/公开 I-D；
2. 内部规范在首次公开前冻结（当前 v1.7.1 即冻结候选）；
3. 公开内容保持与规范版本一致。

6. 将来提交 I-D 时的流程

1. 冻结快照导出（v1.7.1 定稿 → draft-varwof-aic-00）；
2. 到期前刷新 -01（澄清 + 注册表条目）；
3. 静默期允许过期，需要时重新提交；
4. 注册表演进独立于 I-D 修订周期。

附：决策记录

• 2026-08-06：策略定稿，写入 dev-docs/aic 作为设计注记。