Change:
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

Discussion:
A CoAP endpoint (or proxy) MUST support either both or neither of the Q-Block1 and Q-Block2 Options. <ins> If Q-Block1 Option is present in a request or Q-Block2 Option in a response (i.e., in that message to the payload of which it pertains), it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed. </ins> To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request, the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT

(if supported) to send back a message body that is too large to fit into a single IP packet RFC7959. <del> If Q-Block1 Option is present in a request or Q-Block2 Option in a response (i.e., in that message to the payload of which it pertains), it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed. </del> Implementation of the Q-Block1 and Q-Block2 Options is intended to be optional.  However, when it is present in a CoAP message, it MUST be processed (or the message rejected).  Therefore, Q-Block1 and Q-Block2 Options are identified as Critical options. <ins> With CoAP over UDP, the way a request message is rejected for Critical options depends on the message type.  A Confirmable message with a unknown Critical option is rejected with a 4.02 (Bad Option) response (Section 5.4.1 of RFC7252).  A Non-confirmable message with a unknown Critical option is either rejected with a Reset message or just silently ignored (Section 5.4.1 and 4.3 of RFC7252).  To reliably get a rejection message, it is therefore REQUIRED that clients use a Confirmable message for determining support for Q-Block1 and Q-Block2 options. </ins> The Q-Block1 and Q-Block2 Options are unsafe to forward.  That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option MUST reject the request or response that uses either option.

2.01 (Created) This Response Code indicates successful receipt of the entire body <del> and the resource was created. </del> <ins> and the resource was created.  The token used SHOULD be from the last received payload.  The client should then release all of the tokens used for this body. </ins> 2.04 (Changed) This Response Code indicates successful receipt of the entire body <del> and the resource was updated. </del> <ins> and the resource was updated.  The token used SHOULD be from the last received payload.  The client should then release all of the tokens used for this body. </ins> 2.31 (Continue) This Response Code can be used to indicate that all of the blocks up to and including the Q-Block1 Option block NUM (all having the <del> M bit set) in the response have been successfully received. </del> <ins> M bit set) in the response have been successfully received.  The token used SHOULD be from the last received payload. </ins> A response using this Response Code SHOULD NOT be generated for every received Q-Block1 Option request.  It SHOULD only be

matching client request which contains the Request-Tag that is being used for this Q-Block1 body. <ins> The token used in the response SHOULD be from the last received payload.  See code for further information. </ins> 4.13 (Request Entity Too Large) This Response Code can be returned under similar conditions to

these missing blocks is as follows: The token to use for the response SHOULD be the token that was used <del> in the highest block number received so far with the same Request-Tag </del> <ins> in the last block number received so far with the same Request-Tag </ins> value.  Note that the use of any received token with the same <del> Request-Tag would work, but providing the one used in the highest </del> <ins> Request-Tag would work, but providing the one used in the last </ins> received block number will aid any troubleshooting.  The client will use the token to determine what is the previously sent request to obtain the Request-Tag value to be used.

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

Observe Option, if appropriate for an unsolicited response) rather than as a request for the remaining missing blocks. <ins> It is possible that the server may start transmitting the next set of MAX_PAYLOADS payloads before the client times out on waiting for the last of the previous MAX_PAYLOADS payloads.  On receipt of the first received payload from the new set of MAX_PAYLOADS payloads, the client SHOULD send a request for the missing payloads indicating any missing payloads from any previous MAX_PAYLOADS payloads.  Upon receipt of the request for missing payloads, the server 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> The client does not need to acknowledge the receipt of the entire body.

client, but some blocks are dropped in transmission as illustrated in B3non1. <del> The server realizes that some blocks are missing and asks for the missing ones in one go (B3non2).  It does so by indicating which blocks have been received in the data portion of the response.  The token used in the response should be the token that was used in the highest block number received payload.  The client can then derive the Request-Tag by matching the token with the sent request. </del> <ins> On seeing a payload from the next set of payloads, the server realizes that some blocks are missing from the previous MAX_PAYLOADS payloads and asks for the missing blocks in one go (B3non2).  It does so by indicating which blocks have been received in the data portion of the response.  The token used in the response should be the token that was used in the last block number received payload.  The client can then derive the Request-Tag by matching the token with the sent request. </ins> Under high levels of traffic loss, the client can elect not to retry sending missing blocks of data by "forgetting" all the tracked tokens