jiebi/CodeConvo huggingface dataset:
Code change:
write data, understanding when stream flow control credit (data- flow-control) has successfully been reserved to send the written <del> data </del> <ins> data; </ins> end the stream (clean termination), resulting in a STREAM frame (frame-stream) with the FIN bit set; and reset the stream (abrupt termination), resulting in a RESET_STREAM <del> frame (frame-reset-stream), even if the stream was already ended. </del> <ins> frame (frame-reset-stream), if the stream was not already in a terminal state. </ins> On the receiving part of a stream, application protocols need to be able to: <del> read data </del> <ins> read data; and </ins> abort reading of the stream and request closure, possibly <del> resulting in a STOP_SENDING frame (frame-stop-sending) </del> <ins> resulting in a STOP_SENDING frame (frame-stop-sending). </ins> Applications also need to be informed of state changes on streams, including when the peer has opened or reset a stream, when a peer

Related discussion:
text: , requires transport stacks to support abrupt closure of a stream even after the stream has been cleanly closed. This reflects the possibility to transition from "Data Sent" (stream has ended) to "Reset Sent" by sending a RESETSTREAM. Based on the state diagram in the transport doc, if an implementation was already in the "Data Recvd" state, they wouldn't actually send a RESETSTREAM, as they're already in a terminal state; a reset call would be a no-op or an error of some kind. However, NAME points out that in a handle-based API, this essentially means that handles for closed streams have to be recognizable as such for the lifetime of the connection. This might be burdensome for some implementations. Should we reword the requirement here to say that it's permitted if the stream hasn't yet reached the "Data Recvd" state.
This was clearly just a miss on the wording. I don't think that the intent was ever to require that streams be kept around indefinitely. Sure, some stacks might be able to send RESET_STREAM at a whim, but it's not necessary
Code change:
The semantics of the other CoAP header fields are left unchanged. <del> 2.4. </del> <ins> 2.5. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without

Related discussion:
text: This text does not address who might be allowed to wait for the other guy to make their statement (if both wait, there is a deadlock).
The intention is that neither side needs to wait. The only open issue is whether we want to allow the client to immediately start sending messages after it sends its CSM without waiting for the server CSM similar to the HTTP/2 case. I planned to discuss that on-list when I "advertised" this set of pull requests.
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.
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?
Code change:
The semantics of the other CoAP header fields are left unchanged. <del> 2.4. </del> <ins> 2.5. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without

Related discussion:
text: 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.
Michel Veillette points out that a peer that wants to use a new connection has an uncertainty whether a CSM message with capability indications will come or not, so it is hard to decide when to send the first request (either based on default capabilities or waiting for the CSM to come in). One way out of having to do arbitrary waits would be to require the exchange of a CSM message (even an option-less one) after connection setup. The burden is very low, as a minimal implementation would just need to send a constant message of 0x00 0xe1 at setup. This requirement could be stated without giving a sequence, effectively allowing both sides to send the initial CSM in parallel, or it could give the listener the opportunity to not send its CSM until the connection opener has sent theirs, trying to avoid the need to answer right away to a connection setup -- this makes it too easy to scan for ports (OK, we also have a default port, and making scanning harder does not by itself provide any security, but it sure makes life a little harder for the attacker). (To avoid deadlock, the connection opener would not have the opportunity to wait sending the CSM.)
+1 ... especially for Maximum-Message-Size. HTTP/2 has a similar flow for SETTINGS during connection including potentially empty settings: URL URL
No objections. I will create a pull request for review by the WG.
Code change:
Capability and Settings messages are used for two purposes: <del> Capability options advertise the capabilities of the sender to the recipient. </del> <ins> Each capability option advertises one capability of the sender to the recipient. </ins> Setting options indicate a setting that will be applied by the sender.

Related discussion:
text: sig-02 did not define the length for options with uint values. Can you confirm whether 0-4 is correct? I note that there are variants in the RFC7252 options with uint values.
Good catch. 0-4 definitely is right for Max-Message-Size. 0-4 is a bit over the top for Hold-Off, but arbitrarily limiting the time at, say, 65535 seconds (0-2) or 16777215 seconds (0-3) doesn't sound right either -- well, maybe half a year max (0-3) is about right. Option numbers are 65535 max, so Bad-CSM-Option needs to be 0-2.
Code change:
send a Certificate message and a CertificateVerify message, even if the "known_configuration" extension was used for this handshake, thus requiring a signature over the configuration before it can be used by <del> the client. </del> <ins> the client.  Clients MUST not rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate, CertificateVerify, and Finished.  If there is a failure in processing those messages, the client MUST discard the ServerConfiguration. </ins> 6.3.8.

Related discussion:
text: LGTM
Hubert Karlo writes: And how does the client know that the algorithms came from the server. We should have a "client MUST wait for the full handshake to finish before recording this information" or we will have a very nice cipher downgrade. Just having it signed is likely not a good idea, as they may depend on ciphersuites advertised by client.
Since the ServerConfiguration and the suites are covered by the signature the server provides, isn't it safe to use the configuration add soon as you have verified the server identity?
n.b., I have no problem with mandating that clients wait for finished, because it is immediately after the signature, but I wasn't the properties to be clear.
Code change:
for a certificate using a Link relation header field with relation "ct-sct". <del> A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA allows a certificate to be renewed, then it publishes renewed versions of the certificate through the same certificate URI. Clients retrieve renewed versions of the certificate using a GET query to the certificate URI, which the server should then return in a 200 (OK) response.  The server SHOULD provide a stable URI for each specific certificate in the Content-Location header field, as shown above.  Requests to stable certificate URIs MUST always result in the same certificate. To avoid unnecessary renewals, the CA may choose not to issue a renewed certificate until it receives such a request (if it even allows renewal at all).  In such cases, if the CA requires some time to generate the new certificate, the CA MUST return a 202 (Accepted) response, with a Retry-After header field that indicates when the new certificate will be available.  The CA MAY include the current (non- renewed) certificate as the body of the response. Likewise, in order to prevent unnecessary renewal due to queries by parties other than the account key holder, certificate URIs should be structured as capability URLs W3C.WD-capability-urls-20140218. From the client's perspective, there is no difference between a certificate URI that allows renewal and one that does not.  If the client wishes to obtain a renewed certificate, and a GET request to the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. </del> <ins> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new-certificate transaction to request one. Because certificate resources are immutable once issuance is complete, the server MAY enable the caching of the resource by adding Expires and Cache-Control headers specifying a point in time in the distant future.  These headers have no relation to the certificate's period of validity. </ins> 6.6.

Related discussion:
text: For discussion.
See also: URL
I proposed on the mailing list to remove implicit renewal some time ago, and it received some support. Creating this issue to track it. All discussion should be done on the mailing list.
Code change:
receiving a TLS ClientHello.  The server MAY retain these packets for later decryption in anticipation of receiving a ClientHello. <ins> A client generally receives 1-RTT keys at the same time as the handshake completes.  Even if it has 1-RTT secrets, a client MUST NOT process incoming 1-RTT protected packets before the TLS handshake is complete. </ins> 5.8. Retry packets (see the Retry Packet section of QUIC-TRANSPORT) carry

Related discussion:
text: This was never explicit for the client as it is usually not possible. in a way that perhaps was not anticipated.
is complete. Consequently, a server might expect 0-RTT packets to start with a However, this is not necessarily strictly true, because you might have the ACKs in 0.5RTT. Now you might say that the TLS stack reports the handshake as complete as soon as it receives Finished but that's an implementation detail
I think that this is true. The server can send before then, but we require that the client not install 1-RTT keys until it considers the handshake complete.
That's not entirely true. It's the server that needs to hold back keys (namely, the 1-RTT read key) until the handshake completes. The client can use keys as soon as they become available.
I think NAME is correct in sense that the following three events happen at the same moment on the client side: handshake is declared complete TLS stack provides the 1-RTT read and write keys TLS stack provides ClientFinished
Martin is correct. There are two different forms of handshake completion: complete when 1rtt can be sent and received, confirmed when the peer is known to be complete. The client cannot receive 0rtt acks before installing 1rtt keys, hence before hanshake is complete.
a nit, but LGTM
Code change:
The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client <del> MUST be prepared to process "message/dns" (as described in dnswire) responses but MAY also process any other type it receives. </del> <ins> MUST be prepared to process "application/dns-message" (as described in dnswire) responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media <del> formats that include DNS ID, such as message/dns, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as message/ dns.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </del> <ins> formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.

Related discussion:
text: Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.
Code change:
datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. <ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). </ins> 8. 8.1.

Related discussion:
text: This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams.
Code change:
datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. <ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). </ins> 8. 8.1.

Related discussion:
text: On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.
Code change:
datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. <ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). </ins> 8. 8.1.

Related discussion:
text: NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose.
Code change:
datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. <ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). </ins> 8. 8.1.

Related discussion:
text: The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks