Original text:
serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is or could be authoritative for. <del> The ORIGIN frame defines the following flags: </del>  <del> Indicates that the Origin Set MUST be reset to an empty set before processing the contents of the frame it occurs upon. </del>  <del> Indicates that the origin(s) carried in the payload must be removed from the Origin Set, if present; if not present, it/they have no effect. </del>  <del> 2.1. </del>  <del> The set of origins (as per RFC6454) that a given connection might be used for is known in this specification as the Origin Set. </del>  <del> When a connection is first established, its Origin Set is defined to be those origins that the client would normally consider the connection authoritative for; see RFC7540, Section 10.1. </del>  <del> The ORIGIN frame allows the server to modify the Origin Set. In particular: </del>  <del> A server can add to its members by sending an ORIGIN frame (without any flags set); </del>  <del> A server can prune one or more origins from it by sending an ORIGIN frame with the REMOVE flag set; </del>  <del> A server can remove all its members and then add zero or more members by sending an ORIGIN frame with the CLEAR flag set and a payload containing the new origins. </del>  <del> Adding to the Origin Set (cases 1 and 3 above) does not imply that the connection is authoritative for the added origins (in the sense of RFC7540, Section 10.1) on its own; this MUST be established by some other mechanism. </del>  <del> A client that implements this specification MUST NOT use a connection for a given origin unless that origin appears in the Origin Set for the connection, regardless of whether or not it believes that the connection is authoritative for that origin. </del>  <del> 2.2. </del>  <del> The ORIGIN frame is a non-critical extension to HTTP/2.  Endpoints that do not support this frame can safely ignore it upon receipt. </del>  <del> When received by a client, it can be used to inform HTTP/2 connection coalescing (see set), but does not relax the requirement there that the server is authoritative. </del>  <del> The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored. </del>  <del> The ORIGIN frame is processed hop-by-hop.  An intermediary MUST NOT forward ORIGIN frames.  Clients configured to use a proxy MUST ignore any ORIGIN frames received from it. </del>  <del> The following algorithm illustrates how a client can handle received ORIGIN frames: </del>  <del> If the client is configured to use a proxy, ignore the frame and stop processing. </del>  <del> If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. </del>  <del> If the CLEAR flag is set, remove all members from the Origin Set. </del>  <del> For each Origin field "origin_raw" in the frame payload: </del>  <del> Parse "origin_raw" as an ASCII serialization of an origin (RFC6454, Section 6.2) and let the result be "parsed_origin". </del>  <del> If the REMOVE flag is set, remove any member of the Origin Set that is the same as "parsed_origin" (as per RFC6454, Section 5), and continue to the next "parsed_origin". </del>  <del> Otherwise, add "parsed_origin" to the Origin Set. </del>  3.  Clients that blindly trust the ORIGIN frame's contents will be <del> vulnerable to a large number of attacks; hence the reinforcement that this specification does not relax the requirement for server authority in RFC7540, Section 10.1. </del>  <del> 4.  References </del>  <del> 4.1.  URIs </del>  [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Reviewer comments:
Relax DNS requirements when ORIGIN is received Change the initial origin set to just SNI
wait - no. You wouldn't send the alternative in the ORIGIN frame, you would send the origin that you are the alternative for, right? that would make sense - if you want to use an alternative you can't rely on the SNI default.
this is indeed looking goodminor nitsThis is looking good.

Revised text:
serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is or could be authoritative for.  <ins> The ORIGIN frame does not define any flags. </ins>  <ins> 2.2. </ins>  <ins> The ORIGIN frame is a non-critical extension to HTTP/2.  Endpoints that do not support this frame can safely ignore it upon receipt. </ins>  <ins> When received by an implementing client, it is used to manipulate the Origin Set (see set), thereby changing how the client establishes authority for origin servers (see authority). </ins>  <ins> The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored. </ins>  <ins> Likewise, the ORIGIN frame is only valid on connections with the "h2" protocol identifier, or when specifically nominated by the protocol's definition; it MUST be ignored when received on a connection with the "h2c" protocol identifier. </ins>  <ins> The ORIGIN frame is processed hop-by-hop.  An intermediary MUST NOT forward ORIGIN frames.  Clients configured to use a proxy MUST ignore any ORIGIN frames received from it. </ins>  <ins> Each ASCII-Origin field in the frame's payload MUST be parsed as an ASCII serialisation of an origin (RFC6454, Section 6.2).  If parsing fails, the field MUST be ignored. </ins>  <ins> Senders should note that, as per RFC6454 Section 4, the values in an ORIGIN header need to be case-normalised before serialisation. </ins>  <ins> Once parsed, the value MUST have: </ins>  <ins> a scheme of "https", </ins>  <ins> a host that is reflected in a "subjectAltName" of the connection's TLS certificate (using the wildcard rules defined in RFC2818, Section 3.1), and </ins>  <ins> a port that reflects the connection's remote port on the client. </ins>  <ins> If any of these requirements are violated, the client MUST ignore the field. </ins>  <ins> See algo for an illustrative algorithm for processing ORIGIN frames. </ins>  <ins> 2.3. </ins>  <ins> The set of origins (as per RFC6454) that a given connection might be used for is known in this specification as the Origin Set. When an ORIGIN frame is first received by a client, the connection's Origin Set is defined to contain a single origin, composed from: Scheme: "https" Host: the value sent in Server Name Indication (RFC6066 Section 3), converted to lower case </ins>  <ins> Port: the local port of the connection on the server </ins>  <ins> The contents of that ORIGIN frame (and subsequent ones) allows the server to incrementally add new origins to the Origin Set, as described in process. </ins>  <ins> The Origin Set is also affected by the 421 (Misdirected Request) response status code, defined in RFC7540 Section 9.1.2.  Upon receipt of a response with this status code, implementing clients MUST create the ASCII serialisation of the corresponding request's origin (as per RFC6454, Section 6.2) and remove it from the connection's Origin Set, if present. </ins>  <ins> 2.4. </ins>  <ins> RFC7540, Section 10.1 uses both DNS and the presented TLS certificate to establish the origin server(s) that a connection is authoritative for, just as HTTP/1.1 does in RFC7230.  Furthermore, RFC7540 Section 9.1.1 explicitly allows a connection to be used for more than one origin server, if it is authoritative. </ins>  <ins> Upon receiving an ORIGIN frame on a connection, clients that implement this specification change these behaviors in the following ways: </ins>  <ins> They MUST NOT consult DNS to establish authority for origins in the Origin Set. The TLS certificate MUST be used to do so, as described in RFC7540 Section 9.1.1. </ins>  <ins> Requests SHOULD use an existing connection if their origin is in that connection's Origin Set, unless there are operational reasons for creating a new connection. </ins> 3. <ins> TBD. 4. </ins> Clients that blindly trust the ORIGIN frame's contents will be  <ins> vulnerable to a large number of attacks.  See authority for mitigations. Relaxing the requirement to consult DNS when determining authority for an origin means that an attacker who possesses a valid certificate no longer needs to be on-path to redirect traffic to them; instead of modifying DNS, they need only convince the user to visit another Web site, in order to coalesce connections to the target onto their existing connection. </ins>  <ins> 5.  References </ins>  <ins> 5.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/