Re: [hybi] WS framing alternative
"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 02 November 2009 11:08 UTC
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC0628C1F2 for <hybi@core3.amsl.com>; Mon, 2 Nov 2009 03:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.443
X-Spam-Level:
X-Spam-Status: No, score=0.443 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5QSsgO2j+DF for <hybi@core3.amsl.com>; Mon, 2 Nov 2009 03:08:51 -0800 (PST)
Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id E730B28C1FB for <hybi@ietf.org>; Mon, 2 Nov 2009 03:08:50 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id nA2B8xJj019075 for <hybi@ietf.org>; Mon, 2 Nov 2009 20:08:59 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0373_1eb1afc4_c7a0_11de_bc22_001d096c566a; Mon, 02 Nov 2009 20:08:59 +0900
Received: from [IPv6:::1] ([133.2.210.1]:53952) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1251C56> for <hybi@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 2 Nov 2009 20:05:28 +0900
Message-ID: <4AEEBDBE.4050602@it.aoyama.ac.jp>
Date: Mon, 02 Nov 2009 20:08:46 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@gbiv.com>
References: <mailman.3820.1256908248.4669.hybi@ietf.org> <91a5e3ea0910301458q465e5778kb46bcaedc65595a6@mail.gmail.com> <4AEB7AD1.7050509@webtide.com> <Pine.LNX.4.62.0910310401280.25616@hixie.dreamhostps.com> <4AEE33AE.4080601@webtide.com> <ACE82410-B820-494F-906F-03A413D6CFE3@gbiv.com>
In-Reply-To: <ACE82410-B820-494F-906F-03A413D6CFE3@gbiv.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] WS framing alternative
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2009 11:08:52 -0000
Hello Roy, You say that waka was already capable of all of this back in 2001. Can you give us some pointers? What I found is http://gbiv.com/protocols/waka/200211_fielding_apachecon.ppt, which is quite interesting, and says (p. 19): waka * Has not yet been fully specified * Has not yet been implemented * Has not yet been deployed * Will eventually be proposed as ASF project * Will eventually be submitted to IETF * Will have its progress tracked: http://www.apache.org/~fielding/waka/ The later currently gives a 404. Regards, Martin. On 2009/11/02 17:07, Roy T. Fielding wrote: > On Nov 1, 2009, at 5:19 PM, Greg Wilkins wrote: >> >> The problem with what you say are the "we could add", "future version" >> and "if we decide" parts. >> >> Netscape didn't have to wait for any "we" to formulate HTTP/1.1 so that >> persistent connections could be supported. They came up with HTTP/1.0 >> keep-alive as a defacto standard that worked because HTTP supports >> arbitrary meta-data that can be ignored. > > FTR, Netscape had very little to do with formulating keep-alive. > > There were three research projects that showed potential value > in persistent connections. There was also some list discussion > on how best to do that, culminating in at least three different > proposals that I presented at the IETF's HTTP BOF in December 1994. > None of those proposals were accepted. The keep-alive header > came out of a compromise that Henrik and I came up with after the > BOF session, in response to the BOF comments, which I later > wrote-up as a set of notes and distributed to a few of the > primary HTTP implementors at the time, including the folks at > Netscape who had been more interested in a batch method (MGET) > but were eventually convinced to implement keep-alive along > the same lines as Apache httpd and W3C libwww. After we had > demonstrated interoperability, the mechanism was added to a > late draft of HTTP/1.0 and eventually replaced by HTTP/1.1's > persistent connections (triggered by the version change). > > ... > > Although I agree with most of Greg's design points (most of which > were included in the design of waka back in 2001), I still > see no reason for the IETF to standardize anything in the realm > of a hybi protocol at this time. Simply put, there is not enough > agreement yet on what the goals should be, let alone the standard > way everyone should implement them. > > I look at Websockets and what I see is a very limited mechanism to > tunnel arbitrary protocols through an HTTP-established connection, > in spite of the fact that arbitrary protocols are neither secure > nor architecturally scalable on the open Internet. This is just > a slight twist on the old schemes of using CORBA or Java RMI that > Netscape tried to introduce and ultimately failed, and the DCOM > over HTTP crap that Microsoft tried to introduce and ultimately > failed. Those schemes failed because they were architecturally > and socially incompatible with organizational trust boundaries > and the anarchic scalability required on the Web, not because the > protocols lacked some secret sauce. > > I see no point in trying to convince Ian that he is on the > wrong track. As long as Websockets isn't wedged into a more > established spec (like HTML), then it can succeed or fail on > its own terms. The only risk to me is that Apache may have to > introduce code specifically blocking such requests being passed > through the server's extensibility interfaces (API, CGI, etc.), > because there is no effective difference between Ian's requirements > and an extended denial-of-service attack. > > Likewise, I look at BWTP and I see it trying to adopt all of HTTP's > weaknesses regarding syntax and none of its strengths regarding > separation of concerns and simplicity. I don't know if that is > fatal to the idea or not, since AFAICT the only use cases for hybi > that are not unacceptable, either socially or in terms of scale, > are already adequately covered by SMTP. > > My advice is: stop trying to convince each other that your ideals, > use cases, and design theories are even remotely similar. They > are not even comparable. They do not belong in the same WG. > Neither one is suitable for standardization at this time. > They should demonstrate their viability first without being > designed in committee, just like all of the other successful > IETF protocols. > > I think it is a mistake for hybi to continue as if there were > something to standardize here. Waka could do all of this stuff > (in addition to replacing normal HTTP communication), but > I wouldn't dream of bringing waka to an IETF working group > without a half dozen working implementations and a very firm > grasp of why it should be standardized. It is just such a > ridiculous waste of time to try to get consensus amongst > people who aren't implementing the same type of system, > let alone the same exact protocol. > > A protocol is ready to be standardized when there is > no longer any need to explain what it is used for and why > people should want to implement it. Standardization is only > needed when independent implementations already exist but > differ in their observed behavior. > > ....Roy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
- Re: [hybi] WS framing alternative Sylvain Hellegouarch
- Re: [hybi] hybi Digest, Vol 8, Issue 41 Jason Duell
- Re: [hybi] hybi Digest, Vol 8, Issue 41 Ted Goddard
- Re: [hybi] hybi Digest, Vol 8, Issue 41 Greg Wilkins
- Re: [hybi] hybi Digest, Vol 8, Issue 41 Jamie Lokier
- Re: [hybi] WS framing alternative Ian Hickson
- Re: [hybi] WS framing alternative Greg Wilkins
- Re: [hybi] WS framing alternative Roy T. Fielding
- Re: [hybi] WS framing alternative Greg Wilkins
- Re: [hybi] WS framing alternative Martin J. Dürst
- Re: [hybi] WS framing alternative Pieter Hintjens
- Re: [hybi] WS framing alternative Roy T. Fielding
- Re: [hybi] WS framing alternative Greg Wilkins
- Re: [hybi] WS framing alternative Greg Wilkins
- Re: [hybi] WS framing alternative Pieter Hintjens
- Re: [hybi] WS framing alternative Greg Wilkins
- Re: [hybi] WS framing alternative Pieter Hintjens
- Re: [hybi] WS framing alternative Greg Wilkins