jiebi/CodeConvo huggingface dataset:
Code change:
Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level <del> TCP connection, the terminating endpoint SHOULD first send a GTFO so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </del> <ins> TCP connection, the terminating endpoint SHOULD first send a (GOAWAY) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 9.2.

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:
Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level <del> TCP connection, the terminating endpoint SHOULD first send a GTFO so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </del> <ins> TCP connection, the terminating endpoint SHOULD first send a (GOAWAY) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 9.2.

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:
Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level <del> TCP connection, the terminating endpoint SHOULD first send a GTFO so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </del> <ins> TCP connection, the terminating endpoint SHOULD first send a (GOAWAY) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 9.2.

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:
Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level <del> TCP connection, the terminating endpoint SHOULD first send a GTFO so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </del> <ins> TCP connection, the terminating endpoint SHOULD first send a (GOAWAY) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 9.2.

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:
4.2. <del> The current interop version is 3. </del> <ins> The current interop version is 4. </ins> Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version

Related discussion:
text: Since the last draft version was published, we replaced the header with the header. This requires an increase in the interop version as existing clients will need changes to be compatible with the next draft release.
Code change:
5.6.3. <ins> Like header fields, trailer fields with the same name are processed in the order received; multiple trailer field lines with the same name have the equivalent semantics as appending the multiple values as a list of members, even when the field lines are received in separate trailer sections.  Trailer fields that might be generated more than once during a message MUST be defined as a list value even if each member value is only processed once per field line received. Trailer fields are expected (but not required) to be processed one trailer section at a time.  That is, for each trailer section received, a recipient that is looking for trailer fields will parse the received section into fields, invoke any associated processing for those fields at that point in the message processing, and then append those fields to the set of trailer fields received for the overall message. This behavior allows for iterative processing of trailer fields that contain incremental signatures or mid-stream status information, and fields that might refer to each other's values within the same section.  However, there is no guarantee that trailer sections won't shift in relation to the message body stream, or won't be recombined (or dropped) in transit, so trailer fields that refer to data outside the present trailer section need to use self-descriptive references (i.e., refer to the data by name, ordinal position, or an octet range) rather than assume it is the data most recently received. Likewise, at the end of a message, a recipient MAY treat the entire set of received trailer fields as one data structure to be considered as the message concludes.  Additional processing expectations, if any, can be defined within the field specification for a field intended for use in trailers. 5.6.4. </ins> The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated

Related discussion:
text: H1-H3 currently define a way to carry only one such block, but an extension could provide more.
Code change:
start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one optimistically used for the early data.  Any requests sent in early <del> data MUST be sent again, unless the client decides to abandon those requests. </del> <ins> data will need to be sent again, unless the client decides to abandon those requests. </ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the

Related discussion:
text: Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!
Code change:
current congestion control algorithms do have security implications (e.g., as outlined in RFC5681). <del> The IETF process that results in publication needs to ensure that these security implications are considered.  Proposed congestion control algorithms therefore ought to be mindful of pitfalls, and SHOULD examine any potential security issues that may arise. </del> <ins> Proposed congestion control algorithms MUST examine any potential security or privacy issues that may arise from their design. </ins> 9.

Related discussion:
text: A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!
Code change:
Error Code: Identifies an integer error code for subscription failure. <del> Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. </del> <ins> Reason Phrase: Provides the reason for subscription error. </ins> Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track.

Related discussion:
text: When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR
Code change:
can be distinguished from a valid <del> by examining the first two characters for a DQUOTE. </del> <ins> by examining the first three characters for a DQUOTE. </ins> If the validator given in the If-Range header field matches the current validator for the selected representation of the target

Related discussion:
text: (this text is present in RFC 7233 as well) "A valid entity-tag can be distinguished from a valid HTTP-date by examining the first two characters for a DQUOTE." Hm, no. If we want to properly handle weak etags, we either need to inspect three characters (actually position 0 and 2) for DQUOTE, or check pos 0 for DQUOTE or pos 1 for "/". If we're not interested in weak etags, checking the first character is sufficient.
Code change:
content, or poison a cache.  See security.considerations for security considerations regarding message routing. <ins> The status code in a response indicates that the origin server has rejected the request because it appears to have been misdirected (status.421). </ins> 7.5. A connection might be used for multiple request/response exchanges.

Related discussion:
text: I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.
Code change:
content, or poison a cache.  See security.considerations for security considerations regarding message routing. <ins> The status code in a response indicates that the origin server has rejected the request because it appears to have been misdirected (status.421). </ins> 7.5. A connection might be used for multiple request/response exchanges.

Related discussion:
text: This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
Code change:
5.2. The authorization server determines whether the information provided <del> up to this point is sufficient to issue an authorization code, and responds with an authorization code or an error message. </del> <ins> up to this point is sufficient to issue an authorization code, and if so responds with an authorization code.  If the information is not sufficient for issuing an authorization code, then the authorization server MUST respond with an error response. </ins> 5.2.1.

Related discussion:
text: Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types
Code change:
MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim <del> independently from other salts. </del> <ins> independently from other salts.  See Randomness Requirements for Security RFC4086 for considerations on generating random values. </ins> 11.4.

Related discussion:
text: for
"The security considerations about salt entropy should probably reference RFC 4086 (BCP 106) or something more up to date (maybe RFC 8937 too)." resulting from this thread URL / URL Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden wrote: Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want. verification and processing rules (this one specifically ). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft. A more sophisticated version of this “attack” illustrates the need for prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use. And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: URL signature algorithm would probably be worthwhile. Furthermore, preimage resistance is not a sufficient property to ensure section-11.5 along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”. We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? Or could we just replace “preimage resistant” with “irreversible” in that text in 11.5?