Change:
5. <ins> A client interacts with the oblivious proxy resource by constructing an encapsulated request.  This encapsulated request is included as the content of a POST request to the oblivious proxy resource.  This request MUST only contain those fields necessary to carry the encapsulated request: a method of POST, a target URI of the oblivious proxy resource, a header field containing the content type (see (media-types), and the encapsulated request as the request content. Clients MAY include fields that do not reveal information about the content of the request, such as Alt-Used ALT-SVC. The oblivious proxy resource interacts with the oblivious request 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. When a response is received from the oblivious request resource, the oblivious proxy resource forwards the response according to the rules of an HTTP proxy; see Section 7.6 of HTTP. An oblivious request resource, if it receives any response from the oblivious target resource, sends a single 200 response containing the encapsulated response.  Like the request from the client, this response MUST only contain those fields necessary to carry the encapsulated response: a 200 status code, a header field indicating the content type, and the encapsulated response as the response content.  As with requests, additional fields MAY be used to convey information that does not reveal information about the encapsulated response. An oblivious request resource acts as a gateway for requests to the oblivious target resource (see Section 7.6 of HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. 5.1. This encapsulation does not permit progressive processing of responses.  Though the binary HTTP response format does support the inclusion of informational (1xx) status codes, the AEAD encapsulation cannot be removed until the entire message is received. In particular, the Expect header field with 100-continue (see Section 10.1.1 of HTTP) cannot be used.  Clients MUST NOT construct a request that includes a 100-continue expectation; the oblivious request resource MUST generate an error if a 100-continue expectation is received. 5.2. A server that receives an invalid message for any reason MUST generate an HTTP response with a 4xx status code. Errors detected by the oblivious proxy resource and errors detected by the oblivious request resource before removing protection (including being unable to remove encapsulation for any reason) result in the status code being sent without protection in response to the POST request made to that resource. Errors detected by the oblivious request resource after successfully removing encapsulation and errors detected by the oblivious target resource MUST be sent in an encapsulated response. 6. Media types are used to identify encapsulated requests and responses. 6.1. The "message/ohttp-req" identifies an encapsulated binary HTTP request.  This is a binary format that is defined in request. message ohttp-req N/A None only "8bit" or "binary" is permitted see N/A this specification N/A N/A see Authors' Addresses section COMMON N/A see Authors' Addresses section IESG 6.2. The "message/ohttp-res" identifies an encapsulated binary HTTP response.  This is a binary format that is defined in response. message ohttp-res N/A None only "8bit" or "binary" is permitted see N/A this specification N/A N/A see Authors' Addresses section COMMON N/A see Authors' Addresses section IESG 7. </ins> In this design, a client wishes to make a request of a server that is authoritative for the oblivious target resource.  The client wishes to make this request without linking that request with either:

Discussion:
This is more or less implied already, but it is better to write it down. I've added stubs for some content types as well.
This probably covers a bunch of things, so I'll start with a few things that might want to be discovered automatically: Clients might want to ask the oblivious proxy resource which oblivious request resource it forwards to. Clients might want to learn about which oblivious target resources a particular oblivious request resource is willing to forward to. Clients might want to learn automatically about the public keys the oblivious request resource has (along with key identifiers, see ). Clients might want to ask about the oblivious proxy resources that forward to a particular oblivious request resource. This is a little tricky, because clients will need to exercise discretion in selecting from this set. This also risks exposing the existence of DoS exemption agreements between the oblivious request resource server and the oblivious proxy resource server. Clients might want to ask the oblivious target resource for an oblivious request resource (or by extension oblivious proxy resource) that it can use to reach that resource. If you look at this as link relations, this is two forward links, a key configuration, and two backward links. Defining link relation types for this might be a way to address this. Assuming that we also define a media type for a key configuration format, that is.
This seems to me to the fundamental challenge with this system, and a great many other systems. DHTs have been used to advertise resource availability, but the searched object is quite hard to blind from everyone. We could say that good is the enemy of great, only we've been at this a while, and neither have shown up.
NAME use of the word "system" is interesting here. OHTTP does not describe a system, but a protocol. The way that this protocol is deployed and used in practice, I think, defines the system. (The same argument goes for protocols like DoH.) So I don't see this as a challenge to the protocol design, but rather to how one might configure and use it in practice. And that seems rightfully out of scope.
NAME Document that practice a bit, then, if it is practice. I don't view the DoH document as a resounding success, fwiw. It left many questions unanswered, to the point that we had to spin up another working group just to address them.

My fundamental question remains: does ohttp contribute more positive than negative? No use case in the document means no understanding of that. I do appreciate Martin and Eric's explanation on list. Perhaps that should be incorporated.
You might not find this satisfactory, but there is text in the draft about exactly the use cases that Ekr described. https://unicorn-URL has those two. Are you asking for more discussion of the relationship between various actors in those use cases?
Martin, the example you gave was really good. The trick is to show how the players interact.
Discussed at IETF 113 and the WG decided that we would continue the discovery discussion in relation to other drafts.
We aren't really able to carry informational status codes using this form of encapsulation. Sure, we could encode an informational status as a new message, but we don't have anywhere to include it, except as the content of a response, along with the final status code. That might not be helpful if you consider things like 100-continue. My recommendation is to make this limitation clear and prohibit the use of 100-continue.