Subject: WebSocket over HTTP2 RFC6455 conformance

From: Yutaka Hirano <[email-masked]>
Date: Wed, 19 Feb 2014 23:11:29 +0900

Hi,

I once proposed to decide whether we should preserve the RFC6455 semantics
or not at hybi[1].
I would like to propose it again here.
Please see[1] for the proposal.

At hybi, the following people answered "yes & yes".

   - Tobias
   - Takeshi
   - Joakim
   - Peter
   - Salvatore
   - me

I think Roberto answered "yes & no", is that correct? > Roberto

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg10403.html

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Feb 2014 12:59:57 -0800

> At hybi, the following people answered "yes & yes".

When you ask about semantics, you need to be more precise.

My interpretation of "Websocket semantics" is the set of things that
you can do with thewebsocketprotocol, or maybe the W3C WebSocket API.
If your intent is to tunnel the protocol in a completely lossless
fashion, then you are asking for more than just a preservation of
semantics, you also want to preserve syntax.

Note that we preserve syntax in HTTP/2 because there is a wealth of
usage out there that relies on syntax, and even if we might think it
unwise to do so, we are still unwilling to break those users.  It
might be that the hybi group has people using those reserved bits such
that preserving them is paramount, but websockets has far less history
than HTTP.  I also didn't find the framing of the question or the
responses to be particularly convincing.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 20 Feb 2014 14:16:23 +0900

> When you ask about semantics, you need to be more precise.

Good point, Martin. Here're HyBi threads started recently and calling for
opinions for smaller primitive questions.

Is it important to know frame length at the start of frame?
http://www.ietf.org/mail-archive/web/hybi/current/msg10404.html

Straw poll: Do you miss per-frame extension?
http://www.ietf.org/mail-archive/web/hybi/current/msg10448.html

Straw poll: Do you miss interjectable WebSocket level control frame?
http://www.ietf.org/mail-archive/web/hybi/current/msg10450.html

> semantics, you also want to preserve syntax.

Yutaka didn't mean to include syntax (I believe you meant binary
serialization), but preserving frame boundary, etc.

> responses to be particularly convincing.

We're not pushing HyBi's decision but want to ask httpbis people's opinions
as well. Sorry if you felt like that.

So, you're also not interested in preserving RSV1-3 as-is even as
per-message basis?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Feb 2014 21:26:37 -0800

> So, you're also not interested in preserving RSV1-3 as-is even as

I'm more interested in the semantics (what I described), than the
protocol itself.  The protocol in RFC 6455 is just one expression of
those semantics.  I believe that an alternative expression of the
semantics can be found that is more suited to it's environment (in
this case HTTP/2).

This doesn't mean that what RSV1-3 represent (extensibility) is not
expressed.  But the idea that you need to meticulously preserve the
protocol, while perhaps intuitive to some, to me is a little
repugnant.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 20 Feb 2014 14:52:00 +0900

> protocol, while perhaps intuitive to some, to me is a little

Sorry to be unclear. "As-is" in my comment was bad. I'm also talking about
semantics. The fact "there're 3 booleans associated with each message"
surfaces what kind of semantics can be layered over the protocol. So people
at HyBi would be worried about that and ask for "preserve RSV1-3". It's
possible some of them are missing "RSV1-3 as 1 bit occupation in baseband
for the same efficiency as RFC6455", but me and the rest are just talking
about semantics I think.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 20 Feb 2014 14:57:15 +0900

> for the same efficiency as RFC6455", but me and the rest are just talking

Also, reusing the identifier "RSV1-3" we now have in RFC6455 for those
booleans (not pointing syntax. not pointing 1 bit serialization. but
semantics) eases writing extensions that work for both RFC6455 and
WS/HTTP/2.0. This is not-so-important but another concern Yutaka and HyBi
people should have.

Anyway, your point that we should be careful when using a term "semantics"
totally makes sense.

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 20 Feb 2014 15:06:11 +0900

>
> I'm more interested in the semantics (what I described), than the protocol
> itself.

My understanding is that no one want to break the W3C WebSocket API, do you?

> The protocol in RFC 6455 is just one expression of those semantics.

Yes, I think so, and I want to discuss what the best protocol for the
WebSocket API is.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Feb 2014 09:11:21 -0800

> WS/HTTP/2.0. This is not-so-important but another concern Yutaka and HyBi

I don't consider those booleans to be part of the websocket semantics.
 They certainly don't surface at the API level.

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 21 Feb 2014 12:33:39 +0900

>  They certainly don't surface at the API level.

I wanted to talk about minor editorial merit in that paragraph. If we adopt
different ways (identifiers) to attach boolean info to messages which
implement a certain extension, people writing the spec for the extension
for both WS/HTTP/2.0 and RFC6455 need to write algorithm for both. I.e.
- [WS/HTTP/2.0] Include "compressed" field with value of "1" in HEADERS
- [RFC6455] Set RSV1 bit
As I said in the original post, this is not-so-important.

---

From: Yutaka Hirano <[email-masked]>
Date: Fri, 21 Feb 2014 14:44:24 +0900

Martin, is your answer "yes & no"?
All "semantics" words in my proposal are qualified as "the RFC6455
semantics" and it's not your "Websocket semantics".

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 27 Feb 2014 00:46:41 +0900

I wanted to get an agreement on this topic, but it may be difficult.
OK, I am writing another rough draft[1] which is not based on RFC6455
WebSocket frame.
It encodes a WebSocket message to HEADERS + DATAs, there is no message
injection and there is no WebSocket frame.
It may have extensions, but they will be incompatible with RFC6455
extensions.

Martin, Roberto, Is that what you want?

[1]:
https://github.com/yutakahirano/ws-over-http2/blob/master/ws-over-http2-message-mapping.md

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Feb 2014 08:53:28 -0800

> https://github.com/yutakahirano/ws-over-http2/blob/master/ws-over-http2-message-mapping.md

Much better.  I think that your close needs to be reciprocal
END_STREAM flags, but other than that, you have what you need right
there.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 26 Feb 2014 12:35:17 -0800

I like what I see.
-=R

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 27 Feb 2014 06:51:17 +0000

I think that the most important think is to preserve the WebSocket semantic
(that is something that we can quite correctly summarise as what is in W3C WebSocket API, even if
maybe there is something else that people want also to preserve but that is not in the API )
while I don't care about the syntax and we should not really care about it.

the Yutaka proposal is really a good step forward, really clean proposal

/Salvatore

On Feb 26, 2014, at 10:35 PM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:

I like what I see.
-=R

On Wed, Feb 26, 2014 at 8:53 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote: