Re: Design Issue: Merge RST_STREAM and GOAWAY into a single ERROR frame type

I've found the current way to work well too.

otoh if there was a use case for rationale 3 (non-terminal session errors)
that seems like the one place where the new proposal is actually more
expressive. nothing comes to mind though.


On Fri, May 3, 2013 at 5:25 PM, Roberto Peon <grmocg@gmail.com> wrote:

> I also find the current way more obvious-- in wireshark and similar
> traces, it is far easier to pick out the different opcode type (which is
> typically rendered as the textual name of the opcode) as opposed to the
> numeric value in some field.
>
> -=R
>
>
> On Fri, May 3, 2013 at 2:12 PM, William Chan (陈智昌) <willchan@chromium.org>wrote:
>
>> Sorry, my implication is that I don't see any objective determination of
>> what's simpler here, just subjective views of which many people can have an
>> opinion. But if there's consensus on doing this, then by all means, let's
>> do it. I for one disagree and find the current way simpler :)
>>
>>
>> On Fri, May 3, 2013 at 6:08 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>>> There is no bikeshedding going on at all. I made the motivation for
>>> this clear up front: it's a simplification that addresses three
>>> specific items. Note: there is an existing editorial note in the
>>> existing draft that calls out the fact that we have no non-terminal
>>> method of communicating non-stream related errors. If we can address
>>> that item while also simplifying things a bit, then fantastic.
>>>
>>> On Fri, May 3, 2013 at 2:01 PM, William Chan (陈智昌)
>>> <willchan@chromium.org> wrote:
>>> > This is a thread ripe for bikeshedding. Is there any major issue worth
>>> > solving?
>>> >
>>> > If we're going to paint our bike sheds, my take is keep whatever color
>>> the
>>> > bike shed already has unless it really offends a number of people.
>>> >
>>> >
>>> > On Fri, May 3, 2013 at 5:53 PM, James M Snell <jasnell@gmail.com>
>>> wrote:
>>> >>
>>> >> Speaking candidly, if we find ourselves requiring more than 8 boolean
>>> >> flags on an error frame we should all just quit and go home.
>>> >>
>>> >> On Fri, May 3, 2013 at 1:34 PM, Jeff Pinner <jpinner@twitter.com>
>>> wrote:
>>> >> > IIRC, when this was brought up at the last F2F the rational for NOT
>>> >> > doing
>>> >> > this was that frame types were cheaper than flags (256 frame types,
>>> 8
>>> >> > flags).
>>> >> >
>>> >> > That being said I think we should consider combining them :)
>>> >> >
>>> >> >
>>> >> > On Fri, May 3, 2013 at 1:04 PM, James M Snell <jasnell@gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> As a simplification, I'd like to suggest that we merge the
>>> RST_STREAM
>>> >> >> and GOAWAY frames into a single ERROR frame with the following
>>> >> >> definition:
>>> >> >>
>>> >> >>  0                   1                   2                   3
>>> >> >>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> >> >> |                      Error Code (32)                          |
>>> >> >> +---------------------------------------------------------------+
>>> >> >> |X|                  Last-Stream-ID (31)                        |
>>> >> >> +-+-------------------------------------------------------------+
>>> >> >>
>>> >> >> (note that this flips the field order from the GOAWAY frame)
>>> >> >>
>>> >> >> A frame-specific GOAWAY flag bit (0x2) would be defined for the
>>> frame,
>>> >> >> and the Last-Stream-ID field would only be included in the frame
>>> data
>>> >> >> if this flag was set.
>>> >> >>
>>> >> >> This does a couple of things for us:
>>> >> >>
>>> >> >> 1. It simplifies the error handling and reduces the number of core
>>> >> >> frame
>>> >> >> types.
>>> >> >> 2. It allows us to terminate a stream and terminate the session in
>>> a
>>> >> >> single frame if necessary
>>> >> >> 3. It gives us a way of reporting non-terminal session errors
>>> >> >> (currently RST_STREAM is forbidden to use stream id #0 and GOAWAY
>>> is
>>> >> >> always terminal).
>>> >> >>
>>> >> >
>>> >>
>>> >
>>>
>>
>>
>