Draft: draft-ietf-core-new-block

Commentary: I 'm just back to work . Thanks for taking care of the edits .
If the FETCH request includes the Observe Option, then the server
MUST use the same token as used for the initial response for
returning any Observe triggered responses so that the client can
match them up.
The client should then release all of the tokens used for this
body unless a resource is being observed.
If the FETCH request includes the Observe Option, then the server
MUST use the same token as used for the 2.05 (Content) response
for returning any Observe triggered responses so that the client
can match them up.
The client should then release all of the tokens used for this
body apart from the one used for tracking an observed resource.
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) have been successfully received.  The token to use MUST
be one of the tokens that were received in a request for this
block-wise exchange.  However, it is desirable to provide the one
used in the last received request.
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) have been successfully received.  The token to use MUST
be one of the tokens that were received in a request for this
latest MAX_PAYLOADS_SET block-wise exchange.  However, it is
desirable to provide the one used in the last received request.
The client should then release all of the tokens used for this
MAX_PAYLOADS_SET.
This Response Code MUST be returned for a Confirmable request if
the server does not support the Q-Block Options.  Note that a
reset message must be sent in case of Non-confirmable request.
This Response Code MUST be returned for a Confirmable request if
the server does not support the Q-Block Options.  Note that a
reset message may be sent in case of Non-confirmable request.
For Confirmable responses, the client continues to acknowledge each
packet.  Typically, the server acknowledges the initial request using
an ACK with the payload, and then sends the subsequent payloads as
CON responses.  The server will detect failure to send a packet, but
the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate
GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as
needed.
For Confirmable traffic, the server typically acknowledges the
initial request using an ACK with a piggybacked payload, and then
sends the subsequent payloads of the MAX_PAYLOADS_SET as CON
responses.  These CON responses are individually ACKed by the client.
The server will detect failure to send a packet and SHOULD terminate
the body transfer, but the client can issue, after a
MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or
iPATCH for any missing blocks as needed.
The data payload of the 4.08 (Request Entity Incomplete) response is
encoded as a CBOR Sequence RFC8742.  It comprises one or more missing
block numbers encoded as CBOR unsigned integers RFC8949.  The missing
block numbers MUST be unique in each 4.08 (Request Entity Incomplete)
response when created by the server; the client MUST ignore any
duplicates in the same 4.08 (Request Entity Incomplete) response.
The new data payload of the 4.08 (Request Entity Incomplete) response
with Content-Type set to "application/missing-blocks+cbor-seq" is
encoded as a CBOR Sequence RFC8742.  It comprises one or more missing
block numbers encoded as CBOR unsigned integers RFC8949.  The missing
block numbers MUST be unique in each 4.08 (Request Entity Incomplete)
response when created by the server; the client MUST ignore any
duplicates in the same 4.08 (Request Entity Incomplete) response.
This CDDL syntax MUST be followed.
By using 8-byte tokens, it is possible to easily minimize the
number of tokens that have to be tracked by clients, by keeping
the bottom 32 bits the same for the same body and the upper 32
bits containing the current body's request number (incrementing
every request, including every re-transmit).  This allows the
client to be alleviated from keeping all the per-request-state,
e.g., in Section 3 of RFC8974.
By using 8-byte tokens, it is possible to easily minimize the
number of tokens that have to be tracked by clients, by keeping
the bottom 32 bits the same for the same body and the upper 32
bits containing the current body's request number (incrementing
every request, including every re-transmit).  This allows the
client to be alleviated from keeping all the per-request-state,
e.g., in Section 3 of RFC8974.  However, if using NoSec,
Section 5.2 of RFC8974 needs to be considered for security
implications.
MAX_PAYLOADS should be configurable with a default value of 10.  Both
CoAP endpoints SHOULD have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level
protocol (out of scope of this document).  This is the maximum number
of payloads that can be transmitted at any one time.
MAX_PAYLOADS should be configured with a default value of 10.  Both
CoAP endpoints MUST have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level
protocol (out of scope of this document).  This is the maximum number
of payloads that can be transmitted at any one time.
If the CoAP peer reports that at least one payload has not arrived
for each body for at least a 24-hour period and it is known that
there are no other network issues over that period (e.g., DDoS
attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a
time (to a minimum of 1) and the situation re-evaluated for another
24-hour period until there is no report of missing payloads under
normal operating conditions.  Following a period of 24 hours where no
packet recovery was required, the value of MAX_PAYLOADS can be
increased by 1 (but without exceeding the default value) for a
further 24-hour evaluation.  The newly derived value for MAX_PAYLOADS
should be used for both ends of this particular CoAP peer link.  Note
that the CoAP peer will not know about the MAX_PAYLOADS change until
it is reconfigured.  As a consequence of the two peers having
different MAX_PAYLOADS values, a peer may continue indicating that
there are some missing payloads as all of its MAX_PAYLOADS_SET may
not have arrived.  How the two peer values for MAX_PAYLOADS are
synchronized is out of the scope.
Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits.  With
a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this
indicates an average speed requirement of 60 Kbps for a single
body should there be no responses.  This transmission rate is
further reduced by being subject to PROBING_RATE.
number that was indicated in the sent 2.31 (Continue).  If the repeat
request count for the 4.08 (Request Entity Incomplete) exceeds
NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and
stop requesting the missing payloads.
number that was indicated in the sent 2.31 (Continue).  If the
repeated response count of the 4.08 (Request Entity Incomplete)
exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
body and stop requesting the missing payloads.
Note that as 'Continue' was used, the server continues to use the
same token T:0xaa as the 'Continue' is not being used as a request
for a new set of packets, but rather is being used to instruct the
server to continue its transmission (cc-non).
Note that as 'Continue' was used, the server continues to use the
same token (0xaa) since the 'Continue' is not being used as a request
for a new set of packets, but rather is being used to instruct the
server to continue its transmission (cc-non).
If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec
security mode if either the Q-Block1 or Q-Block2 Options is used.
If NoSec is being used, Section D.5 of RFC8613 discusses the security
analysis and considerations for unprotected message fields even if
OSCORE is not being used.