Summary

  • PTTH lets a transport client open a channel that can carry later HTTP requests from a proxy to the worker.
  • The proposed charter treats authentication and request authorization as core work; an outbound connection alone grants no blanket access.

The backend opens the connection. Then the proxy calls it back.

That is the promise of Protocol for Transposed Transactions over HTTP, or PTTH: a worker behind a restrictive firewall initiates an outbound connection to a proxy, which can then send HTTP requests through the established channel. The network-side client receives those transposed requests in the HTTP-server role.

The trick can spare operators from opening inbound ports for every worker or pinning every backend to a fixed address. It also moves the hard decision. Once the channel exists, what may the proxy ask this worker to do?

A proposed IETF working-group charter now under external review is scheduled for the IESG telechat on 5 November 2026. As of 2 November, it remains a proposal; no PTTH standard has been approved.

At IETF 123 in July 2025, presenters described hidden backends, dynamic CDN scaling, request prioritization, Zero Trust access and using HTTP to carry other traffic. These cases do not need the same control surface. A CDN worker receiving a few approved paths is a smaller proposition than a general-purpose tunnel.

The meeting record captured the power question. Participants warned that a worker able to push configuration to a proxy might gain influence over request routing. They questioned authentication, whether a worker could claim only part of a URL space, and when an HTTP channel used for unrelated protocols stops being a narrowly scoped HTTP project. Room polls supported more IETF work; they did not settle scope or measure deployment demand.

At IETF 126 in July 2026, the discussion separated connection plumbing, authorization, and scaling or control. The first two were treated as essential to initial work; scaling and capacity as more deployment-specific. The concern about worker influence over proxy configuration returned.

The proposed charter now makes request authority explicit: signal willingness to receive requests, authenticate both parties, determine which requests a worker is authorized to receive, and guide routing. Whether both endpoints may send on one connection remains open. New identity systems, transports, server discovery, capacity-request protocols and changes to HTTP semantics are out of scope.

These boundaries decide whether a channel stays a channel or grows into a control plane. A connection solves reachability; it does not settle admission, routing or revocation. Vendor-specific rules leave operators with a patchwork. A standard that claims too much can turn one convenient channel into a shortcut across trust boundaries.

Review the whole tuple: authenticated worker, permitted request scope, proxy decision, expiry or revocation rule, and observable audit record. Without it, a working tunnel proves transport, not authorization.

Sources: proposed IETF PTTH charter; IETF 123 minutes; IETF 126 minutes; individual PTTH draft.