jiebi/CodeConvo huggingface dataset:
Code change:
or response header field if the host part of that URI differs from the <del> host part in the effective request URI (effective.request.uri).  This helps prevent denial-of-service attacks. </del> <ins> host part in the target URI (target.resource).  This helps prevent denial-of-service attacks. </ins> <del> A cache MUST invalidate the effective request URI (effective.request.uri) when it receives a non-error response to a request with a method whose safety is unknown. </del> <ins> A cache MUST invalidate the target URI (target.resource) when it receives a non-error response to a request with a method whose safety is unknown. </ins> Here, a "non-error response" is one with a or <del> status code.  "Invalidate" means that the cache will either remove all stored responses related to the effective request URI or will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated.  For example, a state-changing request might invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it has not. </del> <ins> status code. </ins> 5.

Related discussion:
text: NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.
Code change:
subscribe-req. Expires: Time in milliseconds after which the subscription is no <del> longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed. </del> <ins> longer valid.  A value of 0 indicates that the subscription does not expire or expires at an unknown time.  Expires is advisory and a subscription can end prior to the expiry time or last longer. </ins> ContentExists: 1 if an object has been published on this track, 0 if not.  If 0, then the Largest Group ID and Largest Object ID

Related discussion:
text: Note from call. Fixe subscribeDone at same time. Define a new bool type. p[ick new leatter other than b
Also make sure to fix SUBSCRIBE_DONE at the same time.
NAME - I updated, have another read and see if it looks OK. Thanks
and introduced a field to SUBSCRIBEOK, SUBSCRIBEFIN, and SUBSCRIBE_RESET. If I read the notation correctly, it has a size of 1 bit, which makes it hard to parse the rest of the message. Could we encode that information in the message type by using two types per message instead of a 1-bit field?
I think the intent is that it is one byte not one bit.
Maybe it should have been:
or just a byte field with only 2 possible values allowed (1) and (0) ..
I agree we need to keep this byte aligned however we do it.
IMO just make it a VarInt (or byte), with only values of 0 and 1 currently valid. This encoding is temporary until we nail down all of the fields/flags so we shouldn't be making life difficult or efficient.
Individual Comment: Even if it's temporary, my preference is for a one-bit field and unused/reserved bits to align, because there are no error conditions.
Have a look at PR
Code change:
subscribe-req. Expires: Time in milliseconds after which the subscription is no <del> longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed. </del> <ins> longer valid.  A value of 0 indicates that the subscription does not expire or expires at an unknown time.  Expires is advisory and a subscription can end prior to the expiry time or last longer. </ins> ContentExists: 1 if an object has been published on this track, 0 if not.  If 0, then the Largest Group ID and Largest Object ID

Related discussion:
text: And add a new SUBSCRIBE_DONE status code. Fixes part of , but it's still unclear how one might refresh a subscription without interruption.
Subscriptions always end with either SUBSCRIBEFIN or SUBSCRIBERESET, except when they Expire and then no control message is sent. This complicates the state machine and adds another case to handle. The subscriber needs to start a timer or something similar to know when the subscription will end, and it doesn't get to know the final group or object ID.
I'd like to get rid of , but my thought was that it's a signal to SUBSCRIBE again before the timeout to avoid interruption. Otherwise, there would be a SUBSCRIBE_RESET with an "expired" error code containing the final group/object.
I agree that a subscriber can deal with this field, but I don't know what purpose it serves for the publisher/relay? It's different from an idle connection timeout, because assuming there is data flowing for the subscription, it would never go idle. Unlike QUIC, I don't see value in having a 'silent close' for subscriptions, because typically we expect subscriptions to have data flowing at a somewhat regular interval. Also, there's no guarantee that the subscription will last until the expiry time, it can always end early with SUBSCRIBEFIN or SUBSCRIBERESET.
Based on last week's conversation, the Expires field doesn't change the state of the subscription by itself, a publisher would still have to send a FIN or RESET to close it. It's still unclear as to what a subscriber should do with it. There was a fair amount of discussion around refreshing one's authorization. It's unclear if that would be done with a SUBSCRIBE_UPDATE or something similar or via UNSUBSCRIBE/SUBSCRIBE?
Would the solution to this be when the relay expires a subscription, it sends a control message ? This might all become clearer once we figure out re authentication but at a high level, I want some way that the relays can clean up state on a time line that is under relay control particularly when poorly implemented clients make subscriptions.
I think this was resolved by -
LGTM
Code change:
server-scheduling, and connect-scheduling. Where HTTP extensions change stream behavior or define new data <del> carriage mechanisms, they MAY also define how this priority scheme </del> <ins> carriage mechanisms, they can also define how this priority scheme </ins> can be applied. 4.

Related discussion:
text: Thank you for the fix.
FWIW, I would prefer s/MAY/can/ - there is no normative effect of a choice. Originally posted by NAME in URL
Code change:
failed and not process the uploaded data further.  This way, the integrity of the entire uploaded data can be protected. <ins> Alternatively, when creating an upload (upload-creation), the client MAY ask the server to compute and return the integrity digests using a "Want-Repr-Digest" field conveying the preferred algorithms.  The response SHOULD include at least one of the requested digests, but MAY not include it.  The server SHOULD compute the representation digests using the preferred algorithms once the upload is complete and include the corresponding "Repr-Digest" header field in the response.  Alternatively, the server MAY compute the digest continuously during the upload and include the "Repr-Digest" header field in responses to upload creation (upload-creation) and upload appending requests (upload-appending) even when the upload is not completed yet.  This allows the client to simultaneously compute the digest of the transmitted upload data, compare its digest to the server's digest, and spot data integrity issues.  If an upload is spread across multiple requests, data integrity issues can be found even before the upload is fully completed. 15.2. Content digests help verify the integrity of the content in an individual request. </ins> If the client knows the integrity digest of the content from an upload creation (upload-creation) or upload appending (upload- appending) request, it MAY include the "Content-Digest" header field

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
new connection to one or more alternative services immediately, or simultaneously with subsequent requests on the same connection. <del> To reduce the ability of servers to track individual clients over time (see tracking), an alternative service indication sent by a client include any alternative service information other than the protocol, host and port. </del> When using HTTP/2 (HTTP2), clients instead send an ALTSVC frame.  A single ALTSVC frame can be sent for

Related discussion:
text: Mark moved this note in his edits, but I think that we don't need it any more at all. The security considerations will suffice.
Code change:
The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in <del> domain A (https://as.a.org/auth) to receive an authorization grant </del> <ins> domain A (https://as.a.org/auth) to receive a JWT authorization grant </ins> for the authorization server in trust domain B (https://as.b.org/ auth). 2.5. <del> The client presents the token it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </del> <ins> The client presents the JWT authorization grant it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </ins> 2.5.1.

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
15.5.20. <ins> The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI.  A 421 is sent when an origin server (or gateway acting on behalf of the origin server) rejects a target URI that does not match an for which the server has been configured (origin) or does not match the connection context over which the request was received (routing.reject). A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection, such as a fresh connection specific to the target resource's origin, or via an alternative service RFC7838. A proxy MUST NOT generate a 421 response. 15.5.21. </ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a

Related discussion:
text: This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
Code change:
equipped to authenticate the channel between the two devices. Mitigations should focus on: <del> To achieve the above outcomes, mitigating the exploits of cross- device flows require a three-pronged approach: </del> <ins> To achieve the above outcomes, mitigating against Cross-Device Consent Phishing attacks require a three-pronged approach: </ins> 5.1. A number of protocols that enable cross-device flows that are <del> susceptible to illicit consent grant attacks are already deployed. The security profile of these protocols can be improved through practical mitigations that provide defense in depth that either: </del> <ins> susceptible to Cross-Device Consent Phishing attacks are already deployed.  The security profile of these protocols can be improved through practical mitigations that provide defense in depth that either: </ins> It is recommended that one or more of the mitigations are applied whenever implementing a cross-device flow.  Every mitigation provides an additional layer of security that makes it harder to initiate the <del> attack, disrupts attacks when in process or reduces the impact of a </del> <ins> attack, disrupts attacks in progress or reduces the impact of a </ins> successful attack. 5.1.1.

Related discussion:
text: Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!
Code change:
client sends it's first flight data.  When such transport (e.g., TLS 1.3 I-D.ietf-tls-tls13 in full-handshake mode) is used, a client can postpone sending the CACHE_DIGEST frame until it receives a <del> ACCEPT_CACHE_DIGEST settings value. </del> <ins> SETTINGS_ACCEPT_CACHE_DIGEST settings value. </ins> When the underlying transport does not have such property (e.g., TLS 1.3 in 0-RTT mode), a client can reuse the settings value found in

Related discussion:
text: Aligns with other SETTINGS parameter names defined in other docs.
NAME icymi
Thank you for the fix!
Code change:
inclusion proof which increases the size of multiple payload signed inclusion proofs. <ins> Tree algorithm designers are encouraged to comment on this property of their leaf construction algorithm. </ins> 6. <del> TBD </del> <ins> See the privacy considerations section of: </ins> 6.1.

Related discussion:
text: These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now
Code change:
A stub network that services a Wi-Fi stub network SHOULD provide DNS64 translation: hosts on the stub network cannot be assumed to be able to do DNS64 synthesis in the stub resolver.  In this case the <del> DNS resolver on the stub router MUST honor the CD and DO bits if received in a request, since this indicates that the stub resolver on the requestor intends to do DNSSEC validation.  In this case, the resolver on the stub router MUST NOT perform DNS64 synthesis. </del> <ins> DNS resolver on the stub router MUST honor the 'CD' and 'DO' flag bits if received in a request, since this indicates that the stub resolver on the requestor intends to do DNSSEC validation.  In this case, the resolver on the stub router MUST NOT perform DNS64 synthesis. </ins> On specific stub networks it may be desirable to require the stub network device to perform DNS64 synthesis.  Stub network routers for

Related discussion:
text: Flag bits can be referred to as "bit", "flag", or "flag bit". This issue is an editorial reminder to update to a consistent term later on. E.g. "flag" or "flag bit" is most clear I think.
Assigning to myself, to make a PR later on. Everyone and NAME feel free to suggest preferred term. I find "flag bit" the most clear.
Code change:
2.1.6. <del> The "hashes" value of the Use-As-Dictionary header is a inner-list value that provides a list of supported hash algorithms in order of server preference. The dictionaries are identified by the hash of their contents and this value allows for negotiation of the algorithm to use. The "hashes" value is optional and defaults to (sha-256). 2.1.7. 2.1.7.1. </del> <ins> 2.1.6.1. </ins> A response that contained a response header: Would specify matching any document request for a URL with a path <del> prefix of /product/ on the same Origin as the original request, </del> <ins> prefix of /product/ on the same Origin as the original request, and </ins> expiring as a dictionary in 7 days independent of the cache lifetime <del> of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del> <ins> of the resource. </ins> <del> 2.1.7.2. </del> <ins> 2.1.6.2. </ins> A response that contained a response header: <del> Would match main.js in any directory under /app/, expiring as a dictionary in one year and support using the sha-256 hash algorithm. </del> <ins> Would match main.js in any directory under /app/ and expiring as a dictionary in one year. </ins> 2.2.

Related discussion:
text: This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).
Code change:
suspension of a driving license or checking the employment status of an employee credential. <del> This behaviour could be mitigated by: - adding authorization rules to the Status List, see security-authorization.  - regular re-issuance of the Referenced Token, see implementation-lifecycle. </del> <ins> This behaviour could be mitigated by: adding authorization rules to the Status List, see security- authorization. regular re-issuance of the Referenced Token, see implementation- lifecycle. </ins> 12.4.

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types
Code change:
the TLS layer.  TLS only permits a server to accept all early data, or none of it.  Once a server has decided to accept early data, it MUST process all requests in early data, even if the server rejects <del> the request by sending a 4NN (Too Early) response. </del> <ins> the request by sending a 425 (Too Early) response. </ins> A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary

Related discussion:
text: There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.
Code change:
obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary

Related discussion:
text: It occurs to me that if we specify to always be used in conjunction with , and that its semantics are that caches that understand the semantics of the status code can ignore the , all current implementations should already be conferment (if not optimal). Currently, I'm not aware of any cache that implements (because it's new).
Code change:
3. <del> Client Attestation JWT A JSON Web Token (JWT) generated by the client backend which is bound to a key managed by a client instance which can then be used by the instance for client authentication. Client Attestation Proof of Possession (PoP) JWT A Proof of Possession generated by the client instance using the key that the Client Attestation JWT is bound to. Client Instance Key A cryptographic, asymmetric key generated by the client instance and proven to the client backend.  The public key is contained in the Client Attestation JWT and is used to sign the Client Attestation Proof of Possession. </del> 4. To perform client authentication using this scheme, the client

Related discussion:
text: In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL
Code change:
coding. Crypto-Key header field values with multiple instances of the same <del> parameter name are invalid. </del> <ins> parameter name in a single crypto-key-params production are invalid. </ins> The input keying material used by the key derivation (see derivation) can be determined based on the information in the Crypto-Key header

Related discussion:
text: This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.