RE: GOAWAY -> GTFO

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
>

Received on Monday, 27 January 2014 22:21:23 UTC