Re: [hybi] deflate-stream and masking

Whereas, I really believe it shouldn't.   (But not enough to delay
realization of WS)

TCP doesn't have compression.  HTTP does.    TCP is a transport layer.  HTTP
is an application layer.   Websockets is transport layer.  Et voila, my
reasoning.

I've always understood WS as a protocol that defines how content is
exchanged asynchronously between "web" peers.   It is a framing mechanism
for TCP.   It is not an application layer (it doesn't define "verbs", like
GET, POST, HEAD, etc.).    Transport layers should be content agnostic.
Compression is a function of that which uses the transport layer (ie.
application layer).    But, I've said this before, and there is no reason
to belabor the point.

If I have to implement the extension as a mandatory component, I'll be
pissed off, but I'll do it.   My needs for a non-XHR kludge to get async
communication out-weighs my distaste for the extension.  I understand other
peoples needs may differ from mine.

On Wed, Jul 20, 2011 at 4:04 PM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> I really believe the base spec must have a compression definition.
>
> The point of my message was that the W3C editor's draft should not turn
> into a change in direction on compression on our part because the scope
> of that issue is much greater.
>
> On Wed, 2011-07-20 at 20:00 +0000, Gabriel Montenegro wrote:
> > <As individual>
> >
> > That is my reading as well.
> >
> > <as chair>
> >
> > Patrick, would you be able to own that separate spec?
> >
> > > -----Original Message-----
> > > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf
> Of
> > > Peter Saint-Andre
> > > Sent: Wednesday, July 20, 2011 12:49
> > > To: Patrick McManus
> > > Cc: Hybi
> > > Subject: Re: [hybi] deflate-stream and masking
> > >
> > > <hat type='individual'/>
> > >
> > > On 7/20/11 1:43 PM, Patrick McManus wrote:
> > >
> > > > As for compression, the most productive thing to do seems to me to be
> > > > to define in a separate draft deflate-frame and push it through the
> > > > adoption/standardization process. No matter what is defined the
> > > > extensions mechanism should (and does!) provide a mechanism for
> > > > migration for any sensible protocol implementations.
> > > >
> > > > While I don't want to go to the mat for deflate-stream it certainly
> > > > has a number of use cases where it does well - most downstream
> traffic
> > > > of> tiny-sized messages, and large upstream messages - so I'm not in
> > > > the camp of "just throw it out".
> > >
> > > My reading of the discussion is that people don't necessarily want to
> throw out
> > > deflate-stream, but they don't think it belongs in the base spec and
> they would
> > > prefer to see it defined in a separate draft, just as you propose for
> deflate-frame.
> > >
> > > Peter
> > >
> > > --
> > > Peter Saint-Andre
> > > https://stpeter.im/
> > >
> > >
> > > _______________________________________________
> > > hybi mailing list
> > > hybi@ietf.org
> > > https://www.ietf.org/mailman/listinfo/hybi
> >
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>