Subject: GOAWAY -> GTFO

From: Daniel Sommermann <[email-masked]>
Date: Mon, 27 Jan 2014 09:38:15 -0800

I was surprised by this change. I'm not sure exactly how such editorial 
decisions are arrived at, but I didn't see any discussion on this list 
about the change before it was committed on github.

Taking the change at face value:

1) "GTFO" is not English or understandable without context.
2) "GOAWAY" is composed of english words and is self explanatory.
3) This change doesn't fix any problem in the spec. Don't fix what isn't 
broken. In particular, this produces unnecessary churn for implementors, 
documentation updates, etc.

Taking the change as a joking reference to internet culture:

1) "Fuck" doesn't belong in internet standards, implied or otherwise.
2) My protocol cursing at me will get old fast.
3) Clearly SYN_STREAM is a better candidate for renaming and should be 
changed to OHAI, which naturally stands for "Opening Headers And 
Initialization."

Is this just a prank?

---

From: Mike Belshe <[email-masked]>
Date: Mon, 27 Jan 2014 11:18:12 -0800

For what it is worth, I share your disappointment about GTFO, but the
change occurred some time ago (although no discussion on list?).  I see no
advantage of GTFO over GOAWAY.

Mike

---

From: Bruce Perens <[email-masked]>
Date: Mon, 27 Jan 2014 11:24:44 -0800

On 01/27/2014 11:18 AM, Mike Belshe
wrote:

For what it is worth, I share your disappointment
about GTFO, but the change occurred some time ago (although no
discussion on list?).

If I wanted to convince people that the proposal was fabricated by
folks who rarely interact with the world outside of their cubes (and
yes, maybe I do) this would be another datum.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Jan 2014 19:34:16 +0000

"Some time ago"?  I see the commit on January 24, which was only Friday.  I'll join the list of those thinking this is inappropriate.  If someone thinks GOAWAY is also inappropriate, let's *discuss* what options we'd like to consider.

From: Mike Belshe [mailto:[email-masked]]
Sent: Monday, January 27, 2014 11:18 AM
To: Daniel Sommermann
Cc: httpbis mailing list
Subject: Re: GOAWAY -> GTFO

For what it is worth, I share your disappointment about GTFO, but the change occurred some time ago (although no discussion on list?).  I see no advantage of GTFO over GOAWAY.

Mike

On Mon, Jan 27, 2014 at 9:38 AM, Daniel Sommermann <[email-masked]<mailto:[email-masked]>> wrote:
I was surprised by this change. I'm not sure exactly how such editorial decisions are arrived at, but I didn't see any discussion on this list about the change before it was committed on github.

1) "GTFO" is not English or understandable without context.
2) "GOAWAY" is composed of english words and is self explanatory.
3) This change doesn't fix any problem in the spec. Don't fix what isn't broken. In particular, this produces unnecessary churn for implementors, documentation updates, etc.

1) "Fuck" doesn't belong in internet standards, implied or otherwise.
2) My protocol cursing at me will get old fast.
3) Clearly SYN_STREAM is a better candidate for renaming and should be changed to OHAI, which naturally stands for "Opening Headers And Initialization."

Is this just a prank?

---

From: Jesse Wilson <[email-masked]>
Date: Mon, 27 Jan 2014 16:10:23 -0500

OHAI FTW.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 28 Jan 2014 10:46:23 +1300

Did anyone complaining actually read the updated text?

"6.8 GTFO

... General Termination of Future Operations ..."

Anyhow,

NIT:
  The intro wording to that explanation seems to be quite unaligned with 
the intro wording for the other frames and obscures interpretation of 
the acronym. Perhapse the editors should re-write it like so:
   "A General Termination of Future Operations (GTFO) frame (type=0x7) 
informs the remote peer to stop creating streams on this connection."

2) The "future operations" appears to be redundant behind "terminate". 
Perhapse it should just be named GENERAL_TERMINATE.

BUG #1:
  I am noticing a discontinuity in the textual description of the frame:

"the GTFO contains the stream identifier of the last stream which was 
processed on the sending endpoint in this connection. If the receiver of 
the GTFO used streams that are newer than the 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" ...

... "An endpoint MUST treat a GTFO frame with a stream identifier other 
than 0x0 as a connection error ..."

These appear to be mutually exclusive conditions on the use of stream-ID 
for that frame. If implementations follows the MUST condition there is 
nothing graceful about the closure or usefully done with the stream-ID.

BUG #2:
  From a state management perspective it is not clear what the recipient 
of these frames is being informed about. ie what should be done in the 
case where multiple streams are underway when GTFO is sent with a 
stream-ID.

  * Should that be the last/highest completed stream-ID? if so, what 
happens to incomplete streams with numerically lower ID?

  * Should it be the stream-ID before the oldest incomplete stream? if 
so, what happens to all the partially handled and complete streams with 
numerically higher IDs?

  * Should it be the stream-ID of the last frame processed? if so, what 
is it actually telling the remote endpoint?

Going by the text interpretation I would expect the frame to have a 
stream-ID of 0x0 and a *payload* containing a *list* of the stream-IDs 
which are currently being processed (or relayed in the case of 
middleware). Such that the frame is marked as flow control and recipient 
can clearly identify fully which streams must be completed and which can 
be re-tried elsewhere.

Amos

---

From: Mike Belshe <[email-masked]>
Date: Mon, 27 Jan 2014 13:52:46 -0800

My guess is that this is a joke that will be reverted.

> ... General Termination of Future Operations ..."

Amos, you're like the Dad in Modern Family who thinks "WTF" is "Why The
Face?"

But there are no other frame types which are acronyms like this (except for
PING == "Please Indicate Not Gone").

Mike

> the intro wording for the other frames and obscures interpretation of the
> acronym. Perhapse the editors should re-write it like so:
> the GTFO used streams that are newer than the 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" ...
>
>  From a state management perspective it is not clear what the recipient of
> these frames is being informed about. ie what should be done in the case
> where multiple streams are underway when GTFO is sent with a stream-ID.
>
>  * Should it be the stream-ID before the oldest incomplete stream? if so,
> what happens to all the partially handled and complete streams with
> numerically higher IDs?
>
>  * Should it be the stream-ID of the last frame processed? if so, what is
> it actually telling the remote endpoint?
>
> which are currently being processed (or relayed in the case of middleware).
> Such that the frame is marked as flow control and recipient can clearly
> identify fully which streams must be completed and which can be re-tried
> elsewhere.
>
> Amos
>
>

---

From: Bruce Perens <[email-masked]>
Date: Mon, 27 Jan 2014 13:54:56 -0800

On the server's decision to end communications with the client, it
sends the Frame Utility Closure Key.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 28 Jan 2014 11:06:16 +1300

On 2014-01-28 10:52, Mike Belshe wrote:
> On Mon, Jan 27, 2014 at 1:46 PM, Amos Jeffries wrote:
> 

Sigh. Get your mind out of the gutter. That "Whoosh" sound be the 
non-obscene jokes going over your head ;-)

Amos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jan 2014 14:12:10 -0800

On 27 January 2014 13:54, Bruce Perens <[email-masked]> wrote:
> On the server's decision to end communications with the client, it sends the
> Frame Utility Closure Key.

I say this to everyone who wants to make a trivial change that does
not affect protocol function, or improve spec comprehension.

I do not make those sorts of changes without a pull request.  See:
https://github.com/http2/http2-spec

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jan 2014 14:11:29 -0800

> informs the remote peer to stop creating streams on this connection."

Sounds good.

> Perhapse it should just be named GENERAL_TERMINATE.

Sounds like a name for a person not a description of a protocol feature.

> processed on the sending endpoint in this connection. If the receiver of the
> GTFO used streams that are newer than the 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" ...
>
> ... "An endpoint MUST treat a GTFO frame with a stream identifier other than
> 0x0 as a connection error ..."
>
> These appear to be mutually exclusive conditions on the use of stream-ID for
> that frame. If implementations follows the MUST condition there is nothing
> graceful about the closure or usefully done with the stream-ID.

Took me a while to get what you were at here.  There is a stream
identifier in the frame header.  That MUST be 0x0 for GTFO.  That is
separate from the Last-Stream-ID field in the body of the frame, which
can be any value.

>  * Should that be the last/highest completed stream-ID? if so, what happens
> to incomplete streams with numerically lower ID?

This is the highest stream identifier for which work could have been
done.  This includes streams that have completed successfully, streams
that have been partially handled, and even streams that /might/ have
been processed somehow (i.e., if uncertain, you should include it).

If there are lower numbered streams for which work has not been done,
then that's just too bad.

> what happens to all the partially handled and complete streams with

I don't think that's right.

>  * Should it be the stream-ID of the last frame processed?

Yes.

> if so, what is it
> actually telling the remote endpoint?

If I say GTFO(last-stream = X), then you know that the POST request
you put in stream X+2 was not processed and can be tried again.

> stream-ID of 0x0 and a *payload* containing a *list* of the stream-IDs which
> are currently being processed (or relayed in the case of middleware). Such
> that the frame is marked as flow control and recipient can clearly identify
> fully which streams must be completed and which can be re-tried elsewhere.

Including a list is better in a sense, but it also requires more
granular tracking.  It doesn't seem to be that valuable on balance.
(I'll let others disagree with me, of course.)

---

From: David Morris <[email-masked]>
Date: Mon, 27 Jan 2014 14:19:19 -0800 (PST)

That description sounds like it was written to expand an already
chosen acronym ... it is stilted and doesn't seem like it will have
useful mneumonic value. GOAWAY is much clearer.

On Tue, 28 Jan 2014, Amos Jeffries wrote:

>  The intro wording to that explanation seems to be quite unaligned with the
> intro wording for the other frames and obscures interpretation of the acronym.
> Perhapse the editors should re-write it like so:
>   "A General Termination of Future Operations (GTFO) frame (type=0x7) informs
> the remote peer to stop creating streams on this connection."
>
> these frames is being informed about. ie what should be done in the case where
> multiple streams are underway when GTFO is sent with a stream-ID.
>
>  * Should that be the last/highest completed stream-ID? if so, what happens to
> incomplete streams with numerically lower ID?
>
>  * Should it be the stream-ID before the oldest incomplete stream? if so, what
> happens to all the partially handled and complete streams with numerically
> higher IDs?
>
>  * Should it be the stream-ID of the last frame processed? if so, what is it
> Going by the text interpretation I would expect the frame to have a stream-ID
> of 0x0 and a *payload* containing a *list* of the stream-IDs which are
> currently being processed (or relayed in the case of middleware). Such that
> the frame is marked as flow control and recipient can clearly identify fully
> which streams must be completed and which can be re-tried elsewhere.
>
> Amos
>

---

From: David Morris <[email-masked]>
Date: Mon, 27 Jan 2014 14:21:35 -0800 (PST)

But ping as a quasi english word is descriptive of the operation so
the interpretation isn't needed.

---

From: David Morris <[email-masked]>
Date: Mon, 27 Jan 2014 14:37:17 -0800 (PST)

I've searched the list archive and can't find any reference to
GTFO prior to the current dicussion.

I believe it is IETF policy that all decisions need to be validated
on the mailing list.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 28 Jan 2014 11:56:40 +1300

On 2014-01-28 11:11, Martin Thomson wrote:
> On 27 January 2014 13:46, Amos Jeffries wrote:

:-)

> separate from the Last-Stream-ID field in the body of the frame, which

Ah, overlooked that. Perhapse some wording

"The last stream identifier (Last-Stream-ID) in the GTFO frame contains 
..."

"The last stream identifier (Last-Stream-ID) in the GTFO frame payload 
contains ..."

>> happens

Thank you.

>> which

Both ends already have that tracking in place. The costs I here would be 
the extra bytes on the GTFO frame and the cycles used to generate that 
list in the sender for which streams it still wants to receive. The 
cycles to process it in recipient would be the same ones for clearing up 
that state anyway.

This may have benefits such as allowing the recipient to change its 
priority algorithm to send frames for shorter outstanding streams, thus 
closing as many streams as possible completely before anything else goes 
wrong. Or in handling as errors any outstanding streams the sender does 
not list instead of the recipient wasting bandwidth sending their 
frames. A list of only one entry (as currently used) meaning the 
connection close is to follow and everything outstanding is borked.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jan 2014 15:10:05 -0800

On 27 January 2014 14:56, Amos Jeffries <[email-masked]> wrote:
> Both ends already have that tracking in place. The costs I here would be the
> extra bytes on the GTFO frame and the cycles used to generate that list in
> the sender for which streams it still wants to receive. The cycles to
> process it in recipient would be the same ones for clearing up that state
> anyway.

Not exactly.  You know what streams you have, but the streams that
have crossed from 'not idle' states into 'no way back from here' isn't
something that necessarily needs tracking.

It's a line call either way.  Multiple stream identifiers is more
complexity all around, and the gain is marginal at best.

> A list of only one entry (as currently used) meaning the connection close is to follow and everything outstanding is borked.

Signaling using a single entry won't work.  You could make the first
item in the list imply that all earlier streams are (or could be)
processed.  That's an easy way to allow people to contain the
complexity.

BTW, if you send GTFO because things are messed up badly enough that
explosions might occur, I don't think you want to keep on keeping on.
In most of the error scenarios, GTFO is followed immediately with a
connection close.  Keeping the connection alive is usually reserved
for graceful shutdown.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 27 Jan 2014 16:26:37 -0800

Keeping a list of streams and their state is something that some proxies
may not do, especially if only involved in load balancing-- keeping the
last seen stream-id is trivial, however.
On Jan 27, 2014 3:12 PM, "Martin Thomson" <[email-masked]> wrote:

> the
> > A list of only one entry (as currently used) meaning the connection
> close is to follow and everything outstanding is borked.
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jan 2014 12:21:31 +1100

I consider this a purely editorial issue, in that it does not appear on the wire, nor does it affect the operation of the protocol. 

The editor does not need to clear every changed word on the list before committing it; that would be ludicrous, and I’m a bit surprised to see you imply that it’s necessary. Once a draft is published, we comment upon it (both for substantial and more trivial issues), and we move on — this has been the working mode of this group now for years.

As Martin said, the editor does take suggestions, especially those in the form of a pull request. I trust he’ll consider all input and we’ll end up in the right place; if not, we’ll discuss it and move on.

Note that this is *not* a call to start an endless rathole on what flavour like people best; group wordsmithing does not work, and we have a lot to do.

Regards,

P.S. I take people’s focus on the colour of the paint here to mean that they consider the rest of the renovation done, so that’s good, I suppose.

--
Mark Nottingham   http://www.mnot.net/

---

From: Glen Knowles <[email-masked]>
Date: Mon, 27 Jan 2014 18:17:27 -0800

On Mon, Jan 27, 2014 at 5:21 PM, Mark Nottingham <[email-masked]> wrote:
>
> P.S. I take people's focus on the colour of the paint here to mean that
> they consider the rest of the renovation done, so that's good, I suppose.
>
>
Or perhaps the color is distractingly ugly?

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 28 Jan 2014 12:15:22 +0900

On 2014/01/28 11:17, Glen Knowles wrote:
> On Mon, Jan 27, 2014 at 5:21 PM, Mark Nottingham<[email-masked]>  wrote:
>>

Very well put. Whatever "official", "sanitized" expansion we put into 
the speck, people who use a search engine will find something different.

Regards,   Martin.

---

From: Simon Yarde <[email-masked]>
Date: Tue, 28 Jan 2014 08:23:30 +0000

How about COMEBACK ?

This seems to make sense with the added context of a stream-id with which to come-back;  i.e. reconnect and resume. And it's rather more fluffy and humanitarian than GTFO.

FWIW, GTFO is like writing OMG WTF on the side of a lunar lander, and is surely not representative of the ideals to which HTTP aspires.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Jan 2014 10:45:41 +0200

> Sounds like a name for a person not a description of a protocol feature.

A bond villain.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Jan 2014 10:26:02 +0100

Hi there.

I appreciate the interesting discussion about the name of a constant in 
the HTTP/2 spec.

However I'd like to remind all of us about our charter which very 
clearly states in <http://tools.ietf.org/wg/httpbis/charters>

  "The Working Group will give priority to HTTP/1.1 work until that work 
is complete."

Right now the HTTP/1.1 specs are past IESG evaluation, with a lot of 
COMMENTs and a few DISCUSSes being resolved.

It would be awesome if we could get a few participants to review what 
has changed since -25; see either the trac timeline 
<http://trac.tools.ietf.org/wg/httpbis/trac/timeline>, the issues list 
(<http://trac.tools.ietf.org/wg/httpbis/trac/query?status=assigned&status=closed&status=new&status=reopened&milestone=26&col=id&col=summary&col=milestone&col=status&col=owner&col=type&col=priority&order=priority>), 
or the diff documents:

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest-from-previous.diff.html>

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest-from-previous.diff.html

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-latest-from-previous.diff.html>

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-latest-from-previous.diff.html>

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-latest-from-previous.diff.html>

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest-from-previous.diff.html>

Best regards, Julian

---

From: Daniel Sommermann <[email-masked]>
Date: Tue, 28 Jan 2014 09:51:01 -0800

I've made a pull request to revert the change since the popular opinion 
on this thread has been against the rename and I haven't heard any 
arguments defending the choice of GTFO.

https://github.com/http2/http2-spec/pull/366

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Jan 2014 09:53:16 -0800

> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest-from-previous.diff.html>

p1 looks good.  A couple of places could be quibbled, but the intent
was always clear, so it's not worth spending time correcting it.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 28 Jan 2014 15:06:15 -0500

Julian,

+1 on the content in the diffs.

On Jan 28, 2014, at 4:26 AM, Julian Reschke <[email-masked]> wrote:

> Hi there.
> 
> I appreciate the interesting discussion about the name of a constant in the HTTP/2 spec.
> 
> However I'd like to remind all of us about our charter which very clearly states in <http://tools.ietf.org/wg/httpbis/charters>
> 
> "The Working Group will give priority to HTTP/1.1 work until that work is complete."
> 
> Right now the HTTP/1.1 specs are past IESG evaluation, with a lot of COMMENTs and a few DISCUSSes being resolved.
> 
> It would be awesome if we could get a few participants to review what has changed since -25; see either the trac timeline <http://trac.tools.ietf.org/wg/httpbis/trac/timeline>, the issues list (<http://trac.tools.ietf.org/wg/httpbis/trac/query?status=assigned&status=closed&status=new&status=reopened&milestone=26&col=id&col=summary&col=milestone&col=status&col=owner&col=type&col=priority&order=priority>), or the diff documents:
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Adrian Cole <[email-masked]>
Date: Tue, 28 Jan 2014 13:22:34 -0800

FWIW, when GTFO was suggested last week at the working group, all people
present had an opportunity to dissent and I heard not a single dissent
voiced!

That said, I wouldn't conflate above PR/commit as a "popular move" as who
knows.. GOAWAY might actually lose a popular vote vs GTFO!

That said, silencing the argument is likely a popular move, so maybe the
description still fits.

sigh

On Tue, Jan 28, 2014 at 9:51 AM, Daniel Sommermann <[email-masked]> wrote:

> I've made a pull request to revert the change since the popular opinion on
> this thread has been against the rename and I haven't heard any arguments
> defending the choice of GTFO.
>

---

From: Adrian Cole <[email-masked]>
Date: Tue, 28 Jan 2014 14:06:14 -0800

Reposting my github comment here.

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

On Tue, Jan 28, 2014 at 1:22 PM, Adrian Cole <[email-masked]>wrote:

> On Tue, Jan 28, 2014 at 9:51 AM, Daniel Sommermann <[email-masked]>wrote:
>

---

From: Zhong Yu <[email-masked]>
Date: Tue, 28 Jan 2014 17:02:48 -0600

Some implementers are not familiar with English slangs; schools don't
teach this stuff. GTFO will be a hard-to-remember acronym to them.

On Tue, Jan 28, 2014 at 4:06 PM, Adrian Cole <[email-masked]> wrote:
> suggested towards GTFO, I felt motivated I mean the audience of this spec
> implementors are motivated by words that aren't boring. For example, there's
> a popular package manager called "fpm". Guess what that stands for?
>
> 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.
>
>
>
>
>
>>> on this thread has been against the rename and I haven't heard any arguments

---

From: Phil Hunt <[email-masked]>
Date: Tue, 28 Jan 2014 15:08:33 -0800

It is offensive and should not be used. Intent does not solve the issue. 

Phil

> On Jan 28, 2014, at 15:02, Zhong Yu <[email-masked]> wrote:
>