Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00

"Anne van Kesteren" <annevk@opera.com> Mon, 12 July 2010 10:10 UTC

Return-Path: <annevk@opera.com>
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 C36993A6912 for <hybi@core3.amsl.com>; Mon, 12 Jul 2010 03:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 7BZWXqtmbiQB for <hybi@core3.amsl.com>; Mon, 12 Jul 2010 03:10:31 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 527263A6903 for <hybi@ietf.org>; Mon, 12 Jul 2010 03:10:31 -0700 (PDT)
Received: from annevk-t60 (5355737B.cable.casema.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o6CAAMrb008153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Jul 2010 10:10:37 GMT
Content-Type: text/plain; charset="utf-8"; format="flowed"; delsp="yes"
To: hybi@ietf.org, gabriel montenegro <g_e_montenegro@yahoo.com>
References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <op.vfj9vfna64w2qv@annevk-t60> <564970.65690.qm@web82607.mail.mud.yahoo.com> <op.vfl5hj0864w2qv@annevk-t60> <814698.93763.qm@web82601.mail.mud.yahoo.com>
Date: Mon, 12 Jul 2010 12:10:22 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Anne van Kesteren <annevk@opera.com>
Organization: Opera Software ASA
Message-ID: <op.vfp6jk0h64w2qv@annevk-t60>
In-Reply-To: <814698.93763.qm@web82601.mail.mud.yahoo.com>
User-Agent: Opera Mail/10.70 (Linux)
Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00
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, 12 Jul 2010 10:10:33 -0000

On Mon, 12 Jul 2010 11:48:41 +0200, gabriel montenegro  
<g_e_montenegro@yahoo.com> wrote:
>> Yes, but mostly I'm saying that
>> the requirements document should not constrain the design to this level  
>> of detail.
>
> [gm] I think it is appropriate, given that we're supposed to be working  
> on what the charter set out to do:
>
> "  The Hypertext-Bidirectional (HyBi) working group will seek
>   standardization of one approach to maintain bidirectional
>   communications between the HTTP client, server and intermediate
>   entities, which will provide more efficiency compared to the current
>   use of hanging requests.
> "
>
> That seems pretty clear about HTTP usage.

Not to me. The main reason we are discussing what "HTTP compatible" means  
and how the "HTTP handshake" ought to look is because someone at IANA  
thought WebSocket should share a port with HTTP. It has nothing much to do  
with the charter. And frankly, it seems like things might be much easier  
if we did not share a port with HTTP.


> [gm] Not sure the above was specifically related to the size discussion,  
> so perhaps I'm missing something.

Effectively, too much detail for the requirements document.


> There was some discussion with Greg about this. There is some overlap  
> with Req.5 which does not actually talk about sub-protocols. That term  
> is not as important as somehow capturing that different framings should  
> be allowed
> (with one native format for interoperability).

That is directly contrary to the draft proposal we have today. It only  
allows clients to use frames that are defined in the specification.


-- 
Anne van Kesteren
http://annevankesteren.nl/