W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Alissa Cooper's Yes on draft-ietf-httpbis-http2-16: (with COMMENT)

From: Greg Wilkins <gregw@intalio.com>
Date: Fri, 23 Jan 2015 18:20:51 +0100
Message-ID: <CAH_y2NEZChvS1-qnwYYRPByDiUGhn1s6N3Ch8GJviYp2PUzguA@mail.gmail.com>
To: Nicholas Hurley <hurley@todesschaf.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 23 January 2015 at 17:33, Nicholas Hurley <hurley@todesschaf.org> wrote:

> Well, yes, you're right there, it absolutely is too late to be hammering
> on this. Not only are you just moving complexity from one state to another
> (that actually means the same thing, with a different name),
>

A state that has behaviour that is conditional on the the entry into the
state is not one state.   A state that changes behaviour after a timeout is
not one state.  As I have frequently said, this state machine is a fantasy
that does not represent reality.     All implementations are going to have
a state change within closed state as they expire the undefined timeout and
change behaviour.

you're adding more normative text and changing the behavior of the
> protocol. Given that we're past WGLC and well into dealing with the IESG's
> feedback, I don't see how adding a "rst ack" could possibly have any chance
> of meeting the high bar for changes to be accepted at this point.
>

All true and good process arguments for not making this good technical
change.     But I'd say it is a pretty fundamental failure of the process
that we have such a broken state machine this late in the process.


I'm a solid -1 on this, and I'm confident in saying there is no argument
> that will change my mind on this one.
>

What if I split the PR into two parts.

The first would simply define the reset state and the behaviour associated
with it.   The "a short period" timeout would then be used to move to
closed state.    This would not change the wire protocol, but would improve
the description of the current behaviour.

The second part would be the "rst ack", which we can put on hold until a
subsequent iteration






-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Friday, 23 January 2015 17:21:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC