jiebi/TextFlow huggingface dataset:
Original text:
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 <del> support for BERT (see bert). </del>  4.4.

Reviewer comments:
2/1 Conference call with Signaling authors BERT support can be enabled and then disabled: Max-Message-Size=1153 + Block-wise Transfer => Block-wise on + BERT on Max-Message-Size=1152 => Block-wise on + BERT off This should be noted.

Revised text:
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  <ins> support for BERT (see bert).  Subsequently, if the Max-Message-Size Option is indicated with a value equal or less than 1152, BERT support is no longer indicated. </ins> 4.4.
Original text:
Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes.  7.1. The "coap+tcp" URI scheme identifies CoAP resources that are intended

Reviewer comments:
RFC 7252 says about : in Section 6.1 of RFC 7252; it is maybe an erratum that we didn’t do the same in Section 6.2. In any case, we need to do this for all the new URI schemes we define in the current spec, probably best by a blanket statement for all of them at the start of section 7.
RFC 7252 Section 6.2 specifies support for .well-known paths by saying All of the requirements listed above for the "coap" scheme are also requirements for the "coaps" scheme [...] At least that's the intention.
OK, it is not clear that extending is a "requirement", so to me this is at least a "hold for document update" style erratum for RFC 7252. But it is good that the right intention is in there, even if not unambiguously said so.

Revised text:
Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes. <ins> As with the "coap" and "coaps" schemes defined in RFC7252, all URI schemes defined in this section also support the path prefix "/.well- known/" defined by RFC5785 for "well-known locations" in the namespace of a host.  This enables discovery as per Section 7 of RFC7252. </ins> 7.1. The "coap+tcp" URI scheme identifies CoAP resources that are intended
Original text:
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 <del> transports.  It also formally updates RFC7641 for use with these </del>  transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. 1. The RFC7252 was designed for Internet of Things (IoT) deployments, <del> assuming that UDP RFC0768 or DTLS RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. </del>  Some CoAP deployments need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received of a byte-stream.  A Block1 or Block2 option that includes an SZX value of 7.

Reviewer comments:
Updates for acronyms Minor style change to Abstract
Please spell out acronyms at first use. I will correct the BERT case and also review URL for other potential cases.

Revised text:
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  <ins> transports.  It also formally updates RFC 7641 for use with these </ins> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. 1. The RFC7252 was designed for Internet of Things (IoT) deployments,  <ins> assuming that UDP RFC0768 or Datagram Transport Layer Security (DTLS) RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. </ins> Some CoAP deployments need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received of a byte-stream. <ins> BERT extends RFC7959 to enable the use of larger messages over a reliable transport. </ins> A Block1 or Block2 option that includes an SZX value of 7.
Original text:
TLS is enabled.  The guidance in Section 4.4 of RFC7925 applies. <del> The "NoSec" mode is mandatory-to-implement.  The system simply sends </del>  the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port.  The system is secured only by keeping attackers from being able to send or receive packets from the

Reviewer comments:
: Section 8.1 makes it Mandatory to Implement the protocol without any security ("NoSec"). This seems counter to best practice in the IETF, but I'll defer to the Security Area review. I Carsten's position that this could become optional. History: Some context - during the security discussions in the WG, there was a recommendation to "mirror" the similar section in RFC7252. URL states: The NoSec and RawPublicKey modes are mandatory to implement for this specification. which is why NoSec is MTI.

Revised text:
TLS is enabled.  The guidance in Section 4.4 of RFC7925 applies.  <ins> The "NoSec" mode is optional-to-implement.  The system simply sends </ins> the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port.  The system is secured only by keeping attackers from being able to send or receive packets from the
Original text:
reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these <del> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </del>  1. [RFCthis]  11.  References 11.1.  URIs

Reviewer comments:
Add to Updates Updated Abstract Added IANA section to update related references for Block1 and Block2
: 3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc. My sense is that we should treat this as an update to RFC7959 based on the original language: and the use of "extension" in coap-tcp-tls: This also requires an IANA addition, since the entries for Block1 and Block2 need to also reference coap-tcp-tls in addition to RFC7959.

Revised text:
reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these  <ins> transports, RFC 7959 to enable the use of larger messages over a reliable transport, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </ins> 1. [RFCthis] <ins> 10.9. IANA is requested to add [RFCthis] to the references for the following entries registered by RFC7959 in the "CoAP Option Numbers" sub-registry defined by RFC7252: </ins> 11.  References 11.1.  URIs
Original text:
fixed header (first 4 bytes of the CoAP over UDP header), which includes the length information of variable size. <del> 4-bit unsigned integer.  A value between 0 and 12 directly </del>  indicates the length of the message in bytes starting with the first bit of the Options field.  Three values are reserved for special constructs: messages send a modified value. These are not default values for the option, as defined in <del> Section 5.4.4 in RFC7252.  A default value would mean that an empty Capabilities and Settings message would result in the option being set to its default value. </del>  Capabilities and Settings messages are indicated by the 7.01 code (CSM).

Reviewer comments:
(1) s/between 0 and 12/& inclusive/ (2) maybe revisit the language about default values vs. origin values for CSM options:

Revised text:
fixed header (first 4 bytes of the CoAP over UDP header), which includes the length information of variable size.  <ins> 4-bit unsigned integer.  A value between 0 and 12 inclusive </ins> indicates the length of the message in bytes starting with the first bit of the Options field.  Three values are reserved for special constructs: messages send a modified value. These are not default values for the option, as defined in  <ins> Section 5.4.4 in RFC7252.  Default values apply on a per-message basis and thus reset when the value is not present in a given Capabilities and Settings message. </ins> Capabilities and Settings messages are indicated by the 7.01 code (CSM).
Original text:
bidirectional exchange. Upon receipt of a Ping message, the receiver MUST return a Pong <del> message with an identical token in response.  Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand. </del>  Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).

Reviewer comments:
s/Unless there is an option with delaying semantics/Unless the PING carries an option with delaying semantics/

Revised text:
bidirectional exchange. Upon receipt of a Ping message, the receiver MUST return a Pong  <ins> message with an identical token in response.  Unless the Ping carries an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand. </ins> Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).
Original text:
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 <del> adjusted CoAP header format with a modified structure for the fixed header (first 4 bytes of the UDP CoAP header), which </del>  includes the length information of variable size, shown here as an 8-bit length. first bit of the Options field.  Three values are reserved for special constructs: <del> An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. </del>  <del> A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. </del>  <del> A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805. </del>  <del> The encoding of the Len field is modeled on CoAP Options (see section 3.1 of RFC7252). </del>  <del> The following figures show the shim headers for the 0-bit, 16-bit, and the 32-bit headers. </del>  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-

Reviewer comments:
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.

Revised text:
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  <ins> adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which </ins> includes the length information of variable size, shown here as an 8-bit length. first bit of the Options field.  Three values are reserved for special constructs:  <ins> An 8-bit unsigned integer (Extended Length) follows the initial byte and indicates the length of options/payload minus 13. </ins>  <ins> A 16-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 269. </ins>  <ins> A 32-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 65805. </ins>  <ins> The encoding of the Length field is modeled on CoAP Options (see section 3.1 of RFC7252). </ins>  <ins> The following figures show the message format for the 0-bit, 16-bit, and the 32-bit variable length cases. </ins> 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-
Original text:
it. To check the health of the WebSocket connection (and thereby of all <del> active requests, if any), the client can send a Ping frame or an unsolicited Pong frame as specified in Section 5.5 of RFC6455.  There is no way to retransmit a request without creating a new one.  Re- registering interest in a resource is permitted, but entirely </del>  unnecessary. 3.5. 4.4. In CoAP over TCP, Empty messages (Code 0.00) can always be sent and <del> MUST be ignored by the recipient (see also sec-ping).  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del>  Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

Reviewer comments:
There needs to be guidance about the intersection of WebSocket Ping-Pong and Signaling Ping-Pong.
Since Signaling Ping-Pong is a superset of WebSockets Ping-Pong and to use a consistent mechanism across reliable transports, I will add guidance that Signaling Ping-Pong is preferred over WebSockets Ping-Pong.

Revised text:
it. To check the health of the WebSocket connection (and thereby of all  <ins> active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely </ins> unnecessary. 3.5. 4.4. In CoAP over TCP, Empty messages (Code 0.00) can always be sent and  <ins> MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the
Original text:
8.2. <del> IANA is requested to create a sub-registry for signaling options similar to the CoAP Option Numbers Registry (Section 12.2 of RFC7252), with the single change that a fourth column is added to the sub-registry that is one of the codes in the Signaling Codes subregistry (message-codes). The name of this sub-registry is "CoAP Signaling Option Numbers". </del>  Initial entries in this sub-registry are as follows:

Reviewer comments:
URL The table 2 below isn't correct as it includes names not the signal codes from Table 1
URL Cl.8.2: I wonder if the first column in Table 3 should be "Applies to"? It seems more natural to look up the Signal Code to find the option, instead of the options which could have the same number.
URL 8.2. CoAP Signaling Option Numbers Registry s/one/one or more/

Revised text:
8.2.  <ins> IANA is requested to create a sub-registry for Options Numbers used in CoAP signaling options within the "CoRE Parameters" registry.  The name of this sub-registry is "CoAP Signaling Option Numbers". Each entry in the sub-registry must include one or more of the codes in the Signaling Codes subregistry (message-codes), the option number, the name of the option, and a reference to the option's documentation. </ins> Initial entries in this sub-registry are as follows:
Original text:
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. 1. namely TCP RFC0793, in some situations secured by TLS RFC5246. In addition, some corporate networks only allow Internet access via a <del> HTTP proxy.  In this case, the best transport for CoAP would be the </del>  RFC6455.  The WebSocket protocol provides two-way communication between a client and a server after upgrading an RFC7230 connection and may be available in an environment that blocks CoAP over UDP. intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should.
URL Appendix A. Updates to RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) This needs to be referenced from the main body in some form.

Revised text:
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 <ins> transports.  It also formally updates RFC7641 for use with these </ins> transports. 1. namely TCP RFC0793, in some situations secured by TLS RFC5246. In addition, some corporate networks only allow Internet access via a  <ins> HTTP proxy.  In this case, the best transport for CoAP might be the </ins> RFC6455.  The WebSocket protocol provides two-way communication between a client and a server after upgrading an RFC7230 connection and may be available in an environment that blocks CoAP over UDP. intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP. <ins> observing updates RFC7641 for use with CoAP over reliable transports. RFC7641 is an extension to the CoAP core protocol that enables CoAP clients to "observe" a resource on a CoAP server.  (The client retrieves a representation of a resource and registers to be notified by the server when the representation is updated.) </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
The payload of a CoAP message that is affected by a BERT Option in descriptive usage (Section 2.1 of RFC7959).  2. The request/response interaction model of CoAP over TCP is the same

Reviewer comments:
And changed Len to Len=0 for websocket message format in Figure 14.
URL Figure 4: CoAP frame with 8-bit Extended Length field. This (and neither does the text) does not make clear that the payload marker is sent only if there is a non-zero-length payload. (Same for other below.) Please cf. text from Section 3 of RFC 7252: Figure 14: CoAP Message Format over WebSockets Maybe show 0, not Len here. (This also does not make clear that the payload marker is sent only if there is a non-zero-length payload.)
It's a bit awkward to insert text about the Payload Marker, since other fields are not re-introduced from RFC7252. In RFC8030, we used the Conventions and Terminology section to also provide more context for examples based on feedback from the reviewers. One possibility is to use a similar approach here and indicate that all framing examples have the Payload Marker set. And of course, the "(if any)" would need to be removed. And then there's still the need to clarify the WS case due to the requirement to set the Len to 0 and rely on the WS frame.

Revised text:
The payload of a CoAP message that is affected by a BERT Option in descriptive usage (Section 2.1 of RFC7959). <ins> For simplicity, a Payload Marker (0xFF) is present in all examples for message formats: The Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see section 3 of RFC7252). </ins> 2. The request/response interaction model of CoAP over TCP is the same
Original text:
2.3.  A describes a relationship between two resources on the Web.  As in This section defines the encoding of documents in the CoRAL binary format. <del> A document in the binary format is encoded in RFC8949.  The encoding MUST satisfy the Core Deterministic Encoding Requirements specified in RFC8949. </del>  The CBOR structure of a document is presented in the RFC8610.  All CDDL rules not defined in this document are defined in RFC8610.

Reviewer comments:
The requirement was probably a left-over from when CRIs where specified in here; the current document has no use for the properties obtainable from this. Closes: URL
The current text says: I think this is a remnant from when CoRAL and CRI were a single document; I don't see any reason to prescribe this for CoRAL. Any objections to removing that?

Revised text:
2.3. <ins> [ TBD move information model in here ] </ins> A describes a relationship between two resources on the Web.  As in This section defines the encoding of documents in the CoRAL binary format.  <ins> A document in the binary format is encoded in RFC8949. </ins> The CBOR structure of a document is presented in the RFC8610.  All CDDL rules not defined in this document are defined in RFC8610.
Original text:
In particular, the precise data from one structured information document can only be expressed at the same URI.  However, statements <del> can be added to make a data set that is expressible elsewhere, and subsets of the data can be taken and expressed. </del>  Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes. This subsection illustrates the information model and serialization based on an example from RFC6690: <del> After an extraction (currently not defined in this document), this list represents the content of the basic information model representing the above.  For the basic model, the table is to be considered unsorted in the first step. </del>  During extraction, some information on item ordering was preserved into the structured data.  Note that while the CoRAL structured data order of attributes), others (like the relative order of links from different contexts) are deemed irrelevant and not preserved. <del> For serialization, a (so far unspecified) packing was picked, resulting in a binary CBOR file with this CBOR diagnostic notation: </del>  Note that the "temperature-c" interface and "sensor" resource type get code points in the link-format dictionary because they are of

Reviewer comments:
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).

Revised text:
In particular, the precise data from one structured information document can only be expressed at the same URI.  However, statements  <ins> can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the "http://www.iana.org/assignments/relation/carries- information-about" predicate being usable here), and subsets of the data can be taken and expressed. </ins> Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes. This subsection illustrates the information model and serialization based on an example from RFC6690:  <ins> After an extraction described in convert-6690, this list represents the content of the basic information model representing the above. For the basic model, the table is to be considered unsorted in the first step. </ins> During extraction, some information on item ordering was preserved into the structured data.  Note that while the CoRAL structured data order of attributes), others (like the relative order of links from different contexts) are deemed irrelevant and not preserved.  <ins> For serialization, the use of the packing described with the conversion results in a binary CBOR file with this CBOR diagnostic notation: [ TBD: Numbers are made up ] </ins> Note that the "temperature-c" interface and "sensor" resource type get code points in the link-format dictionary because they are of