On 08.10.2014 20:42, [email protected] wrote: > > >> -----Original Message----- >> From: Standards [mailto:[email protected]] On Behalf Of Peter >> Saint-Andre - &yet >> Sent: Wednesday, October 08, 2014 12:15 PM >> To: [email protected] >> Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 >> >> On 10/8/14, 11:04 AM, [email protected] wrote: >>> Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames >>> must be of type text and contain UTF-8 encoded data. Was there some >>> reason for this since it makes XMPP stream compression not usable? >> >> Hi Dave, >> >> I think we'd recommend doing compression at the HTTP layer, just as for >> WebSocket we're doing security at the HTTP layer. >> >> Also, the spec has been approved for publication and is in the RFC Editor > queue >> so it's too late to change it: >> >> http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ >> >> And [email protected] is the right list for IETF specs. :-) >> >> Peter >> >> -- >> Peter Saint-Andre >> https://andyet.com/ > > Argh. No I don't take it back - all it is is a framework for creating > compression extensions. It doesn't actually define any specific mechanisms. >
I don't know what you found, but the latest approach for WebSocket compression within the hybi WG appears to be <https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression>. It provides a general framework for compression, and registers one specific extension using DEFLATE. The plan for XMPP over WS was indeed always to use such an extension for compression, if required. As no finished draft exists/existed it seems sensible that no reference to this was included. I generally think this is a concern of the WebSocket implementation, and not the XMPP mapping. Regards, Florian Zeitz
