SPECIFICATION

第 1 章概要とプロトコル定位

本章では、DTP のプロトコルの範囲（§1.1）、プロトコル定位（§1.2）、CAP との関係（§1.3）、設計目標（§1.4）、マスタースレーブモデル（§1.5）、一致性レベル（§1.6）を定め、§1.7「バージョン管理と互換性」では DTP のバージョン管理規則を規範的な形で示す——これにより本プロトコルは自身のバージョン説明を備え、標準実装者が外部ドキュメントを検索することなく直接参照できる。

1.1 プロトコルの範囲

データトンネルプロトコル（DTP）は、iFay エコシステムにおいて端末デバイスと Fay インスタンスの間の双方向データ伝送を担当するアプリケーション層プロトコル であるべきである。

DTP は以下の 2 つのコアデータフローを実装 しなければならない：

データ収集（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 に基づいて行われなければならない
データ主権	Master はデータフローに対する最終決定権を有さなければならない
エンドツーエンド暗号化	ペイロード（Payload）は暗号化して伝送しなければならない
コンテキスト保全	各 Fragment は構造化されたコンテキストメタデータを保持しなければならない
復旧可能性	実装はシーケンス番号ベースの再開機構をサポートしなければならない

1.5 マスタースレーブモデル

DTP は以下の 2 つの役割を区別 しなければならない：

Master（マスター）：自然人ユーザまたは Fay（iFay / coFay）。データ収集の発起権およびデータ注入の決定権を有 さなければならない。
Slave（スレーブ）：ソフトウェアまたはハードウェア端末。データ注入の申請のみ発起可能であり、データ収集要求を発起 してはならない。

DTP 実装は以下の制約を強制 しなければならない：

任意の時点において、1 つの Slave は複数の Fay を Controller として同時に持つこと はできない。
Controller は他の Fay を Observer として招待 してもよい。
Observer はリクエストを発起したり Agreement を変更したり してはならない。データフローの読み取り専用コピーのみを受信 しなければならない。
Master がデータ収集要求を発起した場合、Slave は受け入れ るべきである。Slave は拒否 してもよい が、拒否にはコンプライアンス上の理由を付随 させなければならない（第 5.3.1 節を参照）。
Slave がデータ注入申請を発起した場合、Master は完全な決定権を有 さなければならない。受け入れ、拒否、または代替案を提示 してもよい。

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 章「バージョン管理」および変更履歴を含む。存在する場合）でバージョン規則に言及する箇所はすべて、本節に従わ なければならず、本節が定めた規則を再定義 してはならない。

本節は以下の固定された順序で構成される：3 つの直交バージョン軸（§1.7.1）→ MAJOR.MINOR の意味論と変更判定（§1.7.2）→ バージョンネゴシエーションと互換性規則（§1.7.3）→ 編集版次と正誤（§1.7.4）→ バージョン番号の配置表と実装者の注意事項（§1.7.5）。

1.7.1 3 つの直交バージョン軸

DTP のバージョン情報は、3 つの相互に直交する軸に沿って独立に管理され なければならない。これら 3 つの軸は単一のバージョン番号に統合 してはならない。各軸は独立した値空間、記録場所、進化規則を持ち、ある軸の変更が他の 2 つの軸の変更を強制 してはならない（直交性の観測可能な定義）。

軸	意味	値空間	記録場所	ワイヤフォーマットに入るか？
プロトコルバージョン（Protocol Version）	相互運用契約	`dtp/MAJOR.MINOR`（2 レベル、PATCH なし；`MAJOR`、`MINOR` はともに非負整数）	フレームヘッダー `protocolVersion` フィールド、schema ファイル名	はい
ドキュメントステータス（Document Status）	ドキュメントのライフサイクル	列挙 `Draft / Final / Deprecated / Obsolete`（任意の時点で正確に 1 つの値）	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 ファイル名）。
プロトコルバージョンは常にワイヤフォーマットに入ら なければならない。実装はプロトコルバージョンをワイヤフォーマットから除外する設定を提供 してはならない。
ドキュメントステータスと編集版次はワイヤフォーマットに入って はならない。実装はドキュメントステータスや編集版次に基づいてメッセージ処理の挙動を変更 してはならない——すなわち、ワイヤフォーマットが完全に同一の 2 つのメッセージは、これら 2 つの軸の値が異なることを理由に処理結果に差異を生じて はならない。
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）**ガバナンス制約であるが、その「アップグレードに偽装してはならない」の 1 条はプロトコルバージョン番号の正確性に対して拘束力を持つ。

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>-<status>`	tag は本文 + テストベクトル + schema を同時にカバーしなければならない

実装者の注意事項（必読）

相互運用性の判断は もっぱら プロトコルバージョン（MAJOR.MINOR）を見て行い、ドキュメントステータスや編集版次に依拠 してはならない。
同一の MAJOR は MAJOR.0 まで後方互換で なければならない。
正誤（編集版次）をプロトコルアップグレードとして扱って はならない。
schema ファイル名で編集版次を符号化することに依拠 してはならない。
Draft 期間中は互換性の約束はない。

完全なディレクトリとステータスの規約、および確定（Draft → Final）の標準アクションは第 10 章「プロトコル進化とガバナンス」にある。そこで言及される git tag 形式、ステータス列挙、編集版次の定義は、本節（§1.7）を規則アンカーと しなければならない。

第 1 章 概要とプロトコル定位