要約

  • Sent は、メッセージ由来のデータが下位プロトコルスタックに渡り、API の責任ではなくなった時点を示す。
  • その時に実際に送出されたのか、カーネルやインターフェースのバッファにあるのかは実装依存であり、イベントだけから相手への到達は導けない。

利用者が見る画面では「送信しました」という一語が便利である。しかし運用上、その一語は再送の停止、障害の終結、契約上の通知完了まで左右し得る。だからこそ、誰が何を観測した言葉なのかを残す必要がある。ローカル API の記録を、遠隔サービスの行為として読み替えてはならない。

RFC 9622 はこの点を意図的に狭く定める。2025 年の Standards Track 文書で、Colin Perkins を含む著者らは、アプリケーションと Transport Services System の間の抽象 API を記述した。Send の後の Sent は、メッセージから得たデータが基底プロトコルスタックへ下り、またはそこを通過し、API の責任でなくなった時に起きる。だが、実際の送信、ネットワークインターフェースのバッファ、カーネルのバッファなど、正確な位置は実装ごとに異なる。

RFC 9621 の設計も同じ境界を支える。選択、接続、メッセージの各プロパティについて、アプリケーションは要件・禁止・選好を表せる。しかし経路とプロトコルの選択にはシステムの方針とヒューリスティックも入る。優先度は送信側だけで使われることもあり、RFC 9622 はその表現がどう実現されるかを保証しない。

Expired と SendError は別のローカルな事実を与える。前者は Lifetime 内に送られなかったこと、後者は大きすぎるメッセージ、下位スタックの失敗、矛盾するプロパティなどを示す。Lifetime さえ「期限後には絶対に送られない」という約束ではなくヒントである。これらは相手のアプリケーションが読んだか、処理したかを証明しない。

送達や効果を語るなら、次の境界ごとに証拠を取るべきだ。API への呼び出し、ローカルな引き渡し、出力の観測、相手のトランスポート、相手のアプリケーション、そして業務上の結果。Sent はその鎖の一つを明確にする。それ以上の意味を与えないことが、かえって監査を強くする。

Sources