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: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 28 Oct 2016 17:59:30 +0900
Message-ID: <CAH9hSJb=mWdHP8xcBis8-jhWgQTfN-cgQXVV3eCyT4U8JYQHZA@mail.gmail.com>
To: Wenbo Zhu <wenboz@google.com>
Cc: Loïc Hoguin <essen@ninenines.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 09:00:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 October 2016 09:00:27 UTC