Request Channel Payloads from Requester (rsocket#154)

* Request Channel Payloads from Requester

Clarifying that a channel sends PAYLOAD frames. 

- Depends on rsocket/rsocket#153 and will need rebasing. 
- Need to also change wording later in the document explaining interaction model.
- Not certain about wording yet.

* Update Protocol.md

* Update Protocol.md

* Update Protocol.md

* Update Protocol.md

Author: benjchristensen

Protocol.md

@@ -145,8 +145,7 @@ connection on reception of a frame that it does not understand with this bit not
 
 #### Frame Validation
 
-ReactiveSocket implementations may provide their own validation at the metadata level for specific frames. However, this is an application concern
-and not necessary for protocol processing.
+ReactiveSocket implementations may provide their own validation at the metadata level for specific frames. However, this is an application concern and not necessary for protocol processing.
 
 #### Metadata Optional Header
 
@@ -461,9 +460,7 @@ Frame Contents
 * __Initial Request N__: 32-bit signed integer representing the initial request N value for the stream. Only positive values are allowed.
 * __Request Data__: identification of the service being requested along with parameters for the request.
 
-Please note that this explicitly does NOT follow rule number 17 in https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md#3-subscription-code
-
-While ReactiveStreams supports a demand of up to 2^63-1, and treats 2^63-1 as a magic number signaling to not track demand, this is not the case for ReactiveSocket. ReactiveSocket prioritizes byte size and only uses 4 bytes instead of 8 so the magic number is unavailable.
+See Flow Control: Reactive Stream Semantics for more information on RequestN behavior.
 
 ### Request Channel Frame
 
@@ -475,9 +472,9 @@ Frame Contents
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Stream ID                           |
     +-----------+-+-+-+-+-+---------+-------------------------------+
-    |Frame Type |0|M|F|C|N|  Flags  |
+    |Frame Type |0|M|F|C|  Flags    |
     +-------------------------------+-------------------------------+
-    |              Initial Request N (only if N bit set)            |
+    |                      Initial Request N                        |
     +---------------------------------------------------------------+
                            Metadata & Request Data
 ```
@@ -486,11 +483,14 @@ Frame Contents
     * (__M__)etadata: Metadata present
     * (__F__)ollows: More Fragments Follow This Fragment.
     * (__C__)omplete: bit to indicate COMPLETE.
-    * (__N__): Is Initial Request N present or not
 * __Initial Request N__: 32-bit signed integer representing the initial request N value for channel. Only positive values are allowed.
 * __Request Data__: identification of the service being requested along with parameters for the request.
 
-See Request Stream Frame for additional information.
+A requester MUST send only __one__ REQUEST_CHANNEL frame. Subsequent messages from requester to responder MUST be sent as PAYLOAD frames. 
+
+A requester MUST __not__ send PAYLOAD frames after the REQUEST_CHANNEL frame until the responder sends a REQUEST_N frame granting credits for number of PAYLOADs able to be sent.
+
+See Flow Control: Reactive Stream Semantics for more information on RequestN behavior.
 
 ### Request N Frame
 
@@ -512,7 +512,7 @@ Frame Contents
      * (__M__)etadata: Metadata __NOT__ present
 * __Request N__: 32-bit signed integer value of items to request. Only positive values are allowed.
 
-See Request Stream Frame for additional information.
+See Flow Control: Reactive Stream Semantics for more information on RequestN behavior.
 
 ### Cancel Frame
 
@@ -829,6 +829,10 @@ There are multiple flow control mechanics provided by the protocol.
 
 [Reactive Stream](http://www.reactive-streams.org/) semantics for flow control of Streams, Subscriptions, and Channels.
 
+Please note that this explicitly does NOT follow rule number 17 in https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md#3-subscription-code
+
+While ReactiveStreams supports a demand of up to 2^63-1, and treats 2^63-1 as a magic number signaling to not track demand, this is not the case for ReactiveSocket. ReactiveSocket prioritizes byte size and only uses 4 bytes instead of 8 so the magic number is unavailable.
+
 The Requester and the Responder MUST respect the reactive-streams semantics.
 
 e.g. here's an example of a successful stream call with flow-control.