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

gabriel montenegro <g_e_montenegro@yahoo.com> Mon, 12 July 2010 09:48 UTC

Return-Path: <g_e_montenegro@yahoo.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 16B583A683C for <hybi@core3.amsl.com>; Mon, 12 Jul 2010 02:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 Te362zTjNYF9 for <hybi@core3.amsl.com>; Mon, 12 Jul 2010 02:48:35 -0700 (PDT)
Received: from web82601.mail.mud.yahoo.com (web82601.mail.mud.yahoo.com [68.142.201.118]) by core3.amsl.com (Postfix) with SMTP id 6C7983A6903 for <hybi@ietf.org>; Mon, 12 Jul 2010 02:48:34 -0700 (PDT)
Received: (qmail 97222 invoked by uid 60001); 12 Jul 2010 09:48:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278928121; bh=WBYApOaLQY42D1kvo857NOqOK6AAaqmG4aG+Mg2iPIk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Shp89otLjTtUtz2D6I30xPPg1dKyU8J8ovi5/rTmDBQYyd6BtlLCvdeyJVVifz2QRQY8y2FY36DGYHZZPE+sfu8UhutfQfSJLspdMAwXJProdFUaWP0sW1eOeZF8Az0ssITX5k/u+9PubkfAC+Vtn7hJ8uS3cNBgQeu7q6VWSaA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LTW7/eNPHr6Qq0MHqStaVwmx0geyKcIS9G25QI6k/xw2ZgsjdJOfRVwW9TnqwuY9i2xF1CRh8CMQSOumer0MsllZt5Czwiv8yEXw2F/RK+DT856h57mlV8n7S4XU7Yu2IbBHcM94SbtKKVUT4nYGOd5XvjuMXI9SQQlAPI50rk4=;
Message-ID: <814698.93763.qm@web82601.mail.mud.yahoo.com>
X-YMail-OSG: H87mIugVM1lUZ0WKU_jULuXFqD.IN9GH535wiAMqktBhKS. ZRnXfo5pZS29XbEm0vZDIg0WML8hOS5jen2gqQDyJxZqDnN0gtj9S2ciAsy_ hk5sC2Na2W1v8lMMkx4iTvOs5g3Jror9rUMaVB1uPpiG4CZ9ltk.e0ZUVodQ Zg6ayp.eolomPN1Ws0.jemEI5DCDsq6SNhsE1GrJgtI9_om2QlNiVfYSkxf. rrR0JS2osEqO0njrZBMaVocFfKvD_4RqWu4hfPl5vAULJl_Typ.bSJNEddIX n2yqydOOrTmkRxZpKSCzslQF2ohh_eLz.ixNaIB_A2e.mi1iSxKzrf0dT7YS E
Received: from [71.197.227.220] by web82601.mail.mud.yahoo.com via HTTP; Mon, 12 Jul 2010 02:48:41 PDT
X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457
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>
Date: Mon, 12 Jul 2010 02:48:41 -0700
From: gabriel montenegro <g_e_montenegro@yahoo.com>
To: Anne van Kesteren <annevk@opera.com>, hybi@ietf.org
In-Reply-To: <op.vfl5hj0864w2qv@annevk-t60>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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 09:48:39 -0000

Hi Anne,


> From: Anne van Kesteren <annevk@opera.com>
> [gm] Hmmm... I was under the impression that the whole point was 
> to
> start with HTTP and then via the Upgrade directive move into 
> the
> WebSocket protocol. Or are you saying that there might be other 
> ways
> to start other than HTTP?

> 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. 

>> Why should we constrain size in
>> the 
> requirements?
> 
> [gm] Please see my response to Greg's 
> message.

Please see above. :-)

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

>> Suggest rewording as 
> follows:
>>    REQ. 11:  During the
>> 
> handshake ,the WebSocket Client MUST be able
>> to send one or 
> more
>> WebSocket sub-protocol proposals to the server
>> so 
> that the server can
>> select one.,This results in the use of a 
> specific
>> WebSocket
>> sub-protocol.
> 
> I 
> don't think this is needed. It's also something that can
> easily be added 
> later if application authors find a need for
> it.
> 
> [gm] 
> Are you disagreeing with the proposed rewording or with the original
> 
> wording?:
> 
> "  REQ. 11:  The WebSocket Client MUST be 
> able to request the server,
>      during the handshake, to 
> use a specific WebSocket sub-protocol.
> "
> 
> The rewording 
> did not change the basic requirement for sub-protocol support, it was just 
> adding more text as to how that might happen.

The rewording suggests the 
> client transmits one or more sub-protocols. I don't think we necessarily need to 
> go there (too complex for v1 and probably not needed at all) and the 
> requirements document should not constrain that. Having said that, I'm not even 
> sure it makes sense to talk about sub-protocols in the requirements document. 
> Requirements should be high-level.

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).

thanks,

Gabriel