W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Costin Manolache <costin@gmail.com>
Date: Fri, 28 Oct 2016 16:25:24 +0000
Message-ID: <CAP8-FqnLaRvyQgXXkoNQPKcyMhv-O3RN67CMw5L_-1iQ9c6mhw@mail.gmail.com>
To: Takeshi Yoshino <tyoshino@google.com>, Wenbo Zhu <wenboz@google.com>
Cc: Loïc Hoguin <essen@ninenines.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
I think WiSH could be great as a fallback to the webpush protocol push
promises, in devices
that don't fully support http/2, and for webpush delivery receipts.

In the context of IoT: since continuation is available, any reason to
support 64-bit-length frames ?
Even 32 bit ( 4G ) frames may be unpractical.  I don't know how common this
int encoding scheme
is - but using varint or fixed may be easier to handle.

Costin

On Fri, Oct 28, 2016 at 2:06 AM Takeshi Yoshino <tyoshino@google.com> wrote:

> On Fri, Oct 28, 2016 at 10:13 AM, Wenbo Zhu <wenboz@google.com> wrote:
>
>
>
> On Tue, Oct 25, 2016 at 2:08 AM, Loïc Hoguin <essen@ninenines.eu> wrote:
>
> On 10/25/2016 11:54 AM, Takeshi Yoshino wrote:
>
> <snip>
> Oh, sorry for being unclear. I meant that we'll use
> "application/subprotocol+webstream". I.e. introducing +webstream as a
> new media type suffix.
>
>
> Ah!
>
> OK I have no problem with that.
>
>
> is it true only registered suffixes are allowed, e.g. json, xml etc?
>
>
> Did you mean the prefix?
>
>
>
> application/webstream; protocol=...  seems more legit and most
> subprotocols are not registered media types either..
>
>
> I skimmed RFC 6838. I think application/xxx+suffix would be subject to the
> same rule for general rule for media types even if +suffix is registered.
>
> We can choose to put the protocol parameter under control of IANA, but
> yes, we'll have options to decide whether we make it so or not.
>
>
> Re: the actual parameter "protocol", we may want to mention it similar to
> utf-8 checking, as a future concern for providing websocket compatibility.
>
>
> I'm adding a section about that. For WebSocket compatibility, its value
> should follow the token ABNF.
>
>
>
>
>
>
> <snip>
>     * By the way, don't know if consistency is desirable, by maybe
>     calling it application/web-stream is better. Maybe not.
>
>
> Could you please elaborate the proposal?
>
>
> I mean there's already text/event-stream, so application/webstream is not
> consistent with it (missing the dash). But maybe it doesn't matter.
>
>     * The HEAD method behaves as usual. The PUT method is probably not
>     compatible with doing this. PATCH and DELETE are not compatible AFAIK.
>
>
> I'm feeling that we should just limit the scope of the proposal to GET
> and POST.
>
>
> Sounds good to me.
>
> Thanks for the great work! I look forward to implementing this.
>
>
> --
> Loïc Hoguin
> https://ninenines.eu
>
>
>
Received on Friday, 28 October 2016 16:26:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 October 2016 16:26:10 UTC