Skip to main content

The ORIGIN HTTP/2 Frame
draft-ietf-httpbis-origin-frame-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: httpbis-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-httpbis-origin-frame@ietf.org, mcmanus@ducksong.com, ietf-http-wg@w3.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org, Patrick McManus <mcmanus@ducksong.com>
Subject: Protocol Action: 'The ORIGIN HTTP/2 Frame' to Proposed Standard (draft-ietf-httpbis-origin-frame-06.txt)

The IESG has approved the following document:
- 'The ORIGIN HTTP/2 Frame'
  (draft-ietf-httpbis-origin-frame-06.txt) as Proposed Standard

This document is the product of the Hypertext Transfer Protocol Working Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/


Ballot Text

Technical Summary

This document creates an HTTP/2 [RFC7540]
extension for finer grained control of connection management than is
provided by the base HTTP/2 specification. In this context that
specifically means the set of origin names that may be served on one
connection. The document provides for changing that set to be both
smaller or larger than the default.

Working Group Summary

Two key aspects of the draft, the ability to remove origin names from
the default set and the syntax to manage the set, underwent several
iterations based on the working group's feedback and arrived at a
strong consensus.

The aspects of this document dealing with the relationship of HTTPS
connection management and DNS were the most controversial and required
the most change to reach consensus. This mechanism addresses
experience with RFC 7540 which shows the existing DNS based mechanism
is administratively onerous and error prone. The change also has
benefits for performance and confidentiality. On the other hand, the
change increases the importance of proper certificate security because
key compromise can now be exploited without being an on-path attacker.

The final position of the draft is that an Origin extension relaxes
the requirements for name resolution (but never certificate
verification) if a client concludes the new risks are mitigated by
alternative signals that boost confidence in the certificate. The
Security Considerations deals with the topic at some length. This
position reached rough consensus.

Document Quality

Participation in the document's review and discussion was unusually
broad based with members of the community from many roles taking part
(browsers, servers, CDNs, security engineers, etc..). There is broad
agreement that the functionality provides benefits to HTTP latency,
efficiency, and administrative flexibility.

There are statements of intent to implement from browser, servers,
and CDNs. There is an existing browser implementation.

Personnel

   Patrick McManus is the document shepherd; Alexey Melnikov is the
   responsible Area Director.

RFC Editor Note