Re: [hybi] new version hybi-requirements

Scott Ferguson <ferg@caucho.com> Mon, 08 March 2010 20:54 UTC

Return-Path: <ferg@caucho.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 BC35A3A6953 for <hybi@core3.amsl.com>; Mon, 8 Mar 2010 12:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 kkDA9pteRUFr for <hybi@core3.amsl.com>; Mon, 8 Mar 2010 12:54:12 -0800 (PST)
Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 215FB3A6889 for <hybi@ietf.org>; Mon, 8 Mar 2010 12:54:12 -0800 (PST)
Received: (qmail 2371 invoked from network); 8 Mar 2010 20:54:16 -0000
Received: from [192.168.1.10] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 08 Mar 2010 12:54:16 -0800 PST
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: y9Ifop8VM1nsd44kb7VZyZzBDG2HFpJebcp_AdVHe_qER5cwXqQYGinDL2Ozlmw4RdXngOBN0AnyF75BAlYTdTHPrtPPO8aNAeYnUmRMbVVri0jcK43c7JP3y5M4hWjdPJV6vBFEyXivneRGaGif88EEJyuz_84iVnqa.y7PmEVo0e0evtdyyuKU2.9Ub8UdbO9e5vKQjyCJG2LSusFQFk7q5x6T6WvzftGw1L_UUdUp8CVqe8N3yI4FojPQBgYAfrFnXbdIgpQCWtAtUmXzkaXziJwn.Pn4zXf8SNkOiFtFqNf3mdc8HCxqCWOqIBRUTvqKDkjC1SQvQc5o3b7FcihjkDB7NcmJoUnuDIBYBKETu7yW2gsIA.A6tu4kR9xmMKZ.GQ7dbuZ7dJXT7r0ypcfffzs8eUNCcis0v9otUyGSz8Vi._vqi8JuNWebttyEAbD88Y9Z4g--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4B9563F7.6020706@caucho.com>
Date: Mon, 08 Mar 2010 12:54:15 -0800
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
References: <4B9554A0.1000909@ericsson.com>
In-Reply-To: <4B9554A0.1000909@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] new version hybi-requirements
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, 08 Mar 2010 20:54:14 -0000

Salvatore Loreto wrote:
> Hi there,
>
> I have submitted a new version of the "HyBi Requirements and Features"
> http://www.ietf.org/id/draft-loreto-hybi-requirements-01.txt
>
> I have changed and rephrased requirements following the consensus in 
> the mailing list.
>
> I have not inserted yet any requirements on extension and subprotocol, 
> as I haven't seen
> a clear consensus on it.
>    REQ. 11:  The WebSocket Client MUST be able to request the server,
>       during the handshake, to use a specific WebSocket sub-protocol.
>   


Validation might be a cleaner requirement than extension (I think REQ 11 
captures the idea), because clients and servers will want to verify that 
they're speaking the same protocol (and possibly verify the version) so 
they don't send incomprehensible frames to each other.  For example, 
even a simple a tic-tac-toe client will want to ensure it's really 
talking to a tic-tac-toe server and not a chat server. (Or a server may 
upgrade/change a version and want to redirect legacy clients to a 
different URL.)

Negotiation/extension may or may not be a requirement (e.g. using HTTP 
redirects), but I think validation of the sub-protocol is a must have, 
even if the client is just checking that the server is expecting raw 
text strings vs binary.

So REQ 11 might have a corresponding server requirement, where the 
server can reject the upgrade if the client's sub-protocol is missing 
(and obviously allow the server to reject the connection if the 
sub-protocol is wrong.)

-- Scott
>
> I look forward to see your comments and feedbacks.
> The draft will be also discussed during the meeting in Anaheim.
>
>
> As chair, I will maintain editorship of the draft, with a goal of 
> naming editors at (or soon after) IETF 77
>  - If you are interested in editing either of those drafts, please 
> email the chairs off-list.
>
>
> Cheers
> Sal
>