I think we can go forward from here. Now, I'm fine with compromising on saying that implementations MUST *support* (emphasis) the `StreamInterface`. I think it's out of the purview of this PSR but blah blah blah ... we've been down that road. What I'm basically objecting to is the *requirement* of representing every entity body as a `StreamInterface` whether it's necessary or not.

Say my application server deals *only* with JSON entity body payloads. And say my application logic dictates that the max size any of these entities will ever be is 512 bytes. I will *never* treat these as anything other than buffered in-memory strings. Ever. However, to access these strings I'm forced to add a new object construction/destruction and a getter method call that I'll never need. Is this a big deal in the web SAPI? Not at all because there my process is isolated from all the other concurrent requests.

But consider my real-life scenario where there are thousands of simultaneous clients and the entire application executes inside an event loop. These few unnecessary userland calls are holding up every other action in the server. I can't accept new clients. I can't send data to other clients. I can't do anything. I have to do these superflous things even though I don't need them.

I'm simply asking that we avoid hard coding the specific type as the only option so that compliant implementations can avoid the `StreamInterface` if they need to do so. So that would look like:

```
/**
 * @return null|string|resource|StreamInterface
 */
public function getBody();

/**
 * @param null|string|resource|StreamInterface $body
 */
public function setBody(StreamInterface $body = null);
```

Now, I'm aware that the vast majority of use-cases do not require this level of fine-grained control. However, this approach is not imposing any unreasonable constraints on implementations.