jiebi/CodeConvo huggingface dataset:
Code change:
6.20. <del> A publisher sends a SUBSCRIBE_NAMESPACE_OK control message for </del> <ins> A publisher sends a SUBSCRIBE_ANNOUNCES_OK control message for </ins> successful namespace subscriptions. Track Namespace Prefix: As defined in message-subscribe-ns. 6.21. <del> A publisher sends a SUBSCRIBE_NAMESPACE_ERROR control message in response to a failed SUBSCRIBE_NAMESPACE. </del> <ins> A publisher sends a SUBSCRIBE_ANNOUNCES_ERROR control message in response to a failed SUBSCRIBE_ANNOUNCES. </ins> Track Namespace Prefix: As defined in message-subscribe-ns.

Related discussion:
text: On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.
Code change:
The encoder determines how to fragment the encoded bitstream into objects (media). <del> Objects are assigned an intended delivery order that should be obeyed during congestion (delivery-order) </del> <ins> Objects are assigned an intended send order that should be obeyed during congestion (send-order) </ins> The decoder receives each objects and skips any objects that do not arrive in time (decoder).

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.
Code change:
distinguishes it from the Name Length field, which cannot contain a value of 0. <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </del> Indeterminate-length messages can be truncated in a similar way as known-length messages; see padding.

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:
<del> The Tunnel-Protocol HTTP Header Field </del> <ins> The ALPN HTTP Header Field </ins> draft-ietf-httpbis-tunnel-protocol-latest Abstract This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the <del> Tunnel-Protocol header field. </del> <ins> ALPN header field. </ins> Editorial Note (To be removed by RFC Editor)

Related discussion:
text: Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.
Code change:
The representation-data-digest of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof <del> of integrity "at rest" unless the whole (e.g. encoded) payload data is persisted. </del> <ins> of integrity "at rest" unless the whole (e.g. encoded) content is persisted. </ins> 12.9.

Related discussion:
text: Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".
Code change:
representation concepts, several examples are provided in resource- representation. <del> When a message has no "representation data" it is still possible to assert that no "representation data" was sent by computing the digest </del> <ins> When a message has no representation data it is still possible to assert that no representation data was sent by computing the digest </ins> on an empty string (see usage-in-signatures). "Repr-Digest" is a "Dictionary" (see STRUCTURED-FIELDS) where each:

Related discussion:
text: Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that
Code change:
Issuer about a Subject of the Verifiable Credential.  Verifiable Credentials are issued to Holders which can present Verifiable Credentials to Verifiers typically in form of Verifiable <del> Presentations which are secure Verifiable Credentials addressed to a </del> <ins> Presentations which secure Verifiable Credentials addressed to a </ins> specific audience. These relationships are described by the three-party-model which

Related discussion:
text: Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.
Code change:
the data elements processed by the core components are based on the CBOR Signing and Encryption (COSE) standard specified in RFC9052, which is used to produce Signed Statements about Artifacts and to <del> build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements. </del> <ins> build and maintain an Append-only Log for corresponding Signed Statements. </ins> 1.1.

Related discussion:
text: This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:
Code change:
Packet loss or flow control can delay the send of individual streams. <del> The sender might not support QUIC stream prioritization. </del> <ins> The sender might not support stream prioritization. </ins> TODO: Refer to Congestion Response and Prioritization Section for further details on various proposals.

Related discussion:
text: Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.
Code change:
in 2007 as a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. <ins> The IETF's standard congestion control schemes have been shown to have performance challenges in various environments (e.g., high-speed networks, cellular and WiFi wireless technologies, long distance satellite links) and also for specific traffic workloads (VoIP, gaming, and videoconferencing). </ins> In 2007, TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG).

Related discussion:
text: If merged this
Our abstract starts: "The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks, wireless technologies such as 3GPP and WiFi, long distance satellite links) and also in conflict with the needed, more isochronous, behaviors of VoIP, gaming, and videoconferencing traffic." ... is it just me, or does "inadequate" and "at conflict" seem an odd BCP statement from the IETF itself.
Agreed. How about something closer to: "The IETF's standard congestion control schemes have been shown to have performance challenges in various environments (e.g., high-speed networks, cellular and WiFi wireless technologies, long distance satellite links) and also for interactive traffic workloads (VoIP, gaming, and videoconferencing)." cc: NAME NAME
Code change:
HeaderBlock.  Otherwise, flow control or header compression state can become unsynchronized. <del> The GTFO frame also contains a 32-bit ErrorCodes that contains the reason for ending communication. </del> <ins> The GOAWAY frame also contains a 32-bit ErrorCodes that contains the reason for closing the connection. </ins> <del> Endpoints MAY append opaque data to the payload of any GTFO frame. </del> <ins> Endpoints MAY append opaque data to the payload of any GOAWAY frame. </ins> Additional debug data is intended for diagnostic purposes only and carries no semantic value.  Debug information could contain security- or privacy-sensitive data.  Logged or otherwise persistently stored

Related discussion:
text: This is almost a straight revert of the various GOAWAY -> GTFO changes. It seems like this is the popular move as per the discussion on the httpbis mailing list. Arguments for the revert: GOAWAY is self-descriptive and serves it purpose well. Editorial changes that don't clearly improve the spec should be discouraged so we can reach a stable spec sooner (granted this change doesn't affect the wire at all, but documentation churn counts too). GTFO is crass and doesn't belong in internet standards. GTFO, if it really stands for "General Termination of Future Operations," has a surprising definition and may produce confusion. We should strive for absolute clarity above all else in editorial changes.
Boo! You guys are no fun.
goaway is just as bad as gtfo for the same reasons as the argument against gtfo... just called it disconnectclient or endcommunication if you're going to be a grumplestiltskin.
QUENCH may be a better, more descriptive word that has been used before in RFC's (for TCP Source Quench messages)
I think we should call it BIKESHED. , Sean McElroy EMAIL:
Here we go.. useless HN circle jerk.
:cat2:
How about STFU?
Boo!
:-1:
This commit should be reverted. It's time we stop behaving like oversensitive automatons and display the beautiful human quality that is a sense of humor every once in a while.
^ this
^ that
how about something like PLZSTOP? it's slightly humorous, but it actually reflects what is wanted (if I understood the spec correctly)
GOAWAY is clearer for non-native English speakers, easier to pronounce, and more professionally appropriate than the common connotational definition of GTFO. There are times and places for pushing the boundaries of professional speech, but the HTTP2 spec isn't one of them.
At least the pendulum didn't swing the other way NICETALKINGTOYOU
This revert is for the express purpose of stopping endless bikeshedding. We shouldn't encourage trivial changes to frame names. If the name is good enough, it should stay. I'm all for fun and games, but clarity and concision (as well as spec stability) come first.
Code change:
HeaderBlock.  Otherwise, flow control or header compression state can become unsynchronized. <del> The GTFO frame also contains a 32-bit ErrorCodes that contains the reason for ending communication. </del> <ins> The GOAWAY frame also contains a 32-bit ErrorCodes that contains the reason for closing the connection. </ins> <del> Endpoints MAY append opaque data to the payload of any GTFO frame. </del> <ins> Endpoints MAY append opaque data to the payload of any GOAWAY frame. </ins> Additional debug data is intended for diagnostic purposes only and carries no semantic value.  Debug information could contain security- or privacy-sensitive data.  Logged or otherwise persistently stored

Related discussion:
text: For those that prefer GTFO, please explain how it is clearer than GOAWAY (please consider an international audience too).
so mean spirited, this change.
Could always name it SHUTDOWN (yay SCTP) , Adrian Cole EMAIL:
"International audience" here. I'm Armenian, English isn't my native language, not even my 2nd language. GTFO to me is more meaningful and more concise than GOAWAY, or any other option mentioned in the comments. GTFO to me doesn't produce any confusion and its actual definition of "General Termination of Future Operations" is actually nice, smart, and descriptive rather than "surprising" in any negative sense. It also formally de-crasses the word. Of course you can tell me that I'm just a single example, but then again you can tell that to any amount of people. Pretty much the only valid argument out of the posted ones is that GTFO is crass (see I didn't know what "crass" meant before reading this). Everything else about descriptiveness and understandability by "international audience" are in my opinion totally irrelevant and unfair.
NAME thanks for the internationalization datapoint and on-topic discussion! Can you elaborate on how GOAWAY is not clear, and how GTFO is clearer? To me, the main argument is that GTFO is not meaningfully more clear than GOAWAY.
If folks have serious contributions to make, they should be on the mailing list, not here, as per URL Now I get to try out NAME
NAME START
NAME Neither option is appropriate or clear... they're both childish choices and neither are semantically appropriate. I've seen some much better options in this thread. if this change were actually about caring about professionalism, clarity of meaning, or necessity, the innumerable amount of better choices (SHUTDOWN, ENDCONNECTION, QUENCH, etc...) should have been used over GOAWAY or GTFO... But its not.. this is about personal preference. this change made nothing better, it made nothing worse. In my opinion, for that reason, it should be reverted.
FWIW, and for lack of anyone else talking about a pro of GTFO. When at the working group, a lot of thick topics were discussed at length and everyone there seemed 100% dedicated to having the best spec there is.
Code change:
HeaderBlock.  Otherwise, flow control or header compression state can become unsynchronized. <del> The GTFO frame also contains a 32-bit ErrorCodes that contains the reason for ending communication. </del> <ins> The GOAWAY frame also contains a 32-bit ErrorCodes that contains the reason for closing the connection. </ins> <del> Endpoints MAY append opaque data to the payload of any GTFO frame. </del> <ins> Endpoints MAY append opaque data to the payload of any GOAWAY frame. </ins> Additional debug data is intended for diagnostic purposes only and carries no semantic value.  Debug information could contain security- or privacy-sensitive data.  Logged or otherwise persistently stored

Related discussion:
text: GTFO, as a word, is harmless to implementation for reasons including the opcode is the same. IOTW, the binary representation is the same. There's no technical reason why it matters. I am one of the implementors of this specification. When the change was suggested towards GTFO, I felt motivated I mean the audience of this spec are implementors, some of which may be uptight about crassness others less so. If you look at github (ps this is on github) there's ample evidence that implementors are motivated by words that aren't boring. For example, there's a popular package manager called "fpm". Guess what that stands for? I'm not saying go back and re-word everything to be fresh, rather have patience with those who are literally implementing this, in open source, and are ok with the choice. Expect many more implementors to arise from github, a place relatively unburdened by crass-ness or location.
NAME I'll split the answer to 2 sections. AWAY vs. Out -- AWAY implies a certain longish physical distance, whereas Out seems to imply just "out". AWAY vs "General Termination of Future Operations" -- obviously the second is much more clear and descriptive.
GTFO would be my vote. No future operations, full connection termination, it describes the action best.
NAME if you feel strongly, mail on this thread as not everyone there are on github to see your pov URL
NAME - will do, thanks. I need to dig my W3C mailing list info; haven't used it in years. Cheers!
From the W3C mailing list: Thanks, NAME :) Cheers!
All made points aside, I couldn't find a very important one; to me actually being the most important. If you think about what "Get Out!" could also mean (the offensive TF part is actually interchangable...), it becomes even more confusing. An expression of disbelief is surely the very last thing this acronym should imply. But it did to me; even as a non-native speaker (German). "General Termination of Future Operations" is, also in my eyes, a made-up term to fit the joke.
Code change:
HeaderBlock.  Otherwise, flow control or header compression state can become unsynchronized. <del> The GTFO frame also contains a 32-bit ErrorCodes that contains the reason for ending communication. </del> <ins> The GOAWAY frame also contains a 32-bit ErrorCodes that contains the reason for closing the connection. </ins> <del> Endpoints MAY append opaque data to the payload of any GTFO frame. </del> <ins> Endpoints MAY append opaque data to the payload of any GOAWAY frame. </ins> Additional debug data is intended for diagnostic purposes only and carries no semantic value.  Debug information could contain security- or privacy-sensitive data.  Logged or otherwise persistently stored

Related discussion:
text: It is more fitting than GOAWAY, but once you have read GTFO your mind is sort of made up, since you spelled GTFO in full in your head, as soon as reading the acronym. My suggestion on this one is: Simply get rid of "General" / "G" and add "of" to the acronym! TOFO still has a nice ring to it, is quick and easy to pronounce and "Termination Of Future Operations" would be sufficiant descriptive. regards (yes, that's my real lastname :P ) On Jan 29, 2014 8:31 AM, "Eugene Ciurana" EMAIL wrote:
Code change:
present, and applications should not put semantic meaning on the labels themselves.  Instead, additional signature parameters can be used to convey whatever additional meaning is required to be attached <del> to and covered by the signature.  In particular, the "context" parameter can be used to define an application-specific value as described in security-signature-context. </del> <ins> to and covered by the signature.  In particular, the "tag" parameter can be used to define an application-specific value as described in security-signature-tag. </ins> 7.2.6.

Related discussion:
text: Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.
Code change:
The subscriber making the subscribe request is notified of the result of the subscription, via "SUBSCRIBE OK" (message-subscribe-ok) or the <del> "SUBSCRIBE ERROR" message-subscribe-error control message. </del> <ins> "SUBSCRIBE ERROR" message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either an OK or ERROR. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each full track name.  Each new OBJECT belonging to

Related discussion:
text: one question is if they come on different streams can they get out order
My inclination is to send a SubscriptionEnd {} message with appropriate Reason Code set. This will help to support the case that we discussed on publisher wanting to indicate wanting to stop publishing
SUBSCRIPTIONEND and SUBSCRIPTIONEND_ERROR could be split for the graceful vs non-graceful cases.
Discussion in room seems to be rather not have an error after OK but instead use new messages or in subscribe_end message
I'd like to consolidate messages at some point, but we can revisit later.
Code change:
The Device Authorization Grant (RFC8628) is an example of a cross- device flow that relies on the user copying information from the <del> Consumption Device to the Authorization Device.  The figure below shows a typical example of this flow: </del> <ins> Consumption Device to the Authorization Device by either entering data manually or scanning a QR code.  The figure below shows a typical example of this flow: </ins> 2.1.2.

Related discussion:
text: See issue
Closing issue
Add reference to VC presenation specs in section 4 and section 2.2.1
Only adding references to section 4. Adding this in section 2.2.1 will be confusing, even though a QR code is being scanned in these protocols, unlike device code flow, the session does not revert back to the consumption device.
Addressed in PR
Looks good to me, one small editorial change.