Original text:
minimum), additional data exchanged, and additional CPU cost of cryptographic computations. <del> To overcome these limitations, this document defines how binary HTTP messages BINARY can be encapsulated using Hybrid Public Key Encryption (HPKE; HPKE) to protect their contents.  exchange these messages with an , which is responsible for forwarding decapsulated requests to the original and encapsulating the corresponding responses and sending them back to the client.  Critically, encapsulated messages are sent through a separate to avoid exposing the client's IP address or allowing the connection to be used as a correlator between its requests. Because it allows connection reuse between the client and , as well as between that relay and the , this scheme represents a performance improvement over using just one request in each connection.  With limited trust placed in the (see security), are assured that requests are not uniquely attributed to them or linked to other requests. </del>  2. particular .  Oblivious HTTP uses a one-to-one mapping between ; see proxy-state for more details. <del> This information allows the to make a request of a with that resource having only a limited ability to correlate that request with the IP or other requests that the might make to that server. </del>  <del> In order to make a request to a , the following steps occur, as shown in fig-overview: </del>  The constructs an HTTP request for a . The receives this request and removes the HPKE protection to obtain an HTTP request. <del> The makes an HTTP request that includes the target URI, method, fields, and content of the request it acquires. The answers this HTTP request with an HTTP response. </del>  The encapsulates the HTTP response following the process in response and sends this in response to the request from the . The removes the encapsulation to obtain the response to the original request.  2.1. <del> Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies (COOKIES), authentication (HTTP), or even alternative services (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests. </del>  Oblivious HTTP is primarily useful where privacy risks associated with possible stateful treatment of requests are sufficiently large 6. <del> In this design, a wishes to make a request of a server that is authoritative for a . The wishes to make this request without linking that request with either: </del>  The identity at the network and transport layer of the (that is, the IP address and TCP or UDP port number the uses to create a As a consequence of this configuration, Oblivious HTTP prevents linkability described above.  Informally, this means: <del> Requests and responses are known only to and Target Resources, plus that possess the corresponding response encapsulation key and HPKE keying material.  In particular, the knows the origin and destination of an and Response, yet does not know the decrypted contents.  Likewise, learn only the and the decrypted request.  No entity other than the can see the plaintext request and response and can attribute them to the . </del>  <del> Targets cannot link requests from the same in the absence of unique per- keys. </del>  Traffic analysis that might affect these properties are outside the scope of this document; see ta. 6.1.  MUST ensure that the they select for generating Encapsulated Requests is integrity protected and authenticated so that it can be attributed to the ; see key-configuration. If separate entities provide the and , these entities might need an arrangement similar to that between server and relay for managing <del> denial of service; see dos. </del>  Non-secure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway

Reviewer comments:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM

Revised text:
minimum), additional data exchanged, and additional CPU cost of cryptographic computations.  <ins> To overcome these limitations, this document defines Oblivious HTTP, a protocol for encrypting and sending HTTP messages from a client to a gateway through a trusted relay service.  In particular, the protocol in this document describes: an algorithm for encapsulating binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE) to protect their contents, a method for forwarding these encapsulated messages between clients and an through a trusted using HTTP, and requirements for how the handles encapsulated HTTP messages and produces encapsulated responses for the client. The combination of encapsulation and relaying ensures that never sees the client's IP address and the never sees plaintext HTTP message content. Oblivious HTTP allows connection reuse between the client and , as well as between that relay and the , so this scheme represents a performance improvement over using just one request in each connection.  With limited trust placed in the (see security), are assured that requests are not uniquely attributed to them or linked to other requests. </ins> 2. particular .  Oblivious HTTP uses a one-to-one mapping between ; see proxy-state for more details.  <ins> This information allows the to send HTTP requests to the for forwarding to a .  The does not learn the client's IP address or any other identifying information that might be revealed from the client at the transport layer, nor does the learn which of the requests it receives are from the same . </ins>  <ins> In order to forward a request for a to the , the following steps occur, as shown in fig-overview: </ins> The constructs an HTTP request for a . The receives this request and removes the HPKE protection to obtain an HTTP request.  <ins> The then handles the HTTP request.  This typically involves making an HTTP request using the content of the . Once the has an HTTP response for this request, the following steps occur to return this response to the client: </ins> The encapsulates the HTTP response following the process in response and sends this in response to the request from the . The removes the encapsulation to obtain the response to the original request. <ins> This interaction provides authentication and confidentiality protection between the and the Oblivious Gateway, but importantly not between the and the . While the is a distinct HTTP resource from the , they are both logically under the control of the Oblivious Gateway, since the can unilaterally dictate the responses returned from the to the . This arrangement is shown in fig-overview.  See security for more information about and Oblivious Relay, and Oblivous Gateway resources in running this protocol. </ins> 2.1.  <ins> Oblivious HTTP has limited applicability.  Imporantly, it requires expicit support from a willing and , thereby limiting the use of Oblivious HTTP for generic applications; see server-responsibilities for more information. Many uses of HTTP benefit from being able to carry state between requests, such as with cookies (COOKIES), authentication (HTTP), or even alternative services (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests. </ins> Oblivious HTTP is primarily useful where privacy risks associated with possible stateful treatment of requests are sufficiently large 6.  <ins> In this design, a wishes to make a request to an that is forwarded to a . The wishes to make this request without linking that request with either: </ins> The identity at the network and transport layer of the (that is, the IP address and TCP or UDP port number the uses to create a As a consequence of this configuration, Oblivious HTTP prevents linkability described above.  Informally, this means:  <ins> Requests and responses are known only to and .  In particular, the knows the origin and destination of an and Response, yet does not know the decrypted contents.  Likewise, learn only the and the decrypted request.  No entity other than the can see the plaintext request and response and can attribute them to the . </ins>  <ins> Oblivous Gateway Resources, and therefore Target Resources, cannot link requests from the same in the absence of unique per- keys. </ins> Traffic analysis that might affect these properties are outside the scope of this document; see ta. 6.1. <ins> Because do not authenticate the when using Oblivious HTTP, MUST maintain an explicit allowlist of target resources that the trusts an Oblivious Gateway to respond for, and check requests against this allowlist before sending them.  This ensures that are not abused to forward traffic to arbitrary Target Resources.  See server- responsibilities for similar responsibilities that apply to . </ins> MUST ensure that the they select for generating Encapsulated Requests is integrity protected and authenticated so that it can be attributed to the ; see key-configuration. If separate entities provide the and , these entities might need an arrangement similar to that between server and relay for managing  <ins> denial of service; see dos.  Moreover, the SHOULD apply some form of allowlist to ensure that the is not misused as a relay for HTTP messages to an arbitrary . </ins> Non-secure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway