Re: GOAWAY -> GTFO

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 <squid3@treenet.co.nz> 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
> >
> >
>

Received on Monday, 27 January 2014 22:22:07 UTC