要約

  • DTPC revision 00では、Topicに登録されたアプリのelisionFnが、送信キュー内で古くなったデータを新しいデータに置き換えられる。
  • Data PDUとAck PDUの記載フィールドには削除理由や新旧対応がないため、送信系列の確認をエリジョン判断の正当性と同一視できない。

失われたのではなく、送らないと決められた

9月27日付の Delay-Tolerant Payload Conditioning は、BPv7の上、アプリの下に置くサービス層を提案する個人Internet-Draftである。IETFの正式な支持も、WG文書としての地位もない。

revision 00 は、順序制御、集約、エリジョン、ACK/NAKによる再送、重複抑止を別々の機能として並べる。同じ宛先とProfileを持つADUはキューで待ち、サイズ上限またはタイマーによってまとめて送られる。

ここでdtpc_openを使うアプリは、Topic IDの決定的なハンドラとして登録され、エリジョン用コールバックを渡す。新しいデータが入ると、コールバックは古いPDUを「陳腐化した」「置換された」と判断してキューから除ける。これは経路上の損失ではない。バンドルが生まれる前の意味判断である。

位置や温度のスナップショットなら最新値だけで足りる場合がある。しかし命令、差分、警報、課金記録は到着順が新しいだけでは旧項目を無効にしない。どのフィールドが同じ対象を表し、どの変化なら上書きできるかはアプリの責任範囲だ。

ACKが説明できる範囲

ドラフトが列挙するData PDUの要素は、種別、フラグ、Topic ID、Profile ID、系列番号、長さ、ペイロードである。Ack PDUはTopicと系列範囲を扱う。削除理由、ルール版、先行項目、置換先、判断時刻は列挙されていない。

RFC 9171 の受信・転送・配送状態は、すでにバンドルとなった対象についての事実であり、成包前の削除を観測できない。RFC 9172 の完全性・機密性保護も、残ったブロックを守るもので、消した判断を正当化しない。RFC 9758 のipn番号体系に対する129番の要求も、登録済みや実装済みを意味しない。

したがって送信側には、意味キー、ポリシー版、除去対象、置換対象、判断主体、時刻、対応する最終Data PDUを結ぶ小さな記録が必要になる。機密性を守るため本文を長期保存せず、ハッシュや限定メタデータで再検証可能にする設計も選べる。

Running-Code Primacy の観点では、仕様上の能力、実キュー、送信記録、宛先アプリ状態は別々に確かめるべきだ。最小仕様と局所的な将来判断 は共通記録を可能にしても、陳腐化の意味を中央化しない。権威と信念の議論を当てはめれば、ACKに書かれていない判断までACKの権威に含めてはならない。