- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 07 Dec 2010 15:47:54 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Greg Wilkins <gregw@webtide.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-id: <CF412E56-591F-46F4-AC45-F21D40E30CC9@apple.com>
On Dec 7, 2010, at 2:53 AM, Mark Nottingham wrote: > > On 07/12/2010, at 6:04 PM, Maciej Stachowiak wrote: > > >> It's also worth noting that operating over ports 80/443 and coexisting with an HTTP server are goals that come from our charter and requirements document, so abandoning those goals would likely require a major reboot of the group. > > No, the charter says nothing about what port(s) the protocol will run over. The requirements you refer to are a -01 draft, so they don't represent IETF consensus. Have there been any WG consensus calls on them? Not on the whole document, but there have been consensus calls on specific items in the draft, notably including the "share a port" item and the related concept of http compatibility. > >> We already have implementors impatient to see a production-shippable protocol, it doesn't seem so great to me to go back to the drawing board. > > > AIUI changing the handshake is already the subject of a lot of discussion, so this is hardly "going back to the drawing board." > > I fully agree we need to unblock this discussion and ship a protocol. I'm trying to understand why people are digging in their heels on a design that's supposed to be helping server deployment, when AFAICT the server folks are telling them it's not workable. The main complaint about CONNECT from server folks seems to be literally a question of semantics. There is also the related practical issue of having to turn off alerts on CONNECT attempts if you want to serve WebSocket. If there are other proposals that would work better and serve the same use cases, that would be useful input to the conversation. "Don't try to share a port with a Web server" is not a sufficiently fleshed out proposal to move the conversation forward, and does break some use cases that were identified as desirable. If someone cares to present a more concrete proposal, we'd be in a position to evaluate the tradeoffs. Regards, Maciej
Received on Tuesday, 7 December 2010 23:48:33 UTC