New I-D: 2-Phase HTTP Protocol for Distributed Transaction Tracking (draft-venkateswaran-jamwal-twophp-01)

Hi all,

We've published -01 of an Independent Submission that may be of interest
to this group:

  https://datatracker.ietf.org/doc/draft-venkateswaran-jamwal-twophp/

What it is
----------

A backward-compatible, opt-in extension to HTTP that adds a two-phase
handshake at each service boundary, so that both client and server
durably register a mutation intent before any processing begins. The
registered intent is written to a queryable local ledger, allowing a
client that does not receive an expected response to inspect whether the
prior intent was registered before issuing a retry.

What it is not
--------------

This is not Two-Phase Commit. There is no cross-service locking, no
distributed transaction coordinator, no thread blocking. The "DTT" in
the title expands to Distributed Transaction *Tracking*.

Framing
-------

We do not claim novelty. Intent tracking, idempotent retries, and
correlation-based inspection are patterns implemented today across
microservices deployments, typically ad hoc and per-team. The goal of
this draft is a consistent, standardized wire contract -- HTTP header
fields plus a ledger schema -- so that a common implementation,
packaged as a library or framework middleware, can serve heterogeneous
deployments without per-vendor reinvention. The draft is compatible
with existing idempotency conventions such as `Idempotency-Key`; where
both are present, the correlation identifier defined here can carry the
same value.

Motivator
---------

The specific gap that prompted this work is retry-storm behavior in
agent-driven HTTP integrations -- MCP tool calls and agent-to-agent
workflows -- where the default retry behavior of an unacknowledged
request, in the absence of a queryable intent record, can push an
already-overwhelmed server into cascading failure. This is a
synchronous-HTTP problem; async patterns (202 Accepted + Location
polling, Prefer: respond-async, webhooks, brokers) already have durable
acknowledgement built into the wire contract and are out of scope here.

Changes from -00
----------------

- Dropped the async server-to-client callback mechanism (SSRF surface,
  delivery reliability, no operational win over what the sync path
  already provides).
- Sync-only in this revision; async explicitly out of scope by design.
- DTT-2PHP-Client-Correlation-ID is mandatory in every mode, including
  Auto-Confirm; server-generated proxy identifiers are not permitted.
- Ledger architecture moved from normative wire spec to implementation
  guidance.
- Replay policy collapsed to REJECT-only.
- Editorial: workgroup element removed (independent submission), RFC
  9110 Section 16.3.1 replaces RFC 3864 for the field-name registry.

Where we would appreciate feedback
----------------------------------

- Whether the framing (standardization of an existing pattern) lands
  correctly, or whether the draft should reposition.
- Overlap with draft-ietf-httpapi-idempotency-key -- we believe the two
  are composable, and would appreciate confirmation or objection.
- Known gaps we already have a working local -02 addressing: ABNF for
  every registered field, Phase 2 endpoint derivation contract, a
  well-known-URI-based client-facing ledger query endpoint, a Phase 1
  replay rule, and a preemptive BCP 178 note on the DTT- prefix. We
  intend to file -02 after a short review window on -01. Early feedback
  on the -01 scope is welcome while -02 bakes.

Thanks in advance for any comments.

Best Regards,
Barathan Venkateswaran, Aditya Jamwal