jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-coap-tcp-tls

Commentary: These labels are confusing and should be rewritten more in the style of RFC6455 with " Length " and " Extended Length " for clarity . 
 And remember to replace the last reference to : The following figures show the shim headers for the 0 - bit , 16 - bit , and the 32 - bit headers .
In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed.  For this purpose, CoAP over TCP
introduces a length field with variable size. fig-frame shows the
adjusted CoAP header format with a modified structure for the
fixed header (first 4 bytes of the UDP CoAP header), which
includes the length information of variable size, shown here as an
8-bit length.
In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed.  For this purpose, CoAP over TCP
introduces a length field with variable size. fig-frame shows the
adjusted CoAP message format with a modified structure for the
fixed header (first 4 bytes of the CoAP over UDP header), which
includes the length information of variable size, shown here as an
8-bit length.
An 8-bit unsigned integer follows the initial byte and
indicates the length of options/payload minus 13.
A 16-bit unsigned integer in network byte order follows the
initial byte and indicates the length of options/payload minus
269.
A 32-bit unsigned integer in network byte order follows the
initial byte and indicates the length of options/payload minus
65805.
The following figures show the shim headers for the 0-bit, 16-bit,
and the 32-bit headers.
An 8-bit unsigned integer (Extended Length) follows the initial
byte and indicates the length of options/payload minus 13.
A 16-bit unsigned integer (Extended Length) in network byte
order follows the initial byte and indicates the length of
options/payload minus 269.
A 32-bit unsigned integer (Extended Length) in network byte
order follows the initial byte and indicates the length of
options/payload minus 65805.
The encoding of the Length field is modeled on CoAP Options (see
section 3.1 of RFC7252).
The following figures show the message format for the 0-bit, 16-bit,
and the 32-bit variable length cases.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Adapted changes from Hannes - primarily moving BERT to follow the Signal section .
Block-wise-Transfer is an elective option with an empty value.  If
the option is not given, the peer has no information about whether
block-wise transfers are supported by the sender or not.  An
implementation that supports block-wise transfers SHOULD indicate the
Block-Wise Transfer option.  If a Max-Message-Size option is
indicated with a value that is greater than 1152 (in the same or a
different CSM message), the Block-Wise Transfer option also indicates
support for BERT.
Block-wise-Transfer is an elective option with an empty value.  If
the option is not given, the peer has no information about whether
block-wise transfers are supported by the sender or not.  An
implementation that supports block-wise transfers SHOULD indicate the
Block-Wise Transfer option.  If a Max-Message-Size option is
indicated with a value that is greater than 1152 (in the same or a
different CSM message), the Block-Wise Transfer option also indicates
support for BERT (see bert).
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Adapted changes from Hannes
The request/response interaction model of CoAP TCP/TLS is similar to
CoAP UDP.  The primary differences are in the message layer.  CoAP
UDP supports optional reliability by defining four types of messages:
Confirmable, Non-confirmable, Acknowledgement, and Reset.  TCP
eliminates the need for the message layer to support reliability.  As
a result, message types are not defined in CoAP TCP/TLS.
The request/response interaction model of CoAP TCP/TLS is the same as
CoAP UDP.  The primary differences are in the message layer.  CoAP
UDP supports optional reliability by defining four types of messages:
Confirmable, Non-confirmable, Acknowledgement, and Reset.  TCP
eliminates the need for the message layer to support reliability.  As
a result, message types are not defined in CoAP TCP/TLS.
fig-flow-comparison illustrates the difference between CoAP over UDP
and CoAP over reliable transport.  The removed Type (no type) and
Message ID fields are indicated by dashes.
In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed.  For this purpose, CoAP over TCP
introduces a length field with variable size. fig-shim shows the
adjusted CoAP header format with a modified structure for the
fixed header (first 4 bytes of the UDP CoAP header), which
includes the length information of variable size, shown here as an
8-bit length.
In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed.  For this purpose, CoAP over TCP
introduces a length field with variable size. fig-frame shows the
adjusted CoAP header format with a modified structure for the
fixed header (first 4 bytes of the UDP CoAP header), which
includes the length information of variable size, shown here as an
8-bit length.
For example: A CoAP message just containing a 2.03 code with the
token 7f and no options or payload would be encoded as shown in fig-
shim2.
For example: A CoAP message just containing a 2.03 code with the
token 7f and no options or payload would be encoded as shown in fig-
frame2.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Adapted changes from Hannes
To address such environments, this document defines additional
bindings for CoAP, including TCP, TLS, and WebSockets.
Some environments may also benefit from the ability of TCP to
exchange larger payloads such as firmware images without application
layer segmentation and to utilize the more sophisticated congestion
control capabilities provided by many TCP implementations.
Some environments may also benefit from the ability of TCP to
exchange larger payloads, such as firmware images, without
application layer segmentation and to utilize the more sophisticated
congestion control capabilities provided by many TCP implementations.
The protocol stack is illustrated in stack.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Adapted changes from Hannes
Some environments would benefit from the availability of CoAP over
reliable transports such as TCP or WebSockets, which already provide
such services.  This document outlines the changes required to use
CoAP over TCP, TLS, and WebSockets transports.
Some environments benefit from the availability of CoAP carried over
reliable transports such as TCP or TLS.  This document outlines the
changes required to use CoAP over TCP, TLS, and WebSockets
transports.