Re: [hybi] WebSocket subprotocol parameters

Takeshi Yoshino <tyoshino@google.com> Thu, 23 January 2014 04:50 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7621A01AD for <hybi@ietfa.amsl.com>; Wed, 22 Jan 2014 20:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.713
X-Spam-Level:
X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldG7DklXmT8Z for <hybi@ietfa.amsl.com>; Wed, 22 Jan 2014 20:50:13 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD881A018D for <hybi@ietf.org>; Wed, 22 Jan 2014 20:50:12 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id t60so723839wes.18 for <hybi@ietf.org>; Wed, 22 Jan 2014 20:50:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n5PA5i6lgzdrIQeIH1NgQVBV8v5jDpub62e4O/8futI=; b=Dyfxkog0wqr5xxMXqsmozN8mPEDUbu9Wk8opGGq/B2mb86Ud3KYxRN5ETKmj5rsSU2 SmOKNBECknUZqejKzYXdFFC4evq5emhrUhlJ2nqCH3EDnZCoWIkHT48PvhBThVP7cRJw cLEtpzyefU+Vnx9XpHIstrzYCbrGoGqJ1BJ/OorWbsdGnD+3N+TCsFVbbmufl4fIcjeC jPuI9P1hYgt7Ou65QYSw5mEJXGQm3sndj0HWvqX55k/NzzSB2VuDpZKQ1Vt3sTVKUP/p 7SLnH2B/rDEH7palC0qzW7i01F5kikAXN0/Io6tMN9pbKX2ysSdJPRlNsSOBW88pYQaq 2wPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=n5PA5i6lgzdrIQeIH1NgQVBV8v5jDpub62e4O/8futI=; b=aRMUKJv4S40NkApDq1tFuW1p0yfmTaak844rQ/dFz7MnfoXusvHiA8g3bFnJ6m3+oM 66yBw2+fZ3sFG5Vs8ssNyI43bEST7guSuTWsBclMm7JkOMrBA8xK+qFjLzrZPRhO8uWN ThMOvN0PjEhD+nacDmvdHkDZirUXtJSSlXiZYWFkbRq3cIwNks346JCsi0uLort0jyi3 Jil83QvR/HzJfo6ORileJF0erUPcFnPtJ41w/8lwR6BnkIE5i1y4stiXx4EGguwkBSlX CgVRAH5ZFdyvZE9uTIVkinHgjKJZyI/QPze/67r3Xcggkg1s7H1nAPtWKSgF6/B0Et6C EXAQ==
X-Gm-Message-State: ALoCoQnFUIF3qvPT046CbfDNY9LOIqcYUoe68sIlaSGg1sJ4NQ2psByeC7O6H9bT/n9a71K1HR7No3laetCRLWJdHHzTOv5STCen29usVxIiYml2dPzAAb8FKz8gySRyRzjep9Q6NGGgbSCPspbWlw1tFlhLR5DoZhhfXFswgnHQkao0FhYymCMTeUQVRKFFskDGj9PYMKSH
X-Received: by 10.194.78.141 with SMTP id b13mr4859690wjx.32.1390452611665; Wed, 22 Jan 2014 20:50:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.8.231 with HTTP; Wed, 22 Jan 2014 20:49:51 -0800 (PST)
In-Reply-To: <634914A010D0B943A035D226786325D4446C082A0D@EXVMBX020-12.exch020.serverdata.net>
References: <634914A010D0B943A035D226786325D4446BF9948F@EXVMBX020-12.exch020.serverdata.net> <52D90F99.6080205@gmx.de> <634914A010D0B943A035D226786325D4446BF9949D@EXVMBX020-12.exch020.serverdata.net> <CAH9hSJZQ3NxVW36PnZ0TpMF4tPPaJLr12M8NtbPb6pUejf1wcQ@mail.gmail.com> <634914A010D0B943A035D226786325D4446BF99977@EXVMBX020-12.exch020.serverdata.net> <B8ED6F18-B710-44AE-829B-EDE5859B2C5B@zaphoyd.com> <52DE3B1B.1010804@it.aoyama.ac.jp> <634914A010D0B943A035D226786325D4446C082A0D@EXVMBX020-12.exch020.serverdata.net>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 23 Jan 2014 13:49:51 +0900
Message-ID: <CAH9hSJZwf4ZuOnOwt7k+YjqCd5zxYYWXdp=krPjZKE+Tq=9LXw@mail.gmail.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary=047d7bfcfc82fefe7304f09bf94e
Cc: Julian Reschke <julian.reschke@gmx.de>, "hybi@ietf.org" <hybi@ietf.org>, Peter Thorson <webmaster@zaphoyd.com>
Subject: Re: [hybi] WebSocket subprotocol parameters
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 23 Jan 2014 04:50:16 -0000

On Tue, Jan 21, 2014 at 7:12 PM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> > > My impression was that subprotocol primarily changed the interpretation
> > of messages payloads by the end applications themselves. WebSocket
> > messages allow essentially arbitrary data so you can define whatever
> > parameter setting mechanism you like with whatever grammar makes sense
> > for your subprotocol and send the parameters in the opening “hello”
> > message. Defining a grammar in the socket spec to allow application
> > protocols to configure themselves seems limiting and out of scope.
> >
> > Yes indeed. It has always been my impression that even subprotocols
> > themselves are rather unnecessary. On the server side, just use a
> different
> > URI/IRI as endpoint. On the client side, it's all JS anyway.
>
> No quite, since using a different URL does not allow the server to
> communicate back
> it's subprotocol selection, e.g.
>
>
The server can immediately send back a frame following the opening
handshake response. So, there's not much difference between subprotocol
selection reply in form of opening handshake and in form of the first
message. No additional RTT.


> Sec-WebSocket-Protocol: foo.msgpack, foo.json
>
> allows the client to announce the "foo" protocol in 2 variants (MsgPack
> and JSON serialization)
> and the server to _select_ one of those, and communicate back it's
> selection to the client.
>
> An URL
>
> ws://server.com?serializers=msgpack;json
>
> does not allow the server to communicate back it's selection.
>

So, you'll define a thin extension layer to your application level protocol
which uses the URI and the first message from the server to negotiate
subprotocol parameter.


>
> Further, as an example, imagine a subprotocol that allows message batching
> with length prefixes, that wants to negotiate the number of bytes used for
> the length prefix.
>
> Sec-WebSocket-Protocol: foo; max_len_prefix=4
>
> A server that wants to use "len_prefix=3" cannot communicate that -
> neither with URL (since there is no "URL response"), and not with
> Sec-WebSocket-Protocol,
> since the server _must_ choose one subprotocol announced by the client
> _exactly_.
>
> It cannot answer
>
> Sec-WebSocket-Protocol: foo; len_prefix=3
>
> Since the number of bytes per length prefix in batched messages is needed
> to _parse_ already the first WebSocket message at application level,
> negotiating at the WS application message level does not work either (or
> gets complicated).
>

I understand it'll be simpler if we could complete that with in subprotocol
negotiation framework. But does it really get so complicated if we do that
using URI and bootstrap message? The client just need to pass one phase
where it parses len_prefix from the server and then transit to real app
mode where len_prefix will be used.

I don't object to raising a request to relax subprotocol constraint from
the next version. But I think it doesn't make much difference technically.