Re: GOAWAY -> GTFO

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