- From: Greg Wilkins <gregw@intalio.com>
- Date: Fri, 23 Jan 2015 18:20:51 +0100
- To: Nicholas Hurley <hurley@todesschaf.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NEZChvS1-qnwYYRPByDiUGhn1s6N3Ch8GJviYp2PUzguA@mail.gmail.com>
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