IETF Logo Mail Archive

Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

Yutaka Hirano <yhirano@chromium.org> Fri, 07 February 2014 07:05 UTC

Return-Path: <yhirano@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 743D21A05B8 for <hybi@ietfa.amsl.com>; Thu, 6 Feb 2014 23:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Level:
X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
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 uXIWr9bQQAdl for <hybi@ietfa.amsl.com>; Thu, 6 Feb 2014 23:05:45 -0800 (PST)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC971A05B7 for <hybi@ietf.org>; Thu, 6 Feb 2014 23:05:45 -0800 (PST)
Received: by mail-qc0-f181.google.com with SMTP id e9so5169526qcy.40 for <hybi@ietf.org>; Thu, 06 Feb 2014 23:05:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=A++8z6DzNfJXcX+4Dbm8Pb0JQJ6ZeUxWVJSHtP+lojo=; b=bLpSuHKA2u0IdoUotaMSZpdJHOYmlRe+sucqdqnOzF1l1bMS7mXgagJllEGMWXPSrP a2TmkOjFe4VGOM5M0J7kbz3mctGsZc/EJNhMlbzVOMl/3oeKp5fTx1x9R9c012ETMLJi rKbMrgmLtQVQfqvldBV4Kpp/hEDqISAc4kW3V/wX9TqVn/zo7s024fI/HXN25aKdoATF xWE9lLAnu153VSD9PCm6qvcYajRMnefnGhvYG7rmodEEi/WHjgYgTXmnX15ugAHsUAs7 I77hrfm3CqZBVCFmVnpyHPmRGX842ZoHQUnJQ/wahyFD7/iAyGUNbmpkZ66pFqQhcokI +N9A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=A++8z6DzNfJXcX+4Dbm8Pb0JQJ6ZeUxWVJSHtP+lojo=; b=KuMwJfzKly2bBwgolUVcl9Aiq5xLoKJaWvACl/sfpH1sf1Nh2JntgZcKRBUKKERK2S w7ZIvKqr/nnRsiJbeiyV1FZcUzliez/IHLyvdpCP3yI4pYoPDtWc3HRUIOwqpqKNZyXu lnOJxTXrxsu98df7VKkNM+/Z0o+p3w18FQ7cc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=A++8z6DzNfJXcX+4Dbm8Pb0JQJ6ZeUxWVJSHtP+lojo=; b=eAIgKppvKOYlc9ezMNzwn21GnxMEOE/XFdd8TK6BJDqjHLAtR2BmmQPE7lu4HB77aD Z9Pow1J5jyCpejc77h+/J4zu8tRKOLb+b69DAkn6ib5w6IkSnwJjCuu+bwd48Fm9gEJn 0uQEBgMAi3bfSa1CJL3+SvwTSeiejgye+bx82oMNNgIAJYrstfBh9Wc6rhr7mNlDQZxK ZvBsPeKWWmDoRc7Rrh3o47wJquhelnQT/8IoOE/FLNkOV+UrUo9UnjEAzJCnWUJkAQP9 6IaiHR8Mlt2p6/UUkEWpvi/LHueD15vwEyDhDNNqDH1W6pulUgi87Xr14TTP4u70fEzL nC3A==
X-Gm-Message-State: ALoCoQkb/tmdEzkQ0va6jWCDZloJn6SN5iT6Ko5I7f2/p5lANE3+V0VMgJ6jFMGXk4kavs35g/KeWLvcUne0DHH/kyp3H7/LiLcaI79GFwijEQDClXZ/V5395vrZfJVGpijOjkiBROX8/f+Jg25HPnY2mf3DsnecZuGQZkrujEaUVFHX0oAeqKXI2o7JTMNjpSRVbhVSBMHH
MIME-Version: 1.0
X-Received: by 10.140.22.145 with SMTP id 17mr18171640qgn.0.1391756743704; Thu, 06 Feb 2014 23:05:43 -0800 (PST)
Sender: yhirano@google.com
Received: by 10.140.109.202 with HTTP; Thu, 6 Feb 2014 23:05:43 -0800 (PST)
In-Reply-To: <2B0B9332-D002-460A-8D50-B90B55999F42@zaphoyd.com>
References: <CAH9hSJah=4Z4-NufVrUrP965epc9eMdEbC+3LmucN4DhR=bWiQ@mail.gmail.com> <634914A010D0B943A035D226786325D4446BE403DF@EXVMBX020-12.exch020.serverdata.net> <CABihn6H5EtDwhXMYhh-BMb5m6yxL9nYv6=Ud4fN5DeQkjDGyPQ@mail.gmail.com> <634914A010D0B943A035D226786325D4446BE403E1@EXVMBX020-12.exch020.serverdata.net> <CABihn6EaE+69q3AJqxEj6vGztBHu4FdOcLCvZ_9Jg-e2cFLwEg@mail.gmail.com> <CAGzyod7ymnpOTiiH7xN3W-aBxD2NNPc=S_Oawdihfhuu84unLw@mail.gmail.com> <634914A010D0B943A035D226786325D4446BED9CDE@EXVMBX020-12.exch020.serverdata.net> <CABihn6EGA3znv_WsJ1gELXyNXgY2fy8weBJ62yD+M2iP7xEnCA@mail.gmail.com> <634914A010D0B943A035D226786325D4446BF99976@EXVMBX020-12.exch020.serverdata.net> <CABihn6GFnGTB9sOZ1=2UnOv-pHPRnRY96DnOb_Q24bNUaxgR=w@mail.gmail.com> <9230B7A2-56AD-4807-A53A-928253364B52@zaphoyd.com> <634914A010D0B943A035D226786325D4446BF99A9B@EXVMBX020-12.exch020.serverdata.net> <F088AE82-E1AF-489B-B220-6E911078C1F3@zaphoyd.com> <6652CC7E-7E92-40EF-BD50-2DDD39E15533@zaphoyd.com> <740FF040-F1E9-43E6-ACDE-0014FE4D012F@zaphoyd.com> <CABihn6HM_yXSB9RapNEQEG0_9OYfpHG3uH+=wnDwRJAFbh9EJA@mail.gmail.com> <0F978119-88F2-49CE-98C6-2A640527AA64@zaphoyd.com> <CAGzyod7BA_UXjN4r+Qr+P33QsPpeWWotxiScTpzqyhvbtPgNYQ@mail.gmail.com> <2B0B9332-D002-460A-8D50-B90B55999F42@zaphoyd.com>
Date: Fri, 07 Feb 2014 16:05:43 +0900
X-Google-Sender-Auth: wVwuYCYz0wd-2lRB_3oidPHT-Cg
Message-ID: <CABihn6Hykczbu0YmUDuFcjVt2+xyeYzmdOpEkiZmP-2Vzuiuow@mail.gmail.com>
From: Yutaka Hirano <yhirano@chromium.org>
To: Peter Thorson <webmaster@zaphoyd.com>
Content-Type: multipart/alternative; boundary="001a11c13010529eb204f1cb9e7e"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0
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: Fri, 07 Feb 2014 07:05:48 -0000

Peter, Roberto, Tobias,
I think we should shrink the battle line.
I propose to choose if we preserve the RFC6455 semantics or not (for
framing).

*Preserve the RFC6455 semantics*
We won't change the RFC6455 semantics, which means we will discuss how to
encapsulate WebSocket frame(s) into HTTP/2.0 frame(s).
All RFC6455 extensions will be supported.
To preserve the RFC6455 semantics, I modify the proposed plans.

Plan A (WS-TUNNEL with MSG_DONE):
 - MSG_DONE is used as a FLUSH signal
 - multiple WebSocket message can be batched in a single HTTP/2.0 frame
I believe that this preserves the RFC6455 semantics.
I support this plan.

Plan C (HEADERS + DATAs for a WebSocket frame):
 - All headers including FIN and length are included in HEADERS.
 - MSG_DONE is mapped to the end of a **WebSocket frame**
  - This means that a WebSocket connection is a stream-of-WS_frames, which
is completely correct.
Hence HEADERS + DATAs represent a complete WebSocket frame.
I support this plan.
I believe Roberto supports this plan.

Plan D (WS-TUNNEL only): as is
Tobias and Peter support this plan.

Choosing "Preserve the RFC6455 semantics", means we choose framing method
from these three plans.
I know that all of us hate some of the plans, but I think this option is
better, because
 - All of us like some of the plans.
 - We can simplify the discussion.
 - if "Not preserve the RFC6455 semantics" seems appealing now, at least
partially that is because it is not concrete.

As the only supporter of Plan A, I promise that I will retract the plan if
a critical problem is found on it (it is not compatible with RFC6455,
MSG_DONE can't be used for the flushing purpose, FLUSH can't be introduced
and so on).

*Not preserve the RFC6455 semantics*
Choosing this option means we abandon Plan A, C and D.

*Questions*
As you notice, there are two questions from me.
1: Are you OK with deciding NOW if we should preserve the RFC6455 semantics
or not?
2: (If the answer for 1 is yes) Should we preserve the RFC6455 semantics?

My answer is, yes & yes.



On Fri, Feb 7, 2014 at 8:18 AM, Peter Thorson <webmaster@zaphoyd.com> wrote:

>
> On Feb 6, 2014, at 13:23 , Roberto Peon <fenix@google.com> wrote:
>
> > Unfortunately, one can't relax that requirement and still have the
> backwards-compatible API that exists today: while HTTP/2 can deliver on
> this, HTTP/1.X cannot.
> > That one need not change their content to deploy HTTP/2 (etc.) is a
> major driver of deployment, so it isn't something that could be lightly
> changed.
> > IMHO, we'd have to invent a new API (which, honestly I'd be all for, but
> that is a completely different set of work).
>
> This statement gets at the heart of the present discussion.
>
> I see the "plan D" option treating WebSocket as HTTP/1.1 is treated by the
> rest of HTTP/2.0, an existing protocol to be muxed mostly "as is" for the
> benefit of backwards compatibility with existing systems. I see a Native
> Messaging option as the "new API” that would allow a cleaner interface for
> pure HTTP/2.0 applications going forward.
>
> For me, the reality is that any piece of HTTP/2.0 software that I write or
> deploy in the foreseeable future is going to demux the message stream,
> convert to RFC6455, and forward to existing systems. This is both due to
> backwards compatibility as well as the nature of a large chunk of my user
> base (particularly the embedded non-browser clients) having no use for any
> of the features that HTTP/2.0 adds over RFC6455 and every reason to want to
> avoid additional overhead.
>
> Plan D provides a straightforward path for this sort of operation and
> simplifies things considerably for a good chunk of the infrastructure-type
> intermediaries without imposing any additional limitations on anyone (other
> than perhaps additional library/protocol dependencies for the more
> ambitious intermediaries).
>
> That said, even if I plan to proxy HTTP/2.0 messages right back into
> RFC6455. I also see the future benefit to having a cleaner messaging option
> that is aware of HTTP/2.0's new features. My first choice is for this
> option as it seems more sane long term.. as long as the new protocol is
> something worth breaking backwards compatibility for. The Plan D case is
> strong as well and I would not oppose that if the consensus says that
> backwards compatibility is more important.

v2.23.0 | Report a Bug | By Email