规范

第 1 章概述与协议定位

本章界定 DTP 的协议范围（§1.1）、协议定位（§1.2）、与 CAP 的关系（§1.3）、设计目标（§1.4）、主从模型（§1.5）与一致性级别（§1.6），并在 §1.7「版本管理与兼容性」中以规范性形式给出 DTP 的版本管理规则——使本协议自带版本说明，便于标准实现者直接查阅，无需检索外部文档。

1.1 协议范围

数据隧道协议（DTP）应当是 iFay 生态系统中负责终端设备与 Fay 实例之间双向数据传输的应用层协议。

DTP 必须实现以下两个核心数据流：

数据归集（Data Collection）：从终端（Slave）流向 Fay（Master），用于将终端产生的数据持久化到 iFay 的 Personal Data Heap。
数据注入（Data Injection）：从 Fay（Master）流向终端（Slave），用于将经 iFay 过滤后的最小化数据集临时提供给终端应用。

DTP 不得用于其他用途。

1.2 协议定位

DTP 必须作为应用层协议运行于既有传输协议之上，包括但不限于 BLE、RTSP、WebSocket、TCP。

DTP 必须通过 Transport_Adapter 抽象层与具体传输协议交互（参见第 3.4 节）。DTP 核心不得依赖任何具体传输协议的实现细节。

1.3 与 CAP 的关系

DTP 必须与控制授权协议（CAP）协同工作，遵循以下分工：

CAP 负责连接授权、身份验证与密钥交换。
DTP 负责协商式数据流传输。

DTP 实现必须在 CAP 完成身份验证与密钥交换后才开始数据传输。如 CAP 尚未就绪，DTP 实现必须拒绝发送数据并返回 KEY_NOT_READY 错误（错误码 2002，参见第 9 章）。

1.4 设计目标

DTP 实现必须满足以下设计目标：

目标	规范性要求
传输无关性	DTP 核心逻辑必须与具体传输协议解耦
协商优先	所有数据传输必须基于已达成的约定（Agreement）
数据主权	主端必须对数据流拥有最终决策权
端到端加密	载荷（Payload）必须加密传输
语境保全	每个数据片段必须携带结构化上下文元数据
可恢复性	实现必须支持基于序列号的续传机制

1.5 主从模型

DTP 必须区分以下两种角色：

主端（Master）：自然人用户或 Fay（iFay / coFay）。必须拥有数据归集发起权和数据注入决策权。
从端（Slave）：软件或硬件终端。仅可发起数据注入申请，不得发起数据归集请求。

DTP 实现必须强制执行以下约束：

在任意时刻，一个从端不得同时被多于一个 Fay 作为控制者（Controller）。
控制者可邀请其他 Fay 作为旁观者（Observer）。
旁观者不得发起请求或修改约定，必须只能接收数据流的只读副本。
主端发起数据归集请求时，从端应接受。从端可拒绝，但拒绝必须附带合规性理由（参见第 5.3.1 节）。
从端发起数据注入申请时，主端必须拥有完全决定权，可接受、拒绝或提出替代方案。

1.6 一致性级别

实现必须声明其一致性级别：

完整一致（Full Conformance）：实现满足所有 必须（MUST） 与 应（SHOULD） 规则。
核心一致（Core Conformance）：实现满足所有 必须（MUST） 规则，但可不满足部分 应（SHOULD） 规则。
不一致（Non-Conformance）：实现不满足某条 必须（MUST） 规则。声明为 DTP 的实现不得处于此状态。

1.7 版本管理与兼容性（Version Management & Compatibility）

本节为规范性（Normative）。 本节是 DTP 版本管理规则的唯一权威来源（Single Source of Truth）。正文其他位置（含第 10 章「版本管理」与变更日志，如有）凡涉及版本规则之处，必须以本节为准，不得重新定义本节已规定的规则。

本节按以下固定顺序组织：三条正交版本轴（§1.7.1）→ MAJOR.MINOR 语义与变更判定（§1.7.2）→ 版本协商与兼容性规则（§1.7.3）→ 编辑版次与勘误（§1.7.4）→ 版本号落地表与实现者须知（§1.7.5）。

1.7.1 三条正交版本轴

DTP 的版本信息必须沿三条相互正交的轴独立管理。这三条轴不得合并为单一版本号；每条轴拥有独立的取值空间、记录位置与演进规则，且一条轴的变更不得强制另外两条轴随之变更（正交性的可观测定义）。

轴	含义	取值空间	记录位置	进入线格式？
协议版本（Protocol Version）	互操作契约	`dtp/MAJOR.MINOR`（两级、无 PATCH；`MAJOR`、`MINOR` 均为非负整数）	帧头 `protocolVersion` 字段、schema 文件名	是
文档状态（Document Status）	文档生命周期	枚举 `Draft / Final / Deprecated / Obsolete`（任一时刻恰取一个值）	front matter 的 `status` 字段	否
编辑版次（Editorial Edition）	勘误与澄清	以发布日期锚定的 `YYYY-MM-DD`（如 `2025-10-25`）	front matter 的 `date` 字段与发布目录名	否

关于文档状态与目录的关键约束（完整目录约定与定稿治理流程见第 10 章，其规则锚点以本节为准）：

文档状态必须是 front matter 标记，不得编码进文件路径或目录名。
某个已发布版次当前是 Final 还是 Deprecated / Obsolete，仅由其文件的 status 字段决定，不得依据目录名判断。

1.7.2 `MAJOR.MINOR` 语义与变更判定

MAJOR（主版本）

MAJOR 用于破坏互操作的变更。判定基准：若一个严格按 MAJOR.0 旧版实现的对端会拒绝或误解新报文，则该变更为破坏互操作变更。此类变更包括但不限于：

变更权威 schema 字段的语义；
移除报文或错误码；
重定义错误码；
变更状态机的吸收态（absorbing state）。

WHEN 发生一次破坏互操作的变更，MAJOR 必须递增 1，且 MINOR 必须归零（重置为 0）。

不同 MAJOR 之间不保证互操作。

MINOR（次版本）

MINOR 用于向后兼容的增补，包括但不限于：新增可选字段、新增报文、新增错误码、新增参数、新增属性。判定基准：严格按 MAJOR.0 旧版实现的对端既不会拒绝、也不会误解新报文。

WHEN 发生一次向后兼容的增补，MINOR 必须递增 1，MAJOR 必须保持不变。在同一 MAJOR 内，较高 MINOR 必须向后兼容至 MAJOR.0。

变更判定规则（有序、可判定）

对任一变更，必须按以下顺序判定其落点，产出唯一档位：

若严格实现 MAJOR.0 旧版的对端会拒绝或误解新报文 → 判定为 MAJOR；
否则，若该变更新增了线格式可见内容（帧头/报文/错误码/参数等线上可见结构）→ 判定为 MINOR；
否则（仅文字变更、无线格式变化）→ 不变更协议版本，改用编辑版次（见 §1.7.4）。
若一处变更可同时匹配多个档位，必须取较高档位。

1.7.3 版本协商与兼容性规则

本小节为规范性。

线格式约束

仅协议版本的 MAJOR.MINOR 进入线格式（即帧头 protocolVersion 字段与 schema 文件名）。
协议版本必须始终进入线格式；实现不得提供将协议版本排除出线格式的配置。
文档状态与编辑版次不得进入线格式。实现不得依据文档状态或编辑版次改变报文处理行为——即：线格式完全相同的两条消息，其处理结果不得因这两条轴取值不同而产生差异。
IF 接收到的消息在线格式中缺失协议版本信息（帧头缺少 protocolVersion，或缺少 major / minor 子字段，或其值非非负整数），THEN 实现必须以协议错误拒绝该消息，且不得以默认或推断版本进行处理。

协商规则

WHEN 进行握手或引导（bootstrap），双方必须各自声明其支持的协议版本集合，该集合不得为空。
版本选择必须遵循：先取双方共同支持的最高 MAJOR，再取该 MAJOR 下双方共同支持的最高 MINOR。
较高 MINOR 的一方必须能够服务较低 MINOR 的对端：必须按对端声明的较低版本语义处理其报文，不得仅因对端 MINOR 较低而拒绝。
IF 双方不存在任何共同支持的 MAJOR，THEN 实现必须直接以协议错误拒绝，且不得进行尽力而为（best-effort）的降级。（该错误的具体绑定见第 10 章 VERSION_INCOMPATIBLE / 7001。）
WHEN 接收到 MAJOR 相同但 MINOR 更高的报文，实现必须以自身最高 MINOR 的语义解读已知字段并忽略不识别的可选字段，不得拒绝、丢弃或报错。

凭据与密码套件

WHEN 进行版本滚动升级，实现必须保持既有的、未过期的凭据或令牌（credentials / tokens）继续有效，不得仅因版本变更而使其失效。
WHERE 协议已具备密码套件（cipher-suite）协商机制，版本协商必须复用同一口径（各自声明、取共同最高）。

协商时序（Hello / Hello_Ack）与「会话内版本一致、不得中途切换」的操作机制见第 10 章。

1.7.4 编辑版次与勘误

本小节描述的约束为**非规范性（Non-normative）**治理约束，但其「不得伪装升级」一条对协议版本号的正确性具有约束力。

WHEN 定稿后进行纯文字勘误（订正错别字、补充示例、澄清表述、修复链接），必须保持协议版本号（MAJOR.MINOR）不变；该勘误必须由一个新的发布日期目录承载，既有的已发布目录必须保持冻结，从而旧引用与链接不得被破坏。
编辑版次应在变更日志（如有）中以 Editorial 类目登记；front matter 必须以 edition / date 字段标注其版次。
编辑版次仅允许非规范性改动，不得触及线格式语义、规范性陈述、错误码、状态机或互操作行为。
硬约束：IF 一项修改触及线格式语义，THEN 必须按 §1.7.2 递增 MINOR 或 MAJOR，且不得将其伪装为勘误（编辑版次）发布。

1.7.5 版本号落地表与实现者须知

落地表

落点	放什么	规范性约束
线信封 `protocolVersion` 字段	`MAJOR.MINOR`	仅放 `MAJOR.MINOR`，不含其他级别
schema 文件名	跟随 `MAJOR.MINOR`	不得随编辑版次重命名（保持引用稳定）
content-type	`application/dtp`	标识协议族；其 `version=` 参数仅作网关路由便利，不属于线格式语义
front matter `status` / `date`	文档治理标记	不进入线格式
git tag	`dtp-v<MAJOR.MINOR>-<状态>`	tag 必须同时覆盖正文 + 测试向量 + schema

实现者须知（必读）

判断互操作只看协议版本（MAJOR.MINOR），不得依据文档状态或编辑版次。
同一 MAJOR 必须向下兼容至 MAJOR.0。
不得把勘误（编辑版次）当作协议升级。
不得依赖 schema 文件名来编码编辑版次。
Draft 期间无兼容性承诺。

完整的目录与状态约定、以及定稿（Draft → Final）的标准动作见第 10 章「协议演进与治理」；其中涉及的 git tag 格式、状态枚举与编辑版次定义，必须以本节（§1.7）为规则锚点。

第 1 章 概述与协议定位