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

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
>
>
>