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: 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.