Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  An HTTP request that is encapsulated in an HPKE-encrypted message; see request. it trusts the oblivious proxy resource to remove, such as fields that are listed in the Connection header field.  The oblivious proxy resource interacts with the oblivious request <del> resource by constructing a request using the same restrictions as the client request, except that the target URI is the oblivious request resource.  The content of this request is copied from the client. The oblivious proxy resource MUST NOT add information about the client to this request. </del>  When a response is received from the oblivious request resource, the oblivious proxy resource forwards the response according to the rules

Reviewer comments:
It would be wrong to use "user agent" as this could be used for an HTTP request made by any client toward any server (using the HTTP definitions).
Why don't use "Oblivious Client" and the "OC" acronym, like OAuth does with "Authorization Server"? This would preserve the natural "client" meaning, and could make the document more readable. The same acronym trick could ease readability wrt "Oblivious Request Resource" and "Oblivious Target Resource"...
I know that people like acronyms, but it doesn't really solve this problem. The oblivious HTTP client really is an HTTP client in the sense that HTTP knows; calling it anything else would be more confusing, I think. As it seems like this is a case where more words would help. I've added more words.
Since there are so many occurrencies of I think that's ok :) Probably in the Introduction, "client" means "HTTP client", but anyway the difference is clear to me now :D
since there are various layers, the term "client" can be applicable to both the oblivious proxy/request resource. Maybe the term User agent can be appropriate when we refer to the originating client?
Hi Roberto, Does URL clarify things? I think that "client" still makes a lot of sense here, but you are right that this is not an HTTP client in the strictest sense. (Although, now that I write this, it really is, it's just that this uses something other than a connection as a medium from getting a request to the server...)
LGTM

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses its own definition of client.  When referring to the HTTP definition of client (Section 3.3 of HTTP), the term "HTTP client" is used; see http-usage. </ins> An HTTP request that is encapsulated in an HPKE-encrypted message; see request. it trusts the oblivious proxy resource to remove, such as fields that are listed in the Connection header field. <ins> The client role in this protocol acts as an HTTP client both with respect to the oblivious proxy resource and the oblivious target resource.  For the request the clients makes to the oblivious target resource, this diverges from typical HTTP assumptions about the use of a connection (see Section 3.3 of HTTP) in that the request and response are encapsulated rather than sent over a connection.  The oblivious proxy resource and the oblivious request resource also act as HTTP clients toward the oblivious request resource and oblivious target resource respectively. </ins> The oblivious proxy resource interacts with the oblivious request  <ins> resource as an HTTP client by constructing a request using the same restrictions as the client request, except that the target URI is the oblivious request resource.  The content of this request is copied from the client.  The oblivious proxy resource MUST NOT add information about the client to this request. </ins> When a response is received from the oblivious request resource, the oblivious proxy resource forwards the response according to the rules