jiebi/CodeConvo huggingface dataset:
Code change:
A list of error codes is included in ErrorCodes. <ins> It is possible that an endpoint will encounter frames that would cause multiple errors.  Implementations MAY discover multiple errors during processing, but they SHOULD report at most one stream and one connection error as a result. The first stream error reported for a given stream prevents any other errors on that stream from being reported.  In comparison, the protocol permits multiple GOAWAY frames, though an endpoint SHOULD report just one type of connection error unless an error is encountered during graceful shutdown.  If this occurs, an endpoint MAY send an additional GOAWAY frame with the new error code, in addition to any prior GOAWAY that contained NO_ERROR. If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection error, that error MUST be reported. </ins> 5.4.1. A connection error is any error that prevents further processing of

Related discussion:
text: Is it okay to leave as an implementation detail, even if most implementations will do the "logical thing"? Also this was just one example of a frame with multiple errors... others may not be so straightforward.
The question we should ask is: Is there any behavior that would change that would cause it to not interoperate here? I suspect that, regardless of how one interprets this, processing must stop, and the client may or may not receive an error, thanks to the vagaries of packet-loss. If this requires any clarification, I'd pick the path of asserting that any connection error stops any other processing.
Actually I also found error handling quite tricky to do, especially regarding when and what to send in GOAWAY frames. One really needs to think in terms of error severity to implement a form of funnel so that more severe errors can still be emitted after less serious ones. One example that quickly comes to mind is that we can send a GOAWAY frame to indicate a graceful shutdown of a connection yet this one is not an error and may be followed by other GOAWAY reporting protocol violations. I also faced an annoying situation related to TCP where you can't send a GOAWAY frame due to a buffer full situation, and closing after this causes a reset to be emitted due to pending incoming data. So we actually have to enter an input drain state in error situations, which further adds to the implementation complexity.
QUIC has that I think h2 would benefit from.
See for some proposed text to address this. We probably need to workshop it a bit.
Thanks!
Code change:
can be more complex as well. <del> The Release is sent together with the SD-JWT from the holder to the </del> <ins> The SD-JWT-R is sent together with the SD-JWT from the holder to the </ins> verifier. 3.3.

Related discussion:
text: addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR
Code change:
. Pushed responses that are cacheable (see RFC7234) can be stored by <del> the client, if it implements a HTTP cache.  Pushed responses are </del> <ins> the client, if it implements an HTTP cache.  Pushed responses are </ins> considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive RFC7234 is present) while the stream identified by the promised stream ID is still open.

Related discussion:
text: I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.
Code change:
4.1. When using this specification in HTTP/2 or HTTP/3, clients MAY start <del> sending TCP stream content without waiting for an HTTP response. Proxies MUST buffer this "false start" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "false start" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as 407 (Proxy Authentication Required).) </del> <ins> sending TCP stream content optimistically, subject to flow control limits (RFC9113)(RFC9000).  Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "optimistic" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as "407 (Proxy Authentication Required)".) </ins> Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send <del> "connect-tcp" requests in early data, and MAY include "false start" content in early data (in HTTP/2 and HTTP/3).  Proxies MAY accept, reject, or delay processing of this early data.  For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </del> <ins> "connect-tcp" requests in early data, and MAY include "optimistic" TCP content in early data (in HTTP/2 and HTTP/3).  At the TLS layer, proxies MAY ignore, reject, or accept the "early_data" extension (RFC8446).  At the HTTP layer, proxies MAY process the request immediately, return a "425 (Too Early)" response (RFC8470), or delay some or all processing of the request until the handshake completes. For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </ins> 4.2.

Related discussion:
text: Within TLS 1.3, the only options for 0-RTT are "accept" or "reject". "accept but delay until after the handshake" is not visible within the TLS 1.3 protocol. The current draft language doesn't align nicely with this, and should be adjusted. Credit: NAME
Code change:
used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field <del> STRUCTURED-FIELDS sf-dictionary SHA-256 hash of the contents of the dictionary that was used to encode the response. </del> <ins> STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of the dictionary that was used to encode the response. </ins> If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available

Related discussion:
text: Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."
Code change:
4.2. *Senders/Receivers*: One to One *Bi-directional*: Yes *Latency*: <del> Significantly less than "Ultra-Low" </del> <ins> Ull100 </ins> Where media is received, and user inputs are sent by the client. This may also include the client receiving other types of signalling,

Related discussion:
text: NAME - Please let me know if this seems about right. One thing that's worth mentioning to you and to NAME - the latency characterizations that we wrote did not make use of the new "ultra-ultra-low latency" categories. I changed the one for gaming to ull100 ("ultra-low-latency under 100 ms") based on conversations at IETF 112, but other people would be better choices to review the characterizations of the use cases they're most interested in.
The opcons drafts uses 4 bands: ultra low-latency (less than 1 second) low-latency live (less than 10 seconds) non-low-latency live (10 seconds to a few minutes) on-demand (hours or more) I think these bands lose some granularity that is useful. For example, a functional video call or interactive game probably needs much less than 1s latency, while low latency live may span lower than 1s in some cases?
NAME - that's very true. The opcons draft was scoped for "streaming operators", and although we've talked (in MOPS) about doing a separate draft for low-latency streaming, we haven't done that yet (in MOPS). That may be for the best, if MOQ turns out to be "not ABR, less than 500 ms", or something like that. I'm also one of the opcons drafts, so I'm thinking we should add at least one, and probably two, lower-than-ultra-low(!!!) latency bands, and explain why we're doing that. I'm assigning this to me, so expect a PR soon.
The industry is terrible at naming things. "ultra-low", "low", "non-low", I mean really? It's all terrible marketing rather than an attempt to classify protocols. I like that the opcons tries to reuse and simplify the terminology but... latency is a complicated. Some protocols have artificial delays, but for the most part, protocols are defined by their ability to deal with congestion. A protocol like RTMP will be "ultra low-latency" within a datacenter or for a user with a perfect network connection, while it will be "low-latency" for somebody on a cellular connection, while it will be "non-low-latency" for somebody going through a tunnel... all of which depends on the implementation.
Code change:
4.2. *Senders/Receivers*: One to One *Bi-directional*: Yes *Latency*: <del> Significantly less than "Ultra-Low" </del> <ins> Ull100 </ins> Where media is received, and user inputs are sent by the client. This may also include the client receiving other types of signalling,

Related discussion:
text: At the end of the day, these lines in the sand don't add to the discussion. I would rather focus on the use-cases like "having a conversation with someone" rather than arguing over millisecond budgets.
Code change:
indicating available-values that are acceptable to the client, in order of preference, greatest to least. <del> Return result of running Find Available Keys (find) on sorted- </del> <ins> Return result of running Compute Possible Keys (find) on sorted- </ins> variants, an empty string and an empty list. This returns a list of strings suitable for comparing to normalised

Related discussion:
text: For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)
Code change:
2. <del> Recall the definition of CoMeTre inclusion proofs, which are parametrized by 3 CBOR data types that are specific to the Tree Algorithm: This document defines the "CCF-leaf" and "CCF-inclusion-proof" CBOR types.  The signed Merkle Root data type "smtr" is the same as in I- D.steele-cose-merkle-tree-proofs but MUST set the protected header parameter carrying the identifier of the tree algorithm, "tree_alg", to the value TBD_1. </del> <ins> This documents extends the verifiable data structure registry of I- D.steele-cose-merkle-tree-proofs with the following value: </ins> 2.1. <del> The input of the Merkle Tree Hash (MTH) function is a list of n bytestrings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE bytestring, also called the tree root hash. </del> <ins> The input of the Merkle Tree Hash (MTH) function is a list of n byte strings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE byte string, also called the Merkle root hash. </ins> This function is defined as follows:

Related discussion:
text: This uses the new proof type registry and redefines the signature type. Unlike the CT-style log algorithm the proof type is part of the trusted headers
Code change:
with the registration procedure of status.code.registry and the status code values summarized in the following table. <del> Additionally, please update the following entry in the Hypertext Transfer Protocol (HTTP) Status Code Registry: </del> 18.4. This specification updates the HTTP related aspects of the existing

Related discussion:
text: by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.
Code change:
The PUSH_PROMISE frame defines the following flags: PUSH_PROMISE frames MUST be associated with an existing, peer- <del> initiated stream.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> initiated stream.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </ins> .

Related discussion:
text: I realize this is somewhat redundant given section 5.1.1, so I don't mind if this pull is rejected. The main reason I think this might be useful is since there are two different stream identifiers involved in PUSHPROMISE: the promised stream id and the stream identifier in the common header. The extra sentence just makes it explicit how PUSHPROMISE is linked to an earlier request. It also puts the following sentence in better context.
Code change:
"keyid": The identifier for the key material as a String value. <ins> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify signatures relevant for specific applications or protocols. </ins> Additional parameters can be defined in the iana-param-contents. Note that there is no general ordering to the parameters, but once an ordering is chosen for a given set of parameters, it cannot be

Related discussion:
text: Adds an optional parameter to signatures, to allow applications to signal specific usage between the signer and verifier. This PR does not add this to any examples yet, but we probably should if accepted.
NAME NAME I've walked the language in the definition back a bit and added it to an example. I think this is sufficient to include as a new feature.
[This came up at the IETF-113 session, credit to Jonathan Hoyland] A signature context mitigates oracle attacks, where a sender can be made to sign data that’s partly controlled by the attacker, and the signed string is then used for unexpected purposes, either within the same protocol or outside it. The context includes the higher level protocol that utilizes the signature mechanism, as well as other information such as sender and receiver identities. Signature context is used in TLS 1.3 (see RFC 8446, Sec. 4.4.3, “context string”) as well as the similar parameter in . The simplest way to add context to Message Signatures is as an additional parameter. We suggest that the context value should NOT be defined by this draft, but it should be mandatory to send, and mandatory to validate upon receipt. This prevents cross-protocol attacks but assumes that the higher level protocol is able to protect itself e.g. by ensuring that the receiver’s identity is included in the signed components. The context is fully defined by the higher level protocol, and no IANA registry is established for it. cc: NAME
Thanks for writing this up. I want to make sure I understand the request for addition: Define a signature parameter "context" as a string, whose content is outside the scope of this spec Define the use for this field aligned with the above Add a security considerations on the use of this in outside protocols I think this is a relatively light weight add, and I am ok with those pieces. Where I don't think I agree is the "mandatory to send and interpret" portion, if we're not going to define anything to put into the field. In this case is becomes just another value, right? I can see a lot of confusion in people trying to apply this without clear guidance. I would be fine with this field being recommended to send by the signer and mandatory to interpret by the verifier if it's present, and applications can make the field required and even have required values, like the example above.
Code change:
"keyid": The identifier for the key material as a String value. <ins> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify signatures relevant for specific applications or protocols. </ins> Additional parameters can be defined in the iana-param-contents. Note that there is no general ordering to the parameters, but once an ordering is chosen for a given set of parameters, it cannot be

Related discussion:
text: Yes, you have it right. This is analogous to the JWT claim whose goal is to prevent cross-protocol (or really, cross-usage) attacks. So making this mandatory is important. I think mandating verification is nice in theory but I'm not sure it would be effective in practice. Instead, we could give guidance that makes it trivial to use, like in my example: include the protocol's name and possibly version. Just doing that would narrow the "blast radius" of cross-protocol attacks significantly. A "nonce" () is a well defined term. This is not a nonce. The on is weaker than I would like, but it's still a SHOULD for new types of JWTs. Here we have an opportunity to get it right from day one.
I appreciate the position, but what if the application is literally just "I am signing this message"? What would we put in that mandatory field that isn't either a random value or just "http"?
Then put the application/service name there, instead of a protocol name.
What's the application or service name, then? I don't think it's always as well defined as you're assuming it to be in practice.
It's guidance, not interoperable normative text. Whether people use "myapp" or "myapp/1" or even "myfile.c" doesn't matter all that much. Basically anything is better than a missing context.
If it's not interoperable normative text, then it has no business being a MUST here.
Existence and verification of the parameter are both normative. Its content is not.
NAME Could you provide an example attack scenario that cannot be mitigated by signing additional semantically relevant message components, and is mitigated by the addition of a parameter? The JWT claim is necessary because often there is nothing in a JWT that ties it to a particular message. This is a feature of JWTs, as it allows things like reusing JWT-formatted access tokens across multiple requests. I'm not familiar enough with TLS internals to say whether the same concept applies to the TLS "context string" parameter. In contrast, reuse across messages is not a use case for HTTP Message Signatures. If a signature is reusable across two semantically different messages, that would suggest to me that the signature is not covering the right message components.
Code change:
"keyid": The identifier for the key material as a String value. <ins> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify signatures relevant for specific applications or protocols. </ins> Additional parameters can be defined in the iana-param-contents. Note that there is no general ordering to the parameters, but once an ordering is chosen for a given set of parameters, it cannot be

Related discussion:
text: So cross-protocol attacks where the signature is presented as a message signature for a different message are mitigated by signing the semantically relevant components. (e.g., , or parts thereof, etc.) Attacks where the signature is presented as some other type of signature (i.e., not an HTTP message signature) are partially mitigated by the fact that the signature base includes the signature parameters, which is likely to distinguish it from content that may be signed in other contexts. For example, the format of the signature base means that an HTTP message signature cannot be passed off as a signature for a JWS. If the overall format and the footer is not already enough for this, I don't see how adding an additional parameter would help. If an attacker can mold the signature input in another context to match the HTTP message signature format as it is, it seems unlikely to me that adding to the end would help.
Hi NAME I'll start with your last paragraph. I agree what we have now is only partial mitigation. This kind of attacks is never fully mitigated, because you need to make assumptions on what implementations of a different, unknown protocol would do. But in general IMHO a unique prefix is a much better way to distinguish between signatures, because something further down in the signature base may be ignored by verifiers. Concretely, having a mandatory as the first line of the signature base would be a much better mitigation. Now back to the : again, we are talking about two different protocols, each of which may have both spec and implementation errors. Of course if both protocols are defined and implemented perfectly, the right fields would be covered and validated, and would also define unique semantics. Life is not perfect - people are lazy and will sign too few fields - and a context protects some protocols/implementations from others.
I'm not sure I buy this. If a non-HTTPSig consumer of signed content can be tricked into accepting as a valid message then I don't see why we should assume it would be any harder to get it to accept Okay, can we walk through the failure modes? An API that exposes multiple operations on different paths could fail to require callers to sign the target URI's path. In order for to help, it would have to be set to a unique value per operation, e.g., "ExampleApp.doExampleThing".