GOAWAY -> GTFO

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GOAWAY -> GTFO

Daniel Sommermann
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?

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Mike Belshe
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 <[hidden email]> 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.

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?


Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

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

Reply | Threaded
Open this post in threaded view
|

RE: GOAWAY -> GTFO

Mike Bishop
In reply to this post by Mike Belshe

“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:[hidden email]]
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 <[hidden email]> 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.

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?

 

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Jesse Wilson
In reply to this post by Daniel Sommermann
OHAI FTW.
Reply | Threaded
Open this post in threaded view
|

RE: GOAWAY -> GTFO

Amos Jeffries-2
In reply to this post by Mike Bishop
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

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Mike Belshe

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



On Mon, Jan 27, 2014 at 1:46 PM, Amos Jeffries <[hidden email]> wrote:
Did anyone complaining actually read the updated text?

"6.8 GTFO

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









 


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


Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Bruce Perens
In reply to this post by Amos Jeffries-2
On the server's decision to end communications with the client, it sends the Frame Utility Closure Key.
Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Amos Jeffries-2
In reply to this post by Mike Belshe
On 2014-01-28 10:52, Mike Belshe wrote:

> My guess is that this is a joke that will be reverted.
>
>
>
> On Mon, Jan 27, 2014 at 1:46 PM, Amos Jeffries wrote:
>
>> Did anyone complaining actually read the updated text?
>>
>> "6.8 GTFO
>>
>> ... 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
>

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

Amos


Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Martin Thomson-3
In reply to this post by Amos Jeffries-2
On 27 January 2014 13:46, Amos Jeffries <[hidden email]> wrote:
>   "A General Termination of Future Operations (GTFO) frame (type=0x7)
> informs the remote peer to stop creating streams on this connection."

Sounds good.

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

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

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

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.

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

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.

>  * 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?

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.

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

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

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Martin Thomson-3
In reply to this post by Bruce Perens
On 27 January 2014 13:54, Bruce Perens <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

RE: GOAWAY -> GTFO

David Morris-4
In reply to this post by Amos Jeffries-2

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:

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

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

David Morris-4
In reply to this post by Mike Belshe

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

On Mon, 27 Jan 2014, Mike Belshe wrote:

> My guess is that this is a joke that will be reverted.
>
>
>
> On Mon, Jan 27, 2014 at 1:46 PM, Amos Jeffries <[hidden email]> wrote:
>
> > Did anyone complaining actually read the updated text?
> >
> > "6.8 GTFO
> >
> > ... 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
>
> > 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
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

David Morris-4
In reply to this post by Martin Thomson-3

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.

On Mon, 27 Jan 2014, Martin Thomson wrote:

> On 27 January 2014 13:54, Bruce Perens <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Amos Jeffries-2
In reply to this post by Martin Thomson-3
On 2014-01-28 11:11, Martin Thomson wrote:

> On 27 January 2014 13:46, Amos Jeffries wrote:
>>   "A General Termination of Future Operations (GTFO) frame (type=0x7)
>> informs the remote peer to stop creating streams on this connection."
>
> Sounds good.
>
>> 2) The "future operations" appears to be redundant behind "terminate".
>> Perhapse it should just be named GENERAL_TERMINATE.
>
> Sounds like a name for a person not a description of a protocol
> feature.
>

:-)

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

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


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

Thank you.

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

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

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Martin Thomson-3
On 27 January 2014 14:56, Amos Jeffries <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Roberto Peon-2

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" <[hidden email]> wrote:
On 27 January 2014 14:56, Amos Jeffries <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Mark Nottingham-2
In reply to this post by David Morris-4
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.



On 28 Jan 2014, at 9:37 am, David Morris <[hidden email]> wrote:

>
> 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.
>
> On Mon, 27 Jan 2014, Martin Thomson wrote:
>
>> On 27 January 2014 13:54, Bruce Perens <[hidden email]> 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

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




Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Glen Knowles
On Mon, Jan 27, 2014 at 5:21 PM, Mark Nottingham <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: GOAWAY -> GTFO

Martin J. Dürst
On 2014/01/28 11:17, Glen Knowles wrote:
> On Mon, Jan 27, 2014 at 5:21 PM, Mark Nottingham<[hidden email]>  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?

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

Regards,   Martin.

12