Re: [hybi] WS framing alternative

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 30 October 2009 07:10 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 7D4313A67F2 for <hybi@core3.amsl.com>; Fri, 30 Oct 2009 00:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.451
X-Spam-Level:
X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=0.241, 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 C0YAbrBP95kV for <hybi@core3.amsl.com>; Fri, 30 Oct 2009 00:10:28 -0700 (PDT)
Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id C640B3A63D3 for <hybi@ietf.org>; Fri, 30 Oct 2009 00:10:26 -0700 (PDT)
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 n9U7AUOs028101 for <hybi@ietf.org>; Fri, 30 Oct 2009 16:10:32 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 639d_4ea54d82_c523_11de_a886_001d096c566a; Fri, 30 Oct 2009 16:10:30 +0900
Received: from [IPv6:::1] ([133.2.210.1]:51768) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S124BAB8> for <hybi@ietf.org> from <duerst@it.aoyama.ac.jp>; Fri, 30 Oct 2009 16:07:01 +0900
Message-ID: <4AEA9151.9040608@it.aoyama.ac.jp>
Date: Fri, 30 Oct 2009 16:10:09 +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: Ian Hickson <ian@hixie.ch>
References: <8B0A9FCBB9832F43971E38010638454F0F1EA72C@SISPE7MB1.commscope.com> <Pine.LNX.4.62.0910270903080.9145@hixie.dreamhostps.com> <a9699fd20910270426u4aa508cepf557b362025ae5db@mail.gmail.com> <Pine.LNX.4.62.0910271824200.25616@hixie.dreamhostps.com> <4AE76137.8000603@webtide.com> <Pine.LNX.4.62.0910272118590.25608@hixie.dreamhostps.com> <20091029123121.GA24268@almeida.jinsky.com> <4AEA0E6C.1060607@webtide.com> <4AEA5713.8020008@it.aoyama.ac.jp> <Pine.LNX.4.62.0910300346010.25616@hixie.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.62.0910300346010.25616@hixie.dreamhostps.com>
Content-Type: text/plain; charset="UTF-8"; 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: Fri, 30 Oct 2009 07:10:29 -0000

Hello Ian,

[order of citations somewhat rearranged.]

On 2009/10/30 13:22, Ian Hickson wrote:

> On Fri, 30 Oct 2009, "Martin J. Dürst" wrote:
>> That said, however, I also agree with some other people on this list that
>> extension points should be considered carefully. Greg's proposal:
>>
>>>    1) WS should allow arbitrary headers in the upgrade request/response

 >On Fri, 30 Oct 2009, Jamie Lokier wrote:
 >> Since you must negotiate any custom protocol layered on top of
 >> WebSocket out of band anyway (e.g. by agreeing what is present on some
 >> URL)

 >Actually the WebSocket-Protocol header lets you negotiate that at
 >connection time.

Does that mean that WS allows arbitrary headers in the upgrade 
request/response? Or that there is one header, WebSocket-Protocol, with 
potentially a lot of data stuffed into it?


>>>    2) WS should define a frame type for transport meta data, whose
>>>       content is defined only as Mime (or just mime headers).
>>>       The semantics of these can be left to other protocols built
>>>       on top of WS.
>> seems to be a very good starting point.
>
> Could you elaborate on what problem this solves?

You seem to assume that Web Sockets communication is basically just 
between a client and a server, without any intermediaries getting 
involved in any significant way. In that case, you are fine. But if 
there's anything where intermediaries get involved in a specific way 
(other than just letting everything through or just blocking), then 
there's probably a need to let these intermediaries know some info. 
Because the payload frames are for data exchange between the client and 
the server, they are essentially opaque to intermediaries, so you can't 
use them for that purpose. That's where a separate frame type comes in 
handy.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp