Draft: draft-ietf-core-new-block

Commentary: 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
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.
This Response Code indicates successful receipt of the entire body
and the resource was created.
This Response Code indicates successful receipt of the entire body
and the resource was updated.
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
M bit set) in the response have been successfully received.
This Response Code indicates successful receipt of the entire body
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.
This Response Code indicates successful receipt of the entire body
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.
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
M bit set) in the response have been successfully received.  The
token used SHOULD be from the last received payload.
The token used in the response SHOULD be from the last received
payload.  See code for further information.
The token to use for the response SHOULD be the token that was used
in the highest block number received so far with the same Request-Tag
value.  Note that the use of any received token with the same
Request-Tag would work, but providing the one used in the highest
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.
The token to use for the response SHOULD be the token that was used
in the last block number received so far with the same Request-Tag
value.  Note that the use of any received token with the same
Request-Tag would work, but providing the one used in the last
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.
For the server receiving NON Q-Block1 requests, it SHOULD send back a
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.
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
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.
For the client receiving NON Q-Block2 responses, it SHOULD send a
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.
For the server receiving NON Q-Block1 requests, it SHOULD send back a
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.
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
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.
For the client receiving NON Q-Block2 responses, it SHOULD send a
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.
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.
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.
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.