jiebi/CodeConvo huggingface dataset:
Change:
Replacing "CoAP over TCP, TLS and Websockets" with "CoAP over reliable transports" is a good idea to reduce repetition. I feel it might be a good idea to clarify when we refer to reliable transports, that we actually refer to stream-based reliable transports. Datagram-based reliable transports (eg DCCP, QUIC, etc) exist, which render the Message Framing layer in Figure 1 unnecessary. I'm not advocating that we run CoAP over QUIC, DCCP etc but perhaps clarification would be wise.
See also
I would add a note to the terminology section that CoAP over reliable transports refers to stream-based transport protocols, such as TCP.
Sounds reasonable: The term "reliable transport" only refers to stream-based transport protocols such as TCP.
URL The term "reliable transport" only refers to stream-based transport protocols such as TCP. We could say more explicitly: sequenced/order-preserving, reliable... (Stream might be byte stream or message stream.) s/only refers/is used only to refer/
NAME - I would probably avoid "sequenced" which suggests sequence numbers and acknowledgements which are the mechanism to provide reliability. Perhaps too much detail? How about: The term "reliable transport" is used only to refer to transport protocols such as TCP which provide reliable and ordered delivery of a byte-stream.
NAME wrote: This concisely clarifies my initial concern, and I'm ok with this.

Discussion:
CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. <del> To address such environments, this document defines how to transport </del> <ins> Emerging standards such as Lightweight Machine to Machine LWM2M currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments in existing CoAP implementations and deployments.  Although HTTP/2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP. To address these requirements, this document defines how to transport </ins> CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. layering illustrates the layering:

This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252. <ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP. </ins> A Block1 or Block2 option that includes an SZX value of 7.

CoAP over TCP message format.  All messages are also untyped. fig-flow-comparison illustrates the difference between CoAP over UDP <del> and CoAP over reliable transport.  The removed Type (no type) and Message ID fields are indicated by dashes. </del> <ins> and CoAP over reliable transport.  The removed Type and Message ID fields are indicated by dashes. </ins> 2.2.
Change:
There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.

Discussion:
The payload of a CoAP message that is affected by a BERT Option in <del> descriptive usage (Section 2.1 of I-D.ietf-core-block). </del> <ins> descriptive usage (Section 2.1 of RFC7959). </ins> 2.

WebSocket protocol does not provide means for multiplexing.  If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as <del> defined in I-D.ietf-core-block. </del> <ins> defined in RFC7959. </ins> Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping).

4.3.3. A sender can use the Block-wise Transfer elective Option to indicate <del> that it supports the block-wise transfer protocol I-D.ietf-core- block. </del> <ins> that it supports the block-wise transfer protocol RFC7959. </ins> If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not.  An

The message size restrictions defined in Section 4.6 of CoAP RFC7252 to avoid IP fragmentation are not necessary when CoAP is used over a reliable byte stream transport.  While this suggests that the Block- <del> wise transfer protocol I-D.ietf-core-block is also no longer needed, it remains applicable for a number of cases: </del> <ins> wise transfer protocol RFC7959 is also no longer needed, it remains applicable for a number of cases: </ins> large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single TCP connection is used

The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved <del> value in I-D.ietf-core-block. </del> <ins> value in RFC7959. </ins> In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the
Change:
Also clarifies that "same kind" in Alternate-Address refers to scheme.
When I submitted the original pull request, I also posed a question on the but did not receive a response. One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2: URL To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
I support not blocking the device until the server CSM. The server can choose to not process messages that are invalid (e.g. too large) and immediately follow up with the server CSM. From the perspective of a cloud and gateway software provider, the CoAP (using TCP/TLS) server will usually be in the cloud or gateway and therefore usually not power constrained. I may be missing other scenarios where a battery powered device is acting as a CoAP/TCP server. Does anyone have plans for any of those scenarios?
NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.

Discussion:
transfers.  The absence of options in the CSM indicates that base values are assumed. <ins> To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (See max-message-size) that is smaller than the base value (1152). </ins> Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort).

this server. The Alternative-Address elective option requests the peer to instead <del> open a connection of the same kind as the present connection to the </del> <ins> open a connection of the same scheme as the present connection to the </ins> alternative transport address given.  Its value is in the form "authority" as defined in Section 3.2 of RFC3986.
Change:
Also updated one more case of "messaging layer" rather than "message layer of"
Consider either removing the UDP to TCP gateway section (URL) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.
Good point - in Hannes's earlier draft, this was more of an example than a separate section - URL A UDP-to-TCP gateway will therefore discard all empty messages, such as empty ACKs (after operating on them at the message layer), and re- pack the contents of all non-empty CON, NON, or ACK messages (i.e., those ACK messages that have a piggy-backed response) into untyped messages (that happen to look like NON messages).

Discussion:
message that on datagram transports is provided by the UDP/DTLS datagram layer. <del> TCP ensures reliable message transmission, so the CoAP over TCP messaging layer is not required to support acknowledgements or to </del> <ins> TCP ensures reliable message transmission, so the message layer of CoAP over TCP is not required to support acknowledgements or to </ins> detect duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the CoAP over TCP message format.

2.2. <del> A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00) after processing at the message layer.  For Confirmable (CON), Non- Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. 2.3. </del> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the

Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). <del> 2.4. </del> <ins> 2.3. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping

The semantics of the other CoAP header fields are left unchanged. <del> 2.5. </del> <ins> 2.4. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without
Change:
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/

Discussion:
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> <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:
Change:
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.

Discussion:
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 <del> HTTP proxy.  In this case, the best transport for CoAP would be the </del> <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",
Change:
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.

Discussion:
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
Change:
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?

Discussion:
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. <del> A document in the binary format is encoded in RFC8949.  The encoding MUST satisfy the Core Deterministic Encoding Requirements specified in RFC8949. </del> <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.
Change:
Closes: URL This builds on
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 ).

Discussion:
The <del> is a sequence of "passings" the basic model's edges, where </del> <ins> is a sequence of "passings" of the basic model's edges, starting at a node identifying the document (its retrieval context, typically URI from which it was obtained) where </ins> each edge is passed at least one time in total, each edge is passed at most one time after each passing that ends in its start point (with the obvious exception that edges from the <del> root node can be passed once from the start), and </del> <ins> retrieval context can be passed once from the start), and </ins> between a passing of an edge from A to B and a later passing from B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing. <del> The passings starts at the root node, usually defined as the URI from which the document is obtained. </del> For better understanding, think of the structured information model <del> as a sort of tree spanning from the root node, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. </del> <ins> as a sort of tree spanning from the retrieval context, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. </ins> 1.1.2.

data set, because There may not be a tree that covers the directed graph, or the <del> tree's root may not be the URI from which the document is obtained. </del> <ins> tree's root may not be the retrieval context. </ins> There may be multiple edges into a blank node. In particular, the precise data from one structured information <del> document can only be expressed with the same root node.  However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the </del> <ins> document can only be expressed with the same retrieval context. However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries- information-about" relation type leading to the </ins> "http://www.iana.org/assignments/relation/carries-information-about" predicate being usable here), and subsets of the data can be taken and expressed.
Change:
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 ).

Discussion:
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> <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: <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> <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. <del> For serialization, a (so far unspecified) packing was picked, resulting in a binary CBOR file with this CBOR diagnostic notation: </del> <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
Change:
This replaces the previous mechanism of having bespoke dictionaries with Packed CBOR. Other places in the text still talk of "dictionaries", but that's not necessarily wrong, it's a term even used occasionally in packed.

Discussion:
3.2. A document in the binary format MAY reference values from an external <del> dictionary.  This helps to reduce representation size and processing cost.  Dictionary references can be used in place of link relation types, link targets, operation types, submission targets, form field types, and form field values. </del> <ins> dictionary using Packed CBOR I-D.ietf-cbor-packed.  This helps to reduce representation size and processing cost. </ins> <del> 3.2.1. A dictionary reference is encoded as an unsigned integer.  Where a dictionary reference cannot be expressed unambiguously, the unsigned integer is tagged with CBOR tag TBD6, as follows: </del> <ins> Dictionary references can be used subject to [ yet to be defined ] profiling. </ins> <del> A dictionary reference MUST NOT refer to a dictionary value that would otherwise not be syntactically allowed in that position.  For example, a dictionary reference in the position of a link relation type cannot refer to a Boolean value; it can only refer to an IRI. </del> <ins> Implementers should note that Packed CBOR is not designed to be uncompressed, but to be used in a compressed form.  In particular, constrained devices may operate without even knowing what a given dictionary entry expands to (as long as they know its meaning) . </ins> <del> 3.2.2. </del> <ins> 3.2.1. </ins> The "application/coral+cbor" media type for documents in the binary format is defined to have a "dictionary" parameter that specifies the