Subject: [hybi] Straw poll: Do you miss per-frame extension? (was: Re: Discontinuation of mux ...)

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 19 Feb 2014 13:08:44 +0900

It seems we're using "RFC 6455 Semantics" with a bit different nuance. I'd
like to divide the discussion into more primitive questions.

Now, I want to ask you, "do you miss per-frame extensions?".

More generally, "do you want there to be boundaries inside a message that
will never be modified by multiplexing mechanism?"

Please respond to this thread with your answer and rationale.

FYI, the expired WebSocket dedicated mux spec
draft-ietf-hybi-websocket-multiplexing-11 DOES MODIFY frame boundaries.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 19 Feb 2014 13:11:29 +0900

My answer is "no, I don't". I think we should drop per-frame extension
capability. Even RFC 6455 should be updated to drop it when we get chance
to do so.

---

From: Adam Rice <[email-masked]>
Date: Wed, 19 Feb 2014 15:46:37 +0900

My answer is also "no, I would not miss per-frame extensions." Adding and
removing frame boundaries is useful when implementing intermediaries, and
needing a separate code path which preserved frame boundaries would be a
nuisance.

I also support the removal of this capability in the successor to RFC6455.

On 19 February 2014 13:11, Takeshi Yoshino <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Yutaka Hirano <[email-masked]>
Date: Wed, 19 Feb 2014 19:42:04 +0900

> Now, I want to ask you, "do you miss per-frame extensions?".

No.
I totally agree with Takeshi.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Feb 2014 11:33:13 -0800

I agree with Yutaka and Takeshi-- The world would be better without frame
extensions.

-=R

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 24 Feb 2014 20:03:11 +0900

> capability. Even RFC 6455 should be updated to drop it when we get chance

This would be my answer, too.

Regards,   Martin.