jiebi/CodeConvo huggingface dataset:
Code change:
whether a session has bi-direction flows of media from senders and receivers, and the expected lowest latency requirements using the definitions <del> specified in I-D.draft-ietf-mops-streaming-opcons. </del> <ins> specified in term. </ins> It is likely that we should add other characteristics, as we come to understand them.

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:
whether a session has bi-direction flows of media from senders and receivers, and the expected lowest latency requirements using the definitions <del> specified in I-D.draft-ietf-mops-streaming-opcons. </del> <ins> specified in term. </ins> It is likely that we should add other characteristics, as we come to understand them.

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:
recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.6. </del> <ins> 7.7. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource

Related discussion:
text: "The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."
Code change:
Clients configured to use a proxy MUST ignore any ORIGIN frames received from it. <del> 2. </del> <ins> 3. </ins> Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of attacks; hence the reinforcement that

Related discussion:
text: Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.
Code change:
RFC7230. The definitions "representation", "selected representation", <del> "representation data", "representation metadata" and "payload body" </del> <ins> "representation data", "representation metadata", and "payload body" </ins> in this document are to be interpreted as described in RFC7230 and RFC7231. <ins> The definition "validator" in this document is to be interpreted as described in Section 7.2 of RFC7231. </ins> 2. To avoid inconsistencies, an integrity mechanism for HTTP messages

Related discussion:
text: to use the new "validator" name. See: URL URL
NAME I'm quite weak on that side: is this PR correct? If not feel free to fix at will :)
NAME I agree... this comes from the original RFC 3230. Merging the change as a simple terminology update. The relation b/w validators and the resource is discussed in , where I tagged you as your guidance will be great. See too.
to clarify the following passage for defining the behavior of digest with caching (eg. when Digest is returned together with Last-Modified and ETag). and to better extend the definition of Digest to POST and PATCH requests. This is because though only when they include explicit freshness information. If we go on the new http-core definition (which is cleaner) we have that eg. According to URL POST responses identify returned resources in different ways according to the following: the primary resource is identified by Content-Location the enclosed representation matches the primary resource eg. 1 eg. 2 primary resource identified by enclosed representation matches the status of the request according to the resource's own semantic eg.
re-reading the old RFC my understanding is that validator fields should just be aligned with Digest (that is: digest-value should be aligned with the values of last-modified and etag). While it is trivial, the original editor could have considered that a potential issue.
The change itself looks right. I wonder however about the whole paragraph: what does it mean to say "resource is specified"? Doesn't that also need request header fields upon which the returned representation varies?
Code change:
RFC7230. The definitions "representation", "selected representation", <del> "representation data", "representation metadata" and "payload body" </del> <ins> "representation data", "representation metadata", and "payload body" </ins> in this document are to be interpreted as described in RFC7230 and RFC7231. <ins> The definition "validator" in this document is to be interpreted as described in Section 7.2 of RFC7231. </ins> 2. To avoid inconsistencies, an integrity mechanism for HTTP messages

Related discussion:
text: Replaces the old with from URL The relations of Last-Modified and ETag with Digest are examined in
Code change:
1.2. <del> The concept of "selected representation" defined in Section 6 of I- D.ietf-httpbis-semantics makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with I-D.ietf-httpbis- semantics concepts. </del> <ins> The concept of "selected representation" defined in Section 6 of SEMANTICS makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with SEMANTICS concepts. </ins> Basing "Digest" on the selected representation makes it straightforward to apply it to use-cases where the transferred data does require some sort of manipulation to be considered a representation, or conveys a partial representation of a resource eg. <del> Range Requests (see Section 8.3 of I-D.ietf-httpbis-semantics). </del> <ins> Range Requests (see Section 8.3 of SEMANTICS). </ins> Changes are semantically compatible with existing implementations and better cover both the request and response cases.

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document. <ins> With post-handshake authentication there is also the possibility, though unlikely in practice, of multiple certificates and certificate chains from the client on a connection, in which case only the certificate and chain of the last post-handshake authentication are to be utilized for the header fields described herein. </ins> 2.

Related discussion:
text: try to say that for multiple post-handshake client certificate authentications, only use the last one (to
TLS 1.3 post-handshake authentication enables the use of multiple client authentications. The draft probably needs to address this. Firstly, the proxy could be smart enough to know which certificate applies. After all, it needs to know how and when to ask for a certificate. If it is that smart, we don't have a problem. If not, then... For , this is easy. If there are multiple certificates and the reverse proxy doesn't know which to include, it can include all of them. It's easy enough to add extra values. For this is less easy. There would be no way to distinguish which intermediate related to which end-entity certificate if you just added them all. I don't think that's fatal though. Chain building for validation always has to deal with certificates that don't do anything, so maybe we can just dump them all in there and let the back-end server sort them out. In terms of actions, we can say something like:
The draft currently , which precludes multiple values/instances. I am very reluctant to change that in support of something that rarely if ever happens in practice (it would mean HTTP/1.1 with multiple TLS 1.3 post-handshake authentications or post-handshake authentication(s) after a client cert authenticated handshake). Could we instead just say the first/last one is used? Then it's predictable/defined should it ever happen. Or declare it out of scope. Existing related text from URL is copied here: >HTTP/2 restricts TLS 1.2 renegotiation ( of ]) and prohibits TLS 1.3 post-handshake authentication ]. However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 ] where the server decides whether to request a client certificate based on the HTTP request. HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document.
I could live with picking the last in the absence of information that might allow for another to be selected. But what harm is there in using a list?
Makes it all more complicated b/c everything then needs to treat it as a list and reason about it being a list.
Code change:
application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document. <ins> With post-handshake authentication there is also the possibility, though unlikely in practice, of multiple certificates and certificate chains from the client on a connection, in which case only the certificate and chain of the last post-handshake authentication are to be utilized for the header fields described herein. </ins> 2.

Related discussion:
text: The value in typing something as what it is seems self-evident so I'm at a bit of a lose as to how else to answer that question.
WFM.
Code change:
Specification Document: Section txn-token-header of this specificaiton <del> 10.2. </del> <ins> 11.2. </ins> Claim Name: "azd"

Related discussion:
text: Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"
Code change:
Claim Issuer, as an integer, for example "-35" for ECDSA with SHA- 384, see COSE Algorithms registry [2]; <del> Issuer (label: "TBD", to be registered): DID (Decentralized </del> <ins> Issuer (label: "TBD", temporary: "391"): DID (Decentralized </ins> Identifier, see W3C Candidate Recommendation [3]) of the signer, as a string, for example "did:web:example.com"; <del> Feed (label: "TBD"): the Issuer's name for the Artifact, as a string; </del> <ins> Feed (label: "TBD", temporary: "392"): the Issuer's name for the Artifact, as a string; </ins> payload type (label: "3"): Media type of payload as a string, for example "application/spdx+json" <del> Registration policy info (label: "TBD"): a map of additional attributes to help enforce Registration policies; </del> <ins> Registration policy info (label: "TBD", temporary: "393"): a map of additional attributes to help enforce Registration policies; </ins> <del> DID key selection hint (label: "TBD"): a DID method-specific selector for the signing key, as a bytestring. </del> <ins> Key ID (label: "4"): Key ID, as a bytestring. </ins> Additionally, Claims MAY carry the following unprotected headers: <del> Receipts (label: "TBD", to be registered): Array of Receipts, </del> <ins> Receipts (label: "TBD", temporary: "394"): Array of Receipts, </ins> defined in In CDDL RFC8610 notation, the Envelope is defined as follows:

Related discussion:
text: This adds temporary integer header parameter labels to have something to prototype against until the new fields are registered. I used 391 as starting offset as that's S+C+I+T+T.
Code change:
5. Our proposal is that "Media Over QUIC" discussions focus first on the <del> use cases for Live Media Contribution (lmcont), Syndication (lmsynd), and Streaming (lmstream).  Our reasoning is provided in usecaseanalysis. </del> <ins> use cases described in lm-media, which are Live Media Ingest (lmingest), Syndication (lmsynd), and Streaming (lmstream).  Our reasoning is provided in usecaseanalysis. </ins> 5.1. Each of the above use cases in overallusecases fit into one of three classifications of solutions. <del> The first group, covering gaming (gaming), screen sharing (remdesk), and general video conferencing (vidconf), are largely covered by WebRTC and related protocols today.  Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the WebRTC protocol and specifications.  Such work could start in a QUIC specific forum, but would likely need to take place in rtcweb and the W3C. The second group of classifications, covering Live Media Contribution (lmcont), Syndication (lmsynd), and Streaming (lmstream) are likely the use cases likely to benefit most from this work.  Existing protocols used such as HLS RFC8216 and DASH DASH are reaching limits towards how low they can reduce latency in live streaming and for scenarios where low-bitrate audio streams are used add a significant amount of overheads compared to the media bitstream. On-Demand media streaming (odstream) is unlikely to benefit from work in this space.  Without notable latency requirements, protocols such as HLS and DASH largely meet the needs of this use case. </del> <ins> The first group, in interact, covering gaming (gaming), screen sharing (remdesk), and general video conferencing (vidconf), are largely covered by WebRTC and related protocols today.  Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the WebRTC protocol and specifications.  Such work could start in a QUIC specific forum, but would likely need to take place in rtcweb and the W3C. The second group of classifications, in lm-media, covering Live Media Ingest (lmingest), Live Media Syndication (lmsynd), and Live Media Streaming (lmstream) are likely the use cases likely to benefit most from this work.  Existing protocols used such as HLS RFC8216 and DASH DASH are reaching limits towards how low they can reduce latency in live streaming and for scenarios where low-bitrate audio streams are used add a significant amount of overheads compared to the media bitstream. The third group, od-media, covering On-Demand Media Ingest (od- ingest) and On-Demand Media streaming (od-stream) is unlikely to benefit from work in this space.  Without notable latency requirements, protocols such as HLS and DASH largely meet the needs of this use case. </ins> 6.

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
Omitting content by truncating a message is only possible if the content is zero-length. <ins> 3.8. Messages can be padded with any number of zero-valued bytes.  Non- zero padding bytes cause a message to be invalid (see invalid). Unlike other parts of a message, a processor MAY decide not to validate the value of padding bytes. Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as zero-length part, which is semantically equivalent to the part being absent. </ins> 4. This document describes a number of ways that a message can be

Related discussion:
text: This adds the ability to pad messages to the binary HTTP format. The design is pretty simple: add zero-valued bytes to the end.
What if someone adds a non-zero byte in the padding block?
Code change:
Recommended HTTP status code: 500 <del> 3.35. </del> <ins> 3.34. </ins> Name: proxy_loop_detected

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
The following is a non-normative example of a decoded SD-JWT header: <del> 4.1.2. VC-SD-JWTs and VP-SD-JWTs can use any claim registered in the "JSON Web Token Claims" registry as defined in RFC7519. Some of the claims in a VC MUST NOT be selectively disclosed as they are always required for processing on the verifier side.  All other claims can be made selectively disclosable by the issuer when issuing the respective VC-SD-JWT. </del> <ins> 4.2.2. </ins> <del> VC-SD-JWTs and VP-SD-JWTs MAY contain additional registered or public claims depending on the application. </del> <ins> This section defines the claims that can be included in the payload of SD-JWTs and Diclosures belonging to VC-SD-JWTs. </ins> <del> 4.1.2.1. </del> <ins> 4.2.2.1. </ins> This specification defines the JWT claim

Related discussion:
text: I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
Code change:
Given a float as input_float: <del> If input_float is not a IEEE 754 double precision number, fail serialisation. </del> <ins> If input_float's fractional part has more than six digits of precision, fail serialisation. If the number of digits of precision in input_float's fractional part plus those in its integer part add to more than fifteen digits, fail serialisation. </ins> Let output be an empty string.

Related discussion:
text: Is this PR meant to include ?
Yeah, oops. Need more coffee.
Try now.
Otherwise, looks alright to me.
The current definition of sh-float is surprisingly hard to serialize correctly, the best C-code I could come up with is: int serializeshfloat(char buf[18], double d) { int p = 0, l, dig; buf[0] = ''; buf[1] = '\0'; if (isnan(d)) return (-1); if (fabs(d) >= 99999999999999.95) return (-1); if (d = 99999999999999.95) return (-1); if (d < 0) { buf[p++] = '-'; d = -d; } p += snprintf(buf + p, 18 - p, "%-16f", d); while (buf[p-1] == ' ') p -= 1; buf[p] = '\0'; return (p); }
+1 from me, our primary focus should be on data types that will have good interop. That level of precision isn't necessary for any current use of HTTP headers I'm aware of, off the top of my head.
Proposal: Call these decimal. Allow a maximum of 9 digits on the left of the decimal place and 6 after. This matches the definition for int and allows storing this in the same sized slot with a or conversion factor.
ABNF gets much simpler.
NAME That would probably curtail the range too much. I think it is desirable to be able to move posix time_t timestamps in these.
If this really is an integer with fixed point semantics, why do we need it at all?
Because it's easier than making people specify "divide the number by a million to get its real value"? That said, I agree that 9 digits to the left of the point is probably not enough, so a floating point representation is more useful. This is the ABNF equivalent of NAME C code, yeah?: That easily gets us a current 32-bit time_t plus microseconds, and a whole range of other values besides.
Why do the arguments about size of integers not also apply here? is 64-bit on my system, which doesn't fit in the sh-integer definition either.
The current time is ish. You don't need to prefix it with 30 bits worth of zeroes.