BLUEPRINT

第5章ネゴシエーション機構

5.1 ネゴシエーション原則

DTP のコア設計原則の1つは「ネゴシエーション優先」です：すべてのデータ伝送は双方のネゴシエーションで合意されたアグリーメント（Agreement）に基づく必要があり、「裸の伝送」は存在しません。ネゴシエーション機構は以下を保証します：

マスター端とスレーブ端がデータ伝送前に伝送パラメータについて明確な合意に達する
伝送中にアグリーメントパラメータを動的に調整可能
いずれの側もアグリーメントを主動的に終了可能

5.2 ネゴシエーションフレームタイプ

DTP は2種類のフレームタイプでネゴシエーションを完了します：

リクエストフレーム（Request_Frame）

データリクエストの発行またはアグリーメントの調整に使用され、以下の要素を含みます：

フィールド	説明
requestId	リクエスト一意識別子
requestorRole	リクエスト側のロール（master / slave）
requestType	リクエストタイプ：collection（収集）/ injection（注入）/ adjustment（調整）/ termination（終了）
targetAgreementId	調整/終了時に参照するアグリーメント ID
proposedParams	提案するアグリーメントパラメータ

レスポンスフレーム（Response_Frame）

データリクエストへの応答に使用され、以下の要素を含みます：

フィールド	説明
requestId	対応するリクエスト ID
result	ネゴシエーション結果：accepted / rejected / counter_proposal
agreedParams	承認または代替案時の最終パラメータ
agreementId	承認時に生成されるアグリーメント ID
rejectionReason	拒否理由

5.3 ネゴシエーションフロー

データ収集ネゴシエーション（Master 発行）

Master                              Slave
  │                                   │
  │── Request_Frame (collection) ────▶│
  │                                   │
  │◀── Response_Frame ────────────────│
  │    (accepted / rejected /         │
  │     counter_proposal)             │
  │                                   │

Master が Slave にデータ収集リクエストを送信し、データタイプ、伝送モード、頻度などのパラメータを指定
Slave が Response_Frame で応答：
- 承認：リクエストパラメータに従ってデータを伝送することに同意
- 拒否：コンプライアンス制約（DLP データ漏洩防止ポリシーなど）に限定され、コンプライアンス上の理由を必ず添付
- 代替案：修正後のパラメータを提案

データ注入ネゴシエーション（Slave 申請）

Slave                               Master
  │                                   │
  │── Request_Frame (injection) ─────▶│
  │                                   │
  │◀── Response_Frame ────────────────│
  │    (accepted + フィルタ後データ範囲 / │
  │     rejected /                    │
  │     counter_proposal)             │
  │                                   │

Slave が Master にデータ注入申請を送信し、必要なデータを説明
Master が Response_Frame で応答：
- 承認：フィルタ後のデータ範囲（最小化データセット）を添付
- 拒否：データを提供しない
- 代替案：異なる範囲またはフォーマットのデータを提供

5.4 アグリーメントパラメータ

双方が合意に達した後、一意の Agreement_ID が生成され、アグリーメント内容には以下が含まれます：

パラメータ	タイプ	説明
dataType	string	データタイプ識別子
dataRange	string	データ範囲の記述
transferMode	enum	伝送モード：one_time / periodic / streaming
frequency	number \| null	伝送頻度（Hz）、ワンタイムモードでは null
validityPeriod	number	有効期間（ミリ秒）
priority	enum	優先度：low / normal / high / critical

5.5 アグリーメントライフサイクル

アグリーメントは以下の状態を経ます：

negotiating ──▶ active ──▶ terminated
                  │
                  ▼
              suspended

negotiating：ネゴシエーション進行中
active：アグリーメント有効、データ伝送中
suspended：接続中断、アグリーメント一時停止
terminated：アグリーメント終了

5.6 動的調整

DTP は伝送中に新しい Request_Frame（requestType が adjustment）を送信することで、既存アグリーメントのパラメータを動的に調整することをサポートします。

典型的なシナリオ：iFay が最初にスマートウォッチに毎分1回の心拍報告を要求していたが、ユーザーがランニングを開始したことを検知した後、アグリーメントを毎秒1回の報告に動的調整する。

5.7 アグリーメント終了

Request_Frame（requestType が termination）を送信することで、アグリーメントを明示的に終了します。終了後、そのアグリーメント下のデータ伝送は即座に停止します。

5.8 マルチアグリーメント並行

DTP は単一セッション内で複数のアクティブなアグリーメントを同時に維持することをサポートします。マルチアグリーメントの直列または並列伝送は、下位トランスポートプロトコルの能力に依存します。

例：iFay がスマートウォッチと心拍データ収集アグリーメント（毎秒1回）と歩数データ収集アグリーメント（毎分1回）を同時に維持し、2つのアグリーメントは独立して動作する。

第5章 ネゴシエーション機構