Summary

  • Mark Nottingham proposed “HTTP/3” to make the HTTP semantics-over-QUIC mapping legible as an HTTP protocol, distinct from QUIC’s transport role.
  • His message paired the name with a governance proposal: after publication, HTTP/3 and QPACK maintenance should pass to the HTTP Working Group. IETF records later document that allocation.
  • The boundary clarified responsibility; it did not make the name a technical guarantee, turn a working-group discussion into Nottingham’s personal decision, or prove that implementations had adopted the protocol.

By late 2018, one label was carrying two different ideas. “QUIC” could mean the transport protocol, or the HTTP mapping being built over that transport. Engineers who were not following the work closely sometimes treated them as the same deliverable. The confusion was more than a naming nuisance: it blurred which group was defining transport behavior and which group should own HTTP’s future.

Mark Nottingham’s October 2018 message to the QUIC Working Group proposed to call its HTTP document “HTTP/3” and use h3 as the final ALPN identifier. He described the document as another binding of HTTP semantics to a wire protocol, like HTTP/2, and said the name would help people see that it was separate from QUIC. The proposal is preserved in his message, not reconstructed from a later retelling.

He attached a second proposal to the first. Once the QUIC group had published the mapping, Nottingham suggested that maintenance of HTTP/3 and QPACK move to the HTTP Working Group. The distinction matters: a document can be drafted by one group because it depends on that group’s transport work, yet require long-term decisions from the group responsible for the application protocol. Naming the document and assigning its maintenance were connected, but they were not the same decision.

The room separated support from authority

At IETF 103, the QUIC group discussed the name. The minutes record objections and competing intuitions. Some participants saw HTTP/3 as a successor to HTTP/2; others questioned whether a new name suggested a fork. Nottingham pointed out that HTTP/2 had neither deprecated nor obsoleted HTTP/1.1, and that the important distinction was between HTTP semantics and the wire protocol beneath them.

The record describes an informal show of hands or “hum,” not a binding ballot: support for renaming was roughly 70:30, while support for letting HTTPbis decide the question was close to unanimous. That second result is the revealing one. A cross-layer protocol had emerged in QUIC work, but the naming authority belonged with the HTTP community. Nottingham’s brief intervention kept the issue attached to the group that maintained HTTP rather than making the QUIC group the permanent arbiter of HTTP identity.

He had already bounded his own role in the mailing-list message. Under a “Chair hat” note, he asked for a short discussion in Bangkok and argued against an open-ended naming contest. His reason was practical: developers and users needed a clear description of the work, while the group still had technical milestones to complete. The chair could frame a question and protect time for it; he could not substitute that framing for consensus.

A name is useful only when the layers remain visible

The eventual specification makes the distinction concrete. RFC 9114 describes HTTP/3 as a mapping of HTTP semantics over QUIC. RFC 9110 defines HTTP semantics; RFC 9000 defines QUIC as a transport. HTTP/3 uses the transport’s reliable, ordered delivery on each stream and its security properties, while retaining HTTP’s message and application meaning. The name identifies the mapping; it does not collapse the layers.

The h3 ALPN token is related but not interchangeable with the public name. It is a wire identifier selected during protocol negotiation. The public name helps people classify the specification and the work. Nottingham’s email explicitly distinguished these functions and said the name would not be formalized or used on the wire until publication. That left room to revise the proposal before an identifier could shape compatibility expectations.

The governance transfer was not left as a slogan. The 2018 HTTPbis charter said that, once QUIC published HTTP/3, HTTPbis would maintain and develop its extensions as needed, including QPACK. The current HTTP charter lists HTTP/3 and QPACK among the core HTTP specifications. The current QUIC charter says its group originated the mapping and QPACK and that these specifications are now maintained in the HTTP Working Group. In this instance, the proposed boundary became part of the groups’ documented remit.

That does not make the boundary a wall. The QUIC Working Group still lists work on HTTP/3 qlog event definitions, where observability crosses transport and application layers. The more precise distinction is between maintaining HTTP’s core mapping and handling work whose evidence or mechanics sit at the QUIC boundary. Coordination remains necessary precisely because the layers meet in running systems.

Publication still needs an operator

Calling the protocol HTTP/3 did not make a client offer it, a server accept it, or a network path carry it successfully. RFC publication and a registered ALPN value establish a common reference. Implementations still have to negotiate, interoperate, handle fallback, and make their own deployment decisions. A name can reduce category error; it cannot report adoption or performance.

That limit is also the proposal’s strongest design choice. The common specification can say what HTTP messages mean and how they are mapped over QUIC. The transport specification can define delivery, congestion control, and transport security. Working-group charters can place ongoing maintenance. Operators and implementers then decide whether and how to deploy those specifications. Each record answers a different question.

Nottingham’s contribution was not that he personally named or transferred HTTP/3. He linked the public label to the location of future responsibility, then argued that the HTTP community should decide the name. The groups’ minutes and charters show how those decisions were handled. The result is a useful test for standards work: if a proposal introduces a new binding, can readers tell what is shared, what is new, who maintains each part, and what remains for implementations to prove?

Sources