Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

Wenbo Zhu <wenboz@google.com> Fri, 28 October 2016 01:09 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BA3129440 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 27 Oct 2016 18:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.451
X-Spam-Level:
X-Spam-Status: No, score=-7.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 gyBgi0hb6uTp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 27 Oct 2016 18:09:14 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75459129406 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 27 Oct 2016 18:09:14 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bzvbV-0004VG-A3 for ietf-http-wg-dist@listhub.w3.org; Fri, 28 Oct 2016 01:05:05 +0000
Resent-Date: Fri, 28 Oct 2016 01:05:05 +0000
Resent-Message-Id: <E1bzvbV-0004VG-A3@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <wenboz@google.com>) id 1bzvbN-0002uS-0E for ietf-http-wg@listhub.w3.org; Fri, 28 Oct 2016 01:04:57 +0000
Received: from mail-oi0-f46.google.com ([209.85.218.46]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <wenboz@google.com>) id 1bzvbG-0001tE-Jh for ietf-http-wg@w3.org; Fri, 28 Oct 2016 01:04:51 +0000
Received: by mail-oi0-f46.google.com with SMTP id n202so80840836oig.3 for <ietf-http-wg@w3.org>; Thu, 27 Oct 2016 18:04:30 -0700 (PDT)
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; bh=8H04CStOoIIAjWYBRl46OZ75fDfyAjMeBb8zdh8t7VI=; b=WuHQ4oF1M0K3nZqQVKI9mBekHbHRL32PEoK/M09dvga5JwAYcLyIOsSzIZ++jXM/Zp e7Ao/kPoiGI0pkZnizbH0EfIE1FxLeXgMCGUsnmmtZ0Ohd1zJ2vvVgHn3WICqj62ZdUO PTBbe/ui0ES55j42ZfvreyLzXJiq/AsPFDp3a2/SJvYccf6q6V4wdFS8rFoqUU+xnJpc 7adDIjLvSvDlddCANc/xePtH1P2VSrAAyv68jEIShU5zRHctLnCD79TWU711M3/BK7Zr 2rfRQEcg+tY1Xr8tugDtxnwS8oHYNZeaKAN7fqBADTVCjXtBja1/fgQv17u/1Es2XIyA NHuA==
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; bh=8H04CStOoIIAjWYBRl46OZ75fDfyAjMeBb8zdh8t7VI=; b=FPRUpsZnHtf5dw8SZF9fxKdacN5hdrYdhQjiP6l2U9ZmBi/sXBjRX9mnF24wvXlMd3 o1h0oEvdJg+RXI95WbTS/nGFIwpqQsjGjTCGisxZxqOCxb4+GkDltmPnFw8xu/P+D+uv mqSaISsfK6QaBPxlM5wj1cu37/3MeDhnZyzjWU6YyK9/fc37tcC76+3/OJqpd9arstcD 8t4EGiKKEUnzvYhSPLOml0XvqX3aw/1TTsehKk36e8aoqw+cmhfkf2Rnzi7iA3UeLIUr AZ3Rf5onlKiw0RAaA5AQ7PF+PitRtMZJ4o5ZbYi6UISP1sBzfmIzmAMZXEmT59iaNerS cAUw==
X-Gm-Message-State: ABUngvcwMCvZTKEqFV/fr86wadgmL4KcOnZOmpXk8abZZRx0TXGN3Xj47bBF8tVuRO3DGLgGHZkDF3RHEWiognXl
X-Received: by 10.107.8.139 with SMTP id h11mr9509833ioi.55.1477616663899; Thu, 27 Oct 2016 18:04:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.19.244 with HTTP; Thu, 27 Oct 2016 18:04:23 -0700 (PDT)
In-Reply-To: <5541be74-afcc-6aef-404e-63acb2f608eb@ninenines.eu>
References: <CAH9hSJZdBJ02+Z6o=aanZ=5PN=9VwyL1ZcX2jct-6f_FFivLGA@mail.gmail.com> <0f79ddf6-c455-c41a-f269-a1bdcef05b14@ninenines.eu> <CAH9hSJb2R9gv2vNqoyTjbMV4hZTYdpX2PoAoYgWUT1UuigLHRA@mail.gmail.com> <5541be74-afcc-6aef-404e-63acb2f608eb@ninenines.eu>
From: Wenbo Zhu <wenboz@google.com>
Date: Thu, 27 Oct 2016 18:04:23 -0700
Message-ID: <CAD3-0rOYZzp2mB3NYZwXvGPUxPz8GG+ih1binEajv3CJFCW-7Q@mail.gmail.com>
To: Loïc Hoguin <essen@ninenines.eu>
Cc: Takeshi Yoshino <tyoshino@google.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a113f9d865e131b053fe270cd"
Received-SPF: pass client-ip=209.85.218.46; envelope-from=wenboz@google.com; helo=mail-oi0-f46.google.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=1.021, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.411, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1bzvbG-0001tE-Jh 8c5a0e2634abe70c5eb635d5c16eafad
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <http://www.w3.org/mid/CAD3-0rOYZzp2mB3NYZwXvGPUxPz8GG+ih1binEajv3CJFCW-7Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32694
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Thanks for the feedback.

On Fri, Oct 21, 2016 at 9:34 AM, Loïc Hoguin <essen@ninenines.eu> wrote:

> On 10/21/2016 03:04 PM, Takeshi Yoshino wrote:
>
>> <snip>
>> Good point. I was thinking about using the media type suffix convention
>> like +json, +xml, etc. (RFC 6839, RFC 7303) when we need to represent
>> the type of the messages. As the WebSocket subprotocol is required to
>> conform to the token ABNF, they can be embedded into the subtype part.
>>
>
> The problem with "+json" and "+xml" is that they do not represent the type
> of the messages, just their encoding.
>
> This is why we have media types like "application/problem+json" instead of
> using "application/json" for everything, where "application/problem"
> indicates what the representation contains, and "+json" indicates its
> encoding.
>
> Going back to WiSH, having application/webstream+json would only give
> information about the encoding of the response and frames bodies, not what
> they actually contain or how an endpoint should process the frames. We
> would still need more info to process it.
>
Agreed. It's also unclear how to apply a single suffix to text/binary
frames.


>
> Regarding negotiation, my impression to the subprotocol mechanism of RFC
>> 6455 has been that it's not really necessary thing. The server and JS
>> (or native application) may negotiate application level sub-protocol
>> using e.g. URL (some parameters in the query part or even the path part
>> can encode such info) and the initial message sent following the
>> handshake response immediately without any latency loss (this topic was
>> discussed at the HyBi WG sometimes e.g.
>> https://www.ietf.org/mail-archive/web/hybi/current/msg10347.html
>> <https://www.ietf.org/mail-archive/web/hybi/current/msg10347.html>).
>>
>
> The good thing is that it's standard. There's only one way to select a
> sub-protocol, and you are guaranteed failure (or a normal HTTP response) if
> the endpoint doesn't speak the sub-protocol you want.
>
> The use of a media type is precious to me as it makes it possible to write
> an autonomous client. Making the sub-protocol as part of the media type
> simplifies things greatly.
>
> There are potential issues though and a number of things need to be
> defined:
>
> * The method used to perform the request is important. A client will not
> be able to speak to the server if the method is GET. Similarly, no
> communication can occur if the method is HEAD. I would advise defining
> behavior for both GET and POST methods.
>
> * The GET method would be used to enable a server->client stream, similar
> to text/event-stream, except with binary frames supported. The difference
> being the lack of event IDs and Last-Event-ID header. In some cases it
> doesn't matter.
>
> * The POST method would be used to enable a bidirectional stream. But this
> implies that the client uses Content-Type: application/webstream in the
> request, along with the Accept header. Otherwise the server has no way to
> know what the request body will contain. Let content negotiation deal with
> both headers, it's already well defined.
>
> * Technically this would allow client->server and server->client streams
> to select and use a different sub-protocol. I'm not sure it's worth
> preventing this in the spec; instead let the servers decide if they want to
> allow this. But we probably need to mention it.
>
It's also possible to have a non-web-stream request with a web-stream
response (POST).


>
> * By the way, don't know if consistency is desirable, by maybe calling it
> application/web-stream is better. Maybe not.
>
Sounds good.


>
> * The HEAD method behaves as usual. The PUT method is probably not
> compatible with doing this. PATCH and DELETE are not compatible AFAIK.
>
Not sure why a PUT/PATCH request can't have a streamed body.  I don't think
we want to over-spec how to use HTTP with this media type (which is not the
only stream-able media type either)




>
> <snip>
>> Oh, interesting. Does this mean that on the browser a JSON codec that
>> takes / produces ArrayBuffers is used?
>>
>
> I have no idea about browsers, sorry. :-) Not dealing with them often. But
> as far as I understand it involves using a different type to get binaries,
> yes. I have no idea how this is done.
>
>     Which brings me to my question: do you think it could be worth
>>     adding a note to implementers that perhaps they should consider
>>     optionally disabling the UTF-8 check when JSON is expected for text
>>     frames?
>>
>>
>> We could have removed the valid UTF-8 requirement of RFC 6455. This is
>> something need to be enforced at the binding between the Web API and a
>> WebSocket protocol stack, but not at the protocol level.
>>
>> Until
>> https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00
>> <https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00>,
>> text frames had to be a valid UTF-8 (strictly speaking, data had to be
>> 0xFF-free), but not from the version 01.
>>
>> We can choose to omit the valid UTF-8 requirement from the WiSH spec and
>> instead have it in the spec for gluing WiSH with the WebSocket API in
>> the future. Then, server implementors won't be explicitly encouraged to
>> check validness when implementing WiSH.
>>
>
> That sounds like a good idea. I think it should still be mentioned in the
> protocol spec (basically explaining what you said and referring to another
> document) so that implementors are aware of the UTF-8 check and decide
> whether to implement it. If it was only written in a browser RFC I would
> most likely never have seen it, personally.
>
>
> --
> Loïc Hoguin
> https://ninenines.eu
>
>