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