摘要

  • 10 月 28 日的个人草案用活动、对话、任务、资源和关系五类对象串起跨机构工作，并把实际发生的全部工作、参与者自己保存的关联、某一协议正式管理的关联分开。
  • 要不要把新对话纳入管理范围由参与者决定；一旦接受了某条受管理关联，就得维护相关变动或明确报出失败。未入该协议的私下分支，不会凭空替那条协议背责任。

门可以关，交接单不能吃掉

草案举了一个很具体的场景：最初的需求变了，相关任务正在 D2、D3 两段对话中执行。变动须沿着已经建立的 D1—D2—D3 关联传下去；与之无关的 D5 不用收到群发。问题不是让每名参与者看见整项活动，而是谁答应照看哪一段连接。

这段连接常常只是一张本地映射表。D1 里的任务编号无法自动对应 D2 的任务编号；能看见两侧的中间人必须保住对应关系，或在边界上转换标识。缺了它，上游看到“同一项目”四个字，下游却不知道新要求该改哪项工作。

草案允许 B 私下委托 C，不把 C 的对话登记进上游使用的关联协议。B 可以自己保存桥接关系，不公开 C 的身份。协议不能向未加入的 C 征收维护义务；B 对自己已经接手的 D1—D2—D3 关联仍须负责。保密是一种边界选择，不是擦掉旧承诺的橡皮。

传递关联资料也不实行连坐。中间人可传活动引用，却不传客户身份、私有政策或全部聊天记录；收到资料的一方无需把它原样转发给所有人。若保留得太少，负责交接的人已经无法建立必要关联，草案要求明确失败，不让任务无限期挂起。拿着关联编号也不等于拿到了指挥权。

IETF 记录仍将它列为个人草案。它提出信息模型，尚无网络消息格式或部署结果；“失败可见性与有限问责”一节甚至还写着 TBD。下一步值得看的，是谁接受了哪条关联、需求变更怎样过桥、桥塌时上游究竟能看到什么。

来源：草案原文；IETF 状态。