Change:
payloads. For the server receiving NON Q-Block1 requests, it SHOULD send back a <del> 2.31 (Continue) or 4.08 (Request Entity Incomplete) Response Code on receipt of the last of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying.  If the last of the MAX_PAYLOADS payloads does not arrive (or the final payload where the M bit is not set does not arrive), then the server SHOULD delay for NON_RECEIVE_TIMEOUT before sending the 4.08 (Request Entity Incomplete) Response Code. </del> <ins> 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying.  Otherwise the server SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the 4.08 (Request Entity Incomplete) Response Code.  The NON_RECEIVE_TIMEOUT delay can be reduced if either the last of the MAX_PAYLOADS payloads or the final payload with the M bit unset arrives, but SHOULD NOT be reduced to zero as packets may arrive in the wrong order. </ins> It is possible that the client may start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads.  On receipt of the first <del> payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads.  Upon receipt of the 4.08 (Request Entity Incomplete) Response Code, the client SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS payloads and then go into another NON_TIMEOUT delay prior to sending the next set of payloads. </del> <ins> received payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads.  Upon receipt of the 4.08 (Request Entity Incomplete) Response Code, the client SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS payloads and then go into another NON_TIMEOUT delay prior to sending the next set of payloads. </ins> For the client receiving NON Q-Block2 responses, it SHOULD send a <del> request for the next set of payloads or a request for the missing payloads upon receipt of the last of the MAX_PAYLOADS payloads to prevent the server unnecessarily delaying the transmission of the body.  If the last of the MAX_PAYLOADS payloads does not arrive (or the final payload where the M bit is not set does not arrive), then the client SHOULD delay for NON_RECEIVE_TIMEOUT before sending the request for the missing payloads. </del> <ins> request for the next set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent the server unnecessarily delaying. Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the request for the missing payloads.  The NON_RECEIVE_TIMEOUT delay can be reduced if either the last of the MAX_PAYLOADS payloads or the final payload with the M bit unset arrives, but SHOULD NOT be reduced to zero as packets may arrive in the wrong order. </ins> The request that the client sends to acknowledge the receipt of all the current set of MAX_PAYLOADS payloads is the 'Continue' Q-Block2

Discussion:
find another name than Quick-Block
A poll is ongoing. Updated to Q-Block in -02, but open to change if we get more inputs