jiebi/CodeConvo huggingface dataset:
Code change:
A certain software component product is created and packaged by a Supplier.  The package by itself does not include a proof of authenticity.  A signing authority is tasked with adding a proof of <del> authenticity.  Trust has to be established from the Supplier towards the Signing Authority - and vice versa.  The mutual trust relationship (trust bond) between Supplier and Signing Authority is </del> <ins> authenticity.  Trustworthiness has to be established from the Supplier towards the Distributor - and vice versa.  The mutual trustworthiness relationship between Supplier and Distributor is </ins> established per each individual software component package. A consumer of a released software wants: <del> to understand and verify that an actual trust bond exists between the Supplier of a certain software component package and the Signing Authority of that software component package. </del> <ins> to understand and verify that an actual trustworthiness relationship exists between the Supplier of a certain software component package and the Distributor of that software component package. </ins> There is no standardized way to: <del> enable the consumer to verify that a trust bond for a certain software component package exists and is still valid. </del> <ins> enable the consumer to verify that a trustworthiness relationship for a certain software component package exists and is still valid. </ins> 3.2.

Related discussion:
text: Signed-off-by: Henk Birkholz
Henk, The Distributor isn’t always the signing authority. It’s true in some app stores, but beyond that the model breaks, down. Walmart doesn’t digitally sign software it sells/distributes. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Then this is going on the agenda for Monday, too. Thanks Dick
Thanks, Henk. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
From discussion with Henk I believe the use-case here is an app store-like promotion scenario. If that's true, I recommend we refer to this as the relationship between a supplier/producer and the distributor. While signing is a property of the relationship between an app creator and an app store we can increase the clarity of the use-case by describing the roles in the relationship (producer/distributor/consumer). I've made some suggestions on the PR to replace "Signing Authority" with "Distributor".
Code change:
where "d(0)" is the payload.  This algorithm takes no extra data. <del> 4.2. The "QLDB_SHA256" tree algorithm uses the Merkle tree definition from TBD with SHA-256 hash algorithm. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. </del> 5. TBD

Related discussion:
text: and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?
Code change:
7.11. <del> PR 1072: LC feedback from Julian Reschke </del> <ins> PR 1072: LC feedback from Julian Reschke. PR 1080: Improve list style. PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. </ins> 8.  References

Related discussion:
text: This is a simple editorial change of the "changes" section, to add the latest PRs.
Landing as this change is not substantive
Code change:
Set is a proper subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. <ins> The Origin Set is unaffected by any alternative services RFC7838 advertisements made by the server.  Advertising an alternative service does not affect whether a server is authoritative. </ins> 3. This specification adds an entry to the "HTTP/2 Frame Type" registry.

Related discussion:
text: The consequences for ORIGIN + Alt-Svc with a port change aren't awesome, but this should at least remove any confusion.
Are you going to take another go at this?
Sorry, I let this one drop because I missed your suggestion, which is good.
Thanks!
Code change:
when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the <del> updated parameters as soon as possible upon receipt. </del> <ins> updated settings as soon as possible upon receipt. </ins> The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values.  Unsupported <del> parameters MUST be ignored.  Once all values have been processed, the </del> <ins> settings MUST be ignored.  Once all values have been processed, the </ins> recipient MUST immediately emit a SETTINGS frame with the ACK flag set.  Upon receiving a SETTINGS frame with the ACK flag set, the <del> sender of the altered parameters can rely on the setting having been </del> <ins> sender of the altered settings can rely on the value having been </ins> applied. If the sender of a SETTINGS frame does not receive an acknowledgement

Related discussion:
text: In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.
Code change:
Additional type-specific flags for the HEADERS frame are: <del> The CONTINUES bit indicates that this frame does not contain the entire payload necessary to provide a complete set of headers. </del> <ins> The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers. </ins> The payload for a complete set of headers is provided by a <del> sequence of HEADERS frames, terminated by a HEADERS frame without the CONTINUES bit.  Once the sequence terminates, the payload of all HEADERS frames are concatenated and interpreted as a single </del> <ins> sequence of HEADERS frames, terminated by a HEADERS frame with the END_HEADERS flag set.  Once the sequence terminates, the payload of all HEADERS frames are concatenated and interpreted as a single </ins> block. <del> A HEADERS frame that includes a CONTINUES bit MUST be followed by a HEADERS frame for the same stream.  A receiver MUST treat the </del> <ins> A HEADERS frame without the END_HEADERS flag set MUST be followed by a HEADERS frame for the same stream.  A receiver MUST treat the </ins> receipt of any other type of frame or a frame on a different stream as a ConnectionErrorHandler of type PROTOCOL_ERROR.

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.
Code change:
priority for the Object priorities. Object Forwarding Preference: An enumeration indicating how a <del> publisher sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. </del> <ins> publisher sends an object.  The preferences are Track, Peep, and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. Peep ID: The object is a member of the indicated peep ID (model- peep) within the group.  This field is omitted if the Object Forwarding Preference is Track or Datagram. </ins> Object Status: As enumeration used to indicate missing objects or mark the end of a group or track.  See object-status below.

Related discussion:
text: I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments
Code change:
of a header field does not equal the sum of the DATA frame payload lengths <del> that form the content.  A response that is defined to have no content, as described in HTTP, can have a non-zero </del> <ins> that form the content, unless the message is defined as having no content.  For example, 204 or 304 responses contain no content, as does the response to a HEAD request.  A response that is defined to have no content, as described in HTTP, MAY have a non-zero </ins> header field, even though no content is included in DATA frames.

Related discussion:
text: And an update to the section reference. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Code change:
of a header field does not equal the sum of the DATA frame payload lengths <del> that form the content.  A response that is defined to have no content, as described in HTTP, can have a non-zero </del> <ins> that form the content, unless the message is defined as having no content.  For example, 204 or 304 responses contain no content, as does the response to a HEAD request.  A response that is defined to have no content, as described in HTTP, MAY have a non-zero </ins> header field, even though no content is included in DATA frames.

Related discussion:
text: This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.
Code change:
3.5.1. <del> Responses that include information status codes (see HTTP) are </del> <ins> Responses that include informational status codes (see HTTP) are </ins> encoded by repeating the response control data and associated header section until the final status code is encoded.

Related discussion:
text: Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.
Code change:
%x5D-7E. The parameters are included in the content of the HTTP response using <del> the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each parameter at the highest structure level.  Parameter names and string values are included as JSON strings.  Numerical values are included as JSON numbers.  The order of parameters does not matter and can vary. </del> <ins> the "application/json" media type as defined in json-serialization. </ins> For example:

Related discussion:
text: This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM
Code change:
data sent by the receiver, and the media may go through additional steps of transcoding or transformation before being distributed. <del> 3.3.2. </del> <ins> 3.2.2. </ins> Where media is sent onwards to another platform for further distribution and not directly used for presentation to an audience,

Related discussion:
text: NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"?
Code change:
data sent by the receiver, and the media may go through additional steps of transcoding or transformation before being distributed. <del> 3.3.2. </del> <ins> 3.2.2. </ins> Where media is sent onwards to another platform for further distribution and not directly used for presentation to an audience,

Related discussion:
text: In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:
Code change:
"ORIGIN", to allow servers to indicate what origins a connection is usable for. <ins> Additionally, experience has shown that HTTP/2's requirement to establish server authority using both DNS and the server's certificate is onerous.  This specification relaxes the requirement to check DNS when the ORIGIN frame is in use. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: Relax DNS requirements when ORIGIN is received Change the initial origin set to just SNI
wait - no. You wouldn't send the alternative in the ORIGIN frame, you would send the origin that you are the alternative for, right? that would make sense - if you want to use an alternative you can't rely on the SNI default.
this is indeed looking goodminor nitsThis is looking good.
Code change:
octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads. <del> DATA frames MAY also contain arbitrary padding.  Padding can be added to DATA frames to obscure the size of messages. </del> <ins> DATA frames MAY also contain padding.  Padding can be added to DATA frames to obscure the size of messages. </ins> The DATA frame contains the following fields:

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.
Code change:
1.1. <ins> This document uses terminology defined in HTTP. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP

Related discussion:
text: It's customary to put the terminology and BCP 14 block in the same section, but this works.