jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-new-block

Commentary: Updates pushed and squashed out all the merge master notifications .
There is little, if any, benefit of using these options with CoAP
running over a reliable connection RFC8323.  In this case, there is
no differentiation between Confirmable and NON as they are not used.
There is little, if any, benefit of using these options with CoAP
running over a reliable connection RFC8323.  In this case, there is
no differentiation between Confirmable and NON as they are not used.
Some examples using a reliable transport are provided in REL.
For Confirmable responses, the client continues to acknowledge each
packet.  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 responses, the client continues to acknowledge each
packet.  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.
Draft: draft-ietf-core-new-block

Commentary: Changes pushed 
 No need to use No - Response with ' continue ' Block defined in -04
Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
PATCH, and iPATCH requests and their responses (2.01 and 2.04).
This Response Code indicates successful receipt of the entire body
and the resource was deleted when using POST (See Section 5.8.2
RFC7252).  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
FETCH request body (See Section 2 of RFC8132) and the appropriate
representation of the resource has been returned.  The token used
in the response MUST be the one in the FETCH request that has the
Q-Block1 with the M bit unset.  If the FETCH request includes the
Observe Option, then the server MUST use the same token for
returning any Observe triggered responses.  The client should then
release all of the tokens used for this body unless a resource is
being observed.
b12non illustrates the example of a FETCH using both Q-Block1 and
Q-Block2 along with an Observe.  No loss is experienced.
b12non0 illustrates the same as b12non but this time has eleven (11)
payloads in both directions which exceeds MAX_PAYLOADS.  There is no
loss experienced.
If there is a loss of a message with a Q-Block1 Option, this is
handled as shown in B3non1 and B3non2 with FETCH substitued for PUT
and 2.04 becomes a 2.05 response.
If there is a loss of a message with a Q-Block2 Option, this is
handled as shown in nonb411 with FETCH substitued for GET.
Draft: draft-ietf-core-new-block

Commentary: The draft describes this all as " just working through a proxy " -- original block - wise does not , and I 'd like to hear how this is hoping to get away without the options being proxy - unsafe . Is there any point at all in using block - by - block proxying for these use cases ? Unless a proxy is sitting right inside the link under attack , and unless the bodies get huge , it may be way easier for this to be purely hop - by - hop . Proxies would reassemble the full bodies and , for the next hop , just decide what works best there ( be it regular block - wise ,  or BERT ) . ( If there 's a point in allowing block - by - block forwarding , we can talk it through and work through the initial ideas that will come up like " We use large enough Request - Tag values so they are unique " , " how large does that need to be " , " why do we end up having a Request - Tag in every request now " and " why do we not want that " , but my gut feeling is we wo n't need to go there . )
This is used to confirm that the current set of MAX_PAYLOADS
payloads have been successfully received and that, upon receipt,
the peer can continue to sent the next set of payloads.  This is
the 'Continue' Q-Block-2.
This is a request for the remaining payloads in the current
MAX_PAYLOADS set.
This is used to confirm that the current set of MAX_PAYLOADS
payloads (the latest one having block number NUM-1) has been
successfully received and that, upon receipt of this request, the
server can continue to send the next set of payloads (the first
one having block number NUM).  This is the 'Continue' Q-Block-2.
This is a request for that block and for all of the remaining
blocks in the current MAX_PAYLOADS set.
The token to use for the response SHOULD be the token that was used
in the highest block number received payload.  Note that the use of
any received token would work, but providing the one used in the
highest received block number will aid any troubleshooting.  The
client will use the token to match the request to find what Request-
Tag value is currently being used.
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.