RE: GOAWAY -> GTFO

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 21:46:50 UTC