I agree. I had focused more on the lower parts of the document where I had changed it to clearly state it's about being non-blocking, not async vs sync for much of it.

The only two places where truly async behavior is needed as I see it are:

1) the `Subscription.request` method (and possible `cancel`)
2) The need for a `Subscriber` to use `request(n)` in the first place which implies that somewhere down the chain it is async (buffering).

Experience with prototypes in RxJava have led me to believe the `Subscription.request` method should allow receiving `-1` or some other value to represent *infinite* – just send me as fast as you can. 

This is a very valid use case for a variety of things. For example, if I have a `Publisher` that represents a file and it's a choice of the `Subscriber` whether it is consumed synchronously or asynchronously, the `Subscriber` should be able to tell the `Subscription` to send without restriction.

Similarly, if I'm streaming metrics, I an do `request(-1)` and then just sample or throttle, since `request(n)` doesn't really make much sense in that use case. The data is flowing along at whatever rate it does and I always want to sample whatever the latest value is.