Draft: draft-ietf-core-new-block

Commentary: Updated code pushed
Mixing of NON and CON during requests/responses using Q-Block is
not supported.
Alternatively, with CoAP over reliable transports, Capabilities and
Settings Messages (CSMs) can be used to indicate support of Q-Block
Options by means of the Q-Block-Wise-Transfer Capability Option
(Table 2).  The behavior of CoAP peers is similar to the one
specified in Section 5.3.2 of RFC8323, except that it indicates
support of Q-Block Options.
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
Options, are both a class E and a class U in terms of OSCORE
processing (Table 3).  The Q-Block1 (or Q-Block2) Option MAY be an
Inner or Outer option (Section 4.1 of RFC8613).  The Inner and Outer
values are therefore independent of each other.  The Inner option is
encrypted and integrity protected between clients and servers, and
provides message body identification in case of end-to-end
fragmentation of requests.  The Outer option is visible to proxies
and labels message bodies in case of hop-by-hop fragmentation of
requests.
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
Options, are both a class E and a class U in terms of OSCORE
processing (Table 2).  The Q-Block1 (or Q-Block2) Option MAY be an
Inner or Outer option (Section 4.1 of RFC8613).  The Inner and Outer
values are therefore independent of each other.  The Inner option is
encrypted and integrity protected between clients and servers, and
provides message body identification in case of end-to-end
fragmentation of requests.  The Outer option is visible to proxies
and labels message bodies in case of hop-by-hop fragmentation of
requests.
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT primarily for use with NON (Table 4).
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
If the CoAP peer reports 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, 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.  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 not being reconfigured, the peer may indicate that
there are some missing payloads prior to the actual payload being
transmitted as all of its MAX_PAYLOADS payloads have not arrived.
If the CoAP peer reports 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, 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.  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 indicate 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.
This document requests IANA to register the following option in the
"CoAP Signaling Option Numbers" registry CSM.
This document suggests 8 (TBA4) as a value to be assigned for the new
option number.