Original text:
The client removes the encapsulation to obtain the response to the original request.  4. A client needs to acquire information about the key configuration of

Reviewer comments:
This is more background than I would normally like to include, but it seems prudent at this stage. The example usage bit might go eventually, but I can see us keeping some sort of applicability statement.
I recognize that / added some conditions and use cases, but it would help readers like me to have even more. A separate explainer document/readme would be fine too. In the meeting chat today, I heard the suggestion of requesting map tiles as another use case, which makes sense to me: asking for map tiles is itself pretty revealing if connected to the user's identity (it might reveal your current location, or a location where you're going to be) and can be pretty transactional/stateless. Maybe search queries are similar. Safe browsing lookups was also mentioned. Having more example use cases might help in resolving other questions, like whether to support multiple HTTP requests at a time, or non-HTTP message bodies, etc. Ideally, we could explain the conditions under which adoption of ohttp will be useful -- maybe, a privacy need for reducing linkability of multiple requests or of a single request from user identity, and HTTP requests that are typically stateless or single-shot in some way, and frequent or performant-requiring at a certain level.
NAME added some more examples. NAME I think we can safely close this now, so I'm going to go ahead and do that. Please reopen with concrete suggestions if you think the new text is insufficient!
A little more text on the narrow applicability of this would be helpful. Some people originally interpreted this as having broader application than was ever intended.
NAME can we close this with ?
Yep. I forgot to link it.

Revised text:
The client removes the encapsulation to obtain the response to the original request. <ins> 3.1. Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies (RFC6265), authentication (Section 11 of I-D.ietf-httpbis-semantics), or even alternative services (RFC7838).  Oblivious HTTP seeks to prevent this sort of linkage, which requires that applications not carry state between requests. Oblivious HTTP is primarily useful where privacy risks associated with possible stateful treatment of requests are sufficiently negative that the cost of deploying this protocol can be justified. Oblivious HTTP is simpler and less costly than more robust systems, like Prio (PRIO) or Tor (Dingledine2004), which can provide stronger guarantees at higher operational costs. Oblivious HTTP is more costly than a direct connection to a server. Some costs, like those involved with connection setup, can be amortized, but there are several ways in which oblivious HTTP is more expensive than a direct request: Each oblivious request requires at least two regular HTTP requests, which adds latency. Each request is expanded in size with additional HTTP fields, encryption-related metadata, and AEAD expansion. Deriving cryptographic keys and applying them for request and response protection takes non-negligible computational resources. Examples of where preventing the linking of requests might justify these costs include: DNS queries.  DNS queries made to a recursive resolver reveal information about the requester, particularly if linked to other queries. Telemetry submission.  Applications that submit reports about their usage to their developers might use oblivious HTTP for some types of moderately sensitive data. </ins> 4. A client needs to acquire information about the key configuration of