jiebi/CodeConvo huggingface dataset:
Change:
We already had the understanding that no one will attempt to deploy the extension for TLS 1.2 and earlier, since it would be plagued with middlebox compatibility issues that TLS 1.3 already faces. However, it was left as supported because there was no cost to supporting it. On the list, David Benjamin has pointed out that: clients have no way to ask for "compress only in TLS 1.3" policy, meaning that they have to assume that a TLS 1.2 connection could attempt to use this extension; clients have to support certificate compression in TLS 1.2 as a result. This adds complexity for no reason, and the problem is easily solved by restricting the extension to 1.3 or higher.
:+1: LGTM

Discussion:
3. <ins> This extension is only supported with TLS 1.3 and newer; if TLS 1.2 or earlier is negotiated, the peers MUST ignore this extension. </ins> This document defines a new extension type (compress_certificate(TBD)), which can be used to signal the supported compression formats for the Certificate message to the peer.  Whenever it is sent by the client as a ClientHello message <del> extension (RFC5246, Section 7.4.1.4), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates.  Note that CertificateRequest messages are not supported by TLS versions prior to 1.3. </del> <ins> extension (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates. </ins> By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use

and try to validate the Certificate message exchanged during a TLS handshake.  This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections <del> that adopt certificate compression. However this is not a problem when using TLS version 1.3 I-D.ietf- tls-tls13 and higher, due to the fact that the Certificate (and thus the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. </del> <ins> that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and higher. </ins> 7.
Change:
This mechanism is also useful for cases where the pub/sub paradigm instead of classic req/resp is desired (one-to-many, many-to-one, many-to-many communications, etc.).

Discussion:
to-machine communication across networks of constrained devices. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources.  Depending on the <del> situation the same device may act either as a server or a client. </del> <ins> situation the same device may act either as a server, a client, or both. </ins> One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging

connecting to a device from the Internet unless the connection was initiated by the device. <del> This document specifies the means for nodes with limited reachability to communicate using simple extensions to CoAP.  The extensions enable publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes. Furthermore the extensions facilitate many-to-many communication using CoAP. </del> <ins> For some applications the client/server and request/response communication model is not optimal but publish-subscribe communication with potentially many senders and/or receivers and communication via topics rather than directly with endpoints may fit better. This document specifies simple extensions to CoAP for enabling publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes.  This model facilitates communication of nodes with limited reachability, enables simple many-to-many communication, and eases integration with other publish-subscribe systems. </ins> 2.

indicated by a link-format content-format.  Sub-topics are also topics and may have their own sub-topics, forming a tree structure of unique paths that is implemented using URIs.  The full URI of a topic <del> includes a schems and authority for the Broker, for example </del> <ins> includes a scheme and authority for the Broker, for example </ins> "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700". 3.5.

If the Broker is unable to serve a certain client that is sending publish messages too fast, the Broker SHOULD respond with Response <del> Code 4.29, "Too Many Requests" I-D.keranen-core-too-many-reqs and set </del> <ins> Code 4.29, "Too Many Requests" I-D.ietf-core-too-many-reqs and set </ins> the Max-Age Option to indicate the number of seconds after which the client can retry.  The Broker MAY stop creating notifications from the publish messages from this client and to this topic for the
Change:
removed duplicate description of hierarchy, added a constraint to allow only one topic to be created at a time, added text to allow additional target attributes in links for created topics

Discussion:
of the CoRE link format RFC6690.  The target of the link MUST be a URI formatted string.  The client MUST indicate the desired content format for publishes to the topic by using the ct (Content Format) <del> link attribute in the link-format payload.  The client MAY indicate the lifetime of the topic by including the Max-Age option in the CREATE request. Topics may be created as sub-topics of other topics.  A client MAY create a topic with a ct (Content Format) link attribute value which describes a supported serialization of the CoRE link format RFC6690 such as application/link-format (ct=40) or its JSON or CBOR serializations.  If a topic is created which describes a link </del> <ins> link attribute in the link-format payload.  Additional link target attributes and relation values may be included in the topic specification link whena topic is created. The client MAY indicate the lifetime of the topic by including the Max-Age option in the CREATE request. Topic hierarchies can be created by creating parent topics.  A parent topic is created with a POST using ct (Content Format) link attribute value which describes a supported serialization of the CoRE link format RFC6690, such as application/link-format (ct=40) or its JSON or CBOR serializations.  If a topic is created which describes a link </ins> serialization, that topic may then have sub-topics created under it as shown in create-sub-fig.

A topic creator MUST include exactly one content format link attribute value (ct) in the create payload.  If the Broker does not <del> support the indicated format for both publish and subscribe, it MUST reject the operation with an error code of 4.00 "Bad Request". </del> <ins> support the indicated format for both publish and subscribe, or if there is more than one "ct" value included in the request, the Broker MUST reject the operation with an error code of 4.00 "Bad Request". Only one topic may be created per request.  If there is more than one link included in a CREATE request, the Broker MUST reject the operation with an erroro code of 4.00 "Bad Request". </ins> There is no default content format.  If no ct is specified, the Broker MUST reject the operation with an error code of 4.00 "Bad

upon topic creation.  The lifetime of a topic MUST be refreshed upon create operations with a target of an existing topic. <del> Topic hierarchies can be created by creating parent topics.  A parent topic is created with a POST using ct (Content Format) link attribute value which describes a supported serialization of the CoRE link format RFC6690, such as application/link-format (ct=40) or its JSON or CBOR serializations.  If a topic is created which describes a link serialization, that topic may then have sub-topics created under it as shown in create-sub-fig. </del> The CREATE interface is specified as follows: Client -> Broker
Change:
Corrected title for (leaving open while we discuss examples) Corrected version for new since-draft section
It only has examples of Ping and Pong. (It would probably help to have an example of an initial CSM exchange.)
Or perhaps eliminate the examples? I note that RFC7252 does not include Option examples.
I'd rather do the work to include an initial CSM exchange. Just not sure I can get to that tomorrow. (This kind of example is counter-intimidating — after all the verbiage you see that it is all really very simple...)
I'm not sure that it was intimidating although I like counter-intimidating. It was certainly not a source of confusion during WGLC that then required clarification in examples. I worry about simply adding noise. And if pursued further, we should avoid Default-Uri-Host which would leave Max-Message-Size and Block-wise Transfer.
I corrected the title in . I'm won't fixing the suggestion for CSM examples based on my previous comment. This can be revisited if there's any related confusion during subsequent reviews.

Discussion:
basic keep-alive function.  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 </del> <ins> Upon receipt of a Ping message, the receiver MUST return a Pong 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 </ins> recipient of a Ping or Pong message MUST ignore elective options it does not understand.
Change:
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.

Discussion:
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> <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.
Change:
Doesn't this need an IANA considerations section - URL
We are not creating a registry here; we are extending the semantics of the existing registry created by RFC 5875 to two existing URI schemes. No IANA action required. (We do have an IANA action for registering in that existing registry.)
I was thinking of something like this - URL
Yes -- URL
Doh. For some reason, I got hung up on needing a separate reference for RFC6455, but only the URI suffix is registered. I can appreciate that the lack of a separate draft could be confusing based on the layout of the registry - which will only reference coap-tcp-tls. Sorry for the noise.
: Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use ...

Discussion:
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 RFC7641 for use with these <del> transports. </del> <ins> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </ins> 1.

The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path <del> "/.well-known/coap" RFC5785.  The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </del> <ins> "/.well-known/coap" RFC5785.  The present specification formally updates RFC6455, extending the well-known URI mechanism defined in RFC5785 to also cover the "ws" URI scheme defined in that document. The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986.

The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path <del> "/.well-known/coap" RFC5785.  The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </del> <ins> "/.well-known/coap" RFC5785.  The present specification formally updates RFC6455, extending the well-known URI mechanism defined in RFC5785 to also cover the "wss" URI scheme defined in that document. The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986.
Change:
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.

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

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 <del> transports.  It also formally updates RFC7641 for use with these </del> <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, <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> <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.
Change:
: 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.

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

Discussion:
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> <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
Change:
(1) s/between 0 and 12/& inclusive/ (2) maybe revisit the language about default values vs. origin values for CSM options:

Discussion:
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> <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 <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> <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).
Change:
s/Unless there is an option with delaying semantics/Unless the PING carries an option with delaying semantics/

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

Discussion:
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> <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: <del> An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. </del> <ins> An 8-bit unsigned integer (Extended Length) follows the initial byte and indicates the length of options/payload minus 13. </ins> <del> A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. </del> <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> <del> A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805. </del> <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> <del> The encoding of the Len field is modeled on CoAP Options (see section 3.1 of RFC7252). </del> <ins> The encoding of the Length field is modeled on CoAP Options (see section 3.1 of RFC7252). </ins> <del> The following figures show the shim headers for the 0-bit, 16-bit, and the 32-bit headers. </del> <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-
Change:
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.

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