Original text:
Abstract <del> This document describes a system for the forwarding of encrypted HTTP messages.  This allows a client to make multiple requests of a server without the server being able to link those requests to the client or to identify the requests as having come from the same client. </del>  1. <del> The act of making a request using HTTP reveals information about the client identity to a server.  Though the content of requests might reveal information, that is information under the control of the client.  In comparison, the source address on the connection reveals information that a client has only limited control over. Even where an IP address is not directly attributed to an individual, the use of an address over time can be used to correlate requests. Servers are able to use this information to assemble profiles of client behavior, from which they can make inferences about the people involved.  The use of persistent connections to make multiple requests improves performance, but provides servers with additional certainty about the identity of clients in a similar fashion. Use of an HTTP proxy can provide a degree of protection against servers correlating requests.  Systems like virtual private networks or the Tor network Dingledine2004, provide other options for clients. Though the overhead imposed by these methods varies, the cost for each request is significant.  Preventing request linkability requires that each request use a completely new TLS connection to the server. At a minimum, this requires an additional round trip to the server in addition to that required by the request.  In addition to having high latency, there are significant secondary costs, both in terms of the number of additional bytes exchanged and the CPU cost of </del>  cryptographic computations. <del> This document describes a method of encapsulation for binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE). This protects the content of both requests and responses and enables a deployment architecture that can separate the identity of a </del>  requester from the request. <del> Though this scheme requires that servers and proxies (called relays in this document) explicitly support it, this design represents a performance improvement over options that perform just one request in each connection.  With limited trust placed in the relay (see security), clients are assured that requests are not uniquely attributed to them or linked to other requests. </del>  2.

Reviewer comments:
I found this helpful, do with it what you will.
I'll merge and fix lints afterwards.
LGTM. Thanks Mark.

Revised text:
Abstract  <ins> This document describes a system for forwarding encrypted HTTP messages.  This allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. </ins> 1.  <ins> A HTTP request reveals information about the client's identity to the server.  Some of that information is in the request content, and therefore under the control of the client.  However, the source IP address of the underlying connection reveals information that the client has only limited control over. Even where an IP address is not directly associated with an individual, the requests made from it can be correlated over time to assemble a profile of client behavior.  In particular, connection reuse improves performance, but provides servers with the ability to correlate requests that share a connection. Client-configured HTTP proxies can provide a degree of protection against IP address tracking, and systems like virtual private networks and the Tor network Dingledine2004 provide additional options for clients. However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS connection to avoid the connection itself being used to correlate behavior.  This imposes considerable performance and efficiency overheads, due to the additional round trip to the server (at a minumum), additional data exchanged, and additional CPU cost of </ins> cryptographic computations.  <ins> This document defines two kinds of HTTP resources - Oblivious Relay Resources and Oblivious Gateway Resources - that process encapsulated binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE).  They can be composed to protect the content of encapsulated requests and responses, thereby separating the identity of a </ins> requester from the request.  <ins> Although this scheme requires support for two new kinds of oblivious resources, it represents a performance improvement over options that perform just one request in each connection.  With limited trust placed in the Oblivious Relay Resource (see security), clients are assured that requests are not uniquely attributed to them or linked to other requests. </ins> 2.