Protocol for Transposed Transactions over HTTP (PTTH)
bofreq-rosomakho-protocol-for-transposed-transactions-over-http-ptth-00

Document Type Approved BOF request
Title Protocol for Transposed Transactions over HTTP (PTTH)
Last updated 2026-06-11
State Approved
Editor Yaroslav Rosomakho
Responsible leadership
Send notices to (None)
bofreq-rosomakho-protocol-for-transposed-transactions-over-http-ptth-00

Name: Protocol for Transposed Transactions over HTTP (PTTH)

Description

The HTTP protocol family provides a rich request-response facility between HTTP clients (which emit requests) and HTTP servers (which return responses). Each version of HTTP relies on a transport protocol to provide the connection – typically TCP, TLS, or QUIC. The transport also identifies a client (which initiates the connection) and a server (which accepts the connection).

In every standard version of HTTP, the transport client is also the HTTP client. This is sensible in ordinary HTTP use cases, in which the client knows how to reach the desired server, but the server does not know how or when to reach all potential clients. However, there are some specialized service architectures in which the situation is reversed:

  • The server is only intended to be accessed directly by a small number of clients.
  • The server knows how to reach these approved clients.
  • The server is not widely accessible by arbitrary clients due to security or routing constraints.

This arrangement most commonly occurs for servers that are subject to a strict transport firewall or have no fixed location. Examples include:

  • Servers that are only publicly reachable via a CDN or DDoS defense service, to avoid unauthorized access and DDoS attacks on the backend server.
  • Servers whose IP address changes frequently, and rely on an HTTP gateway to provide a stable destination for clients.
  • “Hidden services” whose server location is a secret, concealed by an anonymizing transport proxy service.
  • On-premise corporate servers, answering queries from an approved externally hosted service.
  • Untrusted clients that need access to specific resources but are not permitted to initiate outgoing connections.

An additional area of emerging use cases is fueled by advances in MASQUE that enable tunneling of arbitrary UDP and TCP flows over HTTP. Proprietary solutions such as Zero Trust Network Access services commonly reverse initiator and responder transport roles for encapsulated network flows to provide security benefits and deployment flexibility.

Currently, there are multiple proprietary or vendor-specific deployed solutions for each of these use cases. In the absence of a standard, they are served by custom protocols and software. This impedes migration between service providers and cross-vendor integration.
A previous non-WG-forming PTTH BoF was approved and successfully held at IETF 123 in Madrid. The problem space and relevant use cases were presented and thoroughly reviewed. Since that BoF, proponents have prepared a proposed charter for a PTTH working group.

Required Details

  • Status: WG Forming
  • Responsible AD: Mike Bishop
  • BOF proponents: Yaroslav Rosomakho <yaroslavros@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, Marius Kleidl <marius@transloadit.com>, Ben Schwartz <bemasc@meta.com>, Lucas Pardue <lucas@lucaspardue.com>
  • BOF chairs: TBC
  • Number of people expected to attend: 100+
  • Length of session (1 or 2 hours): 2 hours
  • Conflicts (whole Areas and/or WGs)
  • Chair Conflicts: TBD
  • Technology Overlap: httpbis, masque
  • Key Participant Conflict: wimse, webtrans, avtcore, ppm, privacypass, seat, quic, webbotauth

Information for IAB/IESG

This is a WG-forming BoF following a successful non-WG-forming PTTH BoF. The earlier BoF discussed use cases, problem definition, and whether the topic was worth pursuing in the IETF. This follow-up BoF is intended to determine whether there is consensus to charter this work.

The proposed PTTH working group would define a standards-track HTTP mechanism that allows a transport-level client to receive HTTP requests from a transport-level server and respond to them, under explicit agreement and control. The proposed charter is intentionally narrow and does not include defining new non-HTTP transports, server discovery mechanisms, or usage-specific policy frameworks.

The BoF should answer the following questions:
- Is there consensus that the problem is sufficiently well understood and important enough for IETF standardization?
- Is there sufficient implementation and deployment interest to justify a working group?
- Is the proposed charter scope appropriate?
- Is a dedicated PTTH working group the right venue, or should the work be handled in an existing working group such as HTTPBis or MASQUE?
- Is there consensus to form a PTTH working group with the proposed charter, subject to normal IESG review and charter refinement?

Agenda

  • Introduction and goals of the WG-forming BoF
  • Summary of the previous non-WG-forming BoF outcome
  • Brief review of problem statement and use cases
  • Presentation of the proposed PTTH working group charter
  • Discussion of scope, venue, and deliverables
  • BoF Questions