Code change:
6.8. <del> A General Termination of Future Operations (GTFO) frame (type=0x7) informs the remote peer to stop creating streams on this connection. GTFO can be sent by either client or server.  Once sent, the sender will ignore frames sent on new streams for the remainder of the connection.  Receivers of a GTFO frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams.  The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams (perhaps for a reboot or maintenance), while still finishing processing of previously established streams. </del> <ins> The GOAWAY frame (type=0x7) informs the remote peer to stop creating streams on this connection.  It can be sent from the client or the server.  Once sent, the sender will ignore frames sent on new streams for the remainder of the connection.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams.  The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams (perhaps for a reboot or maintenance), while still finishing processing of previously established streams. </ins> There is an inherent race condition between an endpoint starting new <del> streams and the remote sending a GTFO frame.  To deal with this case, the GTFO frame contains the stream identifier of the last stream </del> <ins> streams and the remote sending a GOAWAY frame.  To deal with this case, the GOAWAY contains the stream identifier of the last stream </ins> which was processed on the sending endpoint in this connection.  If <del> the receiver of the GTFO frame used streams that are newer than the </del> <ins> the receiver of the GOAWAY used streams that are newer than the </ins> indicated stream identifier, they were not processed by the sender and the receiver may treat the streams as though they had never been created at all (hence the receiver may want to re-create the streams later on a new connection). <del> Endpoints SHOULD always send a GTFO frame before closing a connection so that the remote can know whether a stream has been partially processed or not.  For example, if an HTTP client sends a POST at the same time that a server closes a connection, the client cannot know if the server started to process that POST request if the server does not send a GTFO frame to indicate where it stopped working.  An endpoint might choose to close a connection without sending GTFO for misbehaving peers. </del> <ins> Endpoints SHOULD always send a GOAWAY frame before closing a connection so that the remote can know whether a stream has been partially processed or not.  For example, if an HTTP client sends a POST at the same time that a server closes a connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate where it stopped working.  An endpoint might choose to close a connection without sending GOAWAY for misbehaving peers. </ins> <del> After sending a GTFO frame, the sender can discard frames for new </del> <ins> After sending a GOAWAY frame, the sender can discard frames for new </ins> streams.  However, any frames that alter connection state cannot be completely ignored.  For instance,

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.