Subject: Re: [hybi] Impacts of mux and compression extension on the WebSocket API (was: Re: MUC: channel ID semantics)

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 19 Apr 2012 04:12:30 +0000

_Extensions In Use_ does not seem like a *new* requirement, as it was already spelled out in RFC6455 and included in the API:

The _Extensions In Use_
   is defined to be a (possibly empty) string, the value of which is
   equal to the value of the |Sec-WebSocket-Extensions| header field
   supplied by the server's handshake or the null value if that header
   field was not present in the server's handshake.

And in the API at http://www.w3.org/TR/websockets/ it is:
readonly attribute DOMString extensions<http://www.w3.org/TR/websockets/#dom-websocket-extensions>;

The protocol also defines the format (“equal to the value of the |Sec-Websocket-Extensions| header field” whose ABNF is defined in RFC6455. Or are you referring to something else?

From: John Tamplin [mailto:[email-masked]]
Sent: Thursday, 29 March, 2012 8:56
To: Takeshi Yoshino
Cc: Gabriel Montenegro; [email-masked]
Subject: Re: Impacts of mux and compression extension on the WebSocket API (was: Re: [hybi] MUC: channel ID semantics)

On Thu, Mar 29, 2012 at 3:34 AM, Takeshi Yoshino <[email-masked]<mailto:[email-masked]>> wrote:
Not the issue discussed in the f2f meeting, but I'm sure that introduction of extensions we're now working on impacts extensions attribute of the WebSocket API.

1. the API must define in what form it exports _Extensions In Use_. What to include (just token? parameters together?), formatting, etc.

Ah, I wasn't aware they added that.  Making WeSocket.extensions be a DOMString seems like a poor idea, as you now have to encode the list of extensions (possibly with their parameters) into a string, and the JS will have to decode it.  It seems making it return a list of objects with defined properties would be much better.

2. under use of the multiplexing extension, Sec-WebSocket-Extensions header will contain both extensions applied to physical channel and logical channels. We must figure out what should be exported from this mixture and which side should do such transformation if any by coordinating with webapps WG.

Since the WebSocket object in the browser may be a physical or logical channel and applications shouldn't know the difference, it seems to me that the extensions have to be that of the logical channel in the mux case.

--
John A. Tamplin
Software Engineer (GWT), Google

---

From: John Tamplin <[email-masked]>
Date: Thu, 19 Apr 2012 00:14:27 -0400

On Thu, Apr 19, 2012 at 12:12 AM, Gabriel Montenegro <
[email-masked]> wrote:

>  _*Extensions In Use*_ does not seem like a **new** requirement, as it
> was already spelled out in RFC6455 and included in the API:
>

To clarify - I meant "added since I last looked closely at the spec under
development".

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 24 Apr 2012 16:46:06 +0000

+Thomas, w3c liaison.

Based on the thread on the mailing list and after discussion with Salvatore, the chairs do not see any new requirements for the WebSocket API at this point.

Thanks,

Gabriel

From: John Tamplin [mailto:[email-masked]]
Sent: Wednesday, 18 April, 2012 21:14
To: Gabriel Montenegro
Cc: Takeshi Yoshino; [email-masked]
Subject: Re: Impacts of mux and compression extension on the WebSocket API (was: Re: [hybi] MUC: channel ID semantics)

On Thu, Apr 19, 2012 at 12:12 AM, Gabriel Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
_Extensions In Use_ does not seem like a *new* requirement, as it was already spelled out in RFC6455 and included in the API:

To clarify - I meant "added since I last looked closely at the spec under development".