idnits 2.17.1 draft-tyoshino-hybi-websocket-perframe-deflate-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2012) is 4392 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'LZ77' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HyBi Working Group T. Yoshino 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track March 10, 2012 5 Expires: September 11, 2012 7 WebSocket Per-frame Compression 8 draft-tyoshino-hybi-websocket-perframe-deflate-06 10 Abstract 12 This specification defines a general per-frame compression scheme for 13 the WebSocket Protocol and one specific compression extension using 14 DEFLATE. This scheme compresses the "Application data" part of 15 WebSocket data frames using specified compression algorithm. 17 Please send feedback to the hybi@ietf.org mailing list. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 11, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 4 55 3. General Per-frame Compression Scheme . . . . . . . . . . . . . 5 56 3.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Per-frame DEFLATE Extension . . . . . . . . . . . . . . . . . 6 59 4.1. Extension Negotiation . . . . . . . . . . . . . . . . . . 6 60 4.2. Application Data Transformation . . . . . . . . . . . . . 6 61 4.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 7 62 4.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 7 63 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. Implementation Note . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. Registration of the "deflate-frame" WebSocket 68 Extension Name . . . . . . . . . . . . . . . . . . . . . . 10 69 6.2. Registration of the "Per-frame compressed" WebSocket 70 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 10 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 _This section is non-normative._ 81 As well as other protocols, octets exchanged over the WebSocket 82 Protocol [RFC6455] can benefit from compression technology. This 83 specification introduces a scheme to apply compression algorithms to 84 the WebSocket Protocol, and then adds DEFLATE [RFC1951] based 85 compression functionality to the WebSocket Protocol using its 86 extension framework. 88 The per-frame compression scheme applies the specified compression 89 algorithm to the octets in the "Application data" part of data 90 frames. It specifies the use of the RSV1 bit of the WebSocket 91 framing to indicate whether any compression is applied to the frame 92 or not, so that we can choose to skip compression for frames with 93 incompressible contents. By specifying extension negotiation and how 94 to transform octets in "Application data", we can define per-frame 95 compression extensions for various compression algorithms based on 96 this scheme. 98 The specific extension we introduce in this specification by applying 99 DEFLATE to the scheme is called "Per-frame DEFLATE extension". To 100 align the end of compressed data to octet boundary, the extension 101 uses the algorithm described in the Section 2.1 of the PPP Deflate 102 Protocol [RFC1979]. Endpoints can take over the LZ77 sliding window 103 [LZ77] used to build previous frames to get better compression ratio. 105 The simplest "Sec-WebSocket-Extensions" header in the client's 106 opening handshake to request per-frame DEFLATE extension is the 107 following: 109 Sec-WebSocket-Extensions: deflate-frame 111 The simplest header from the server to accept this extension is the 112 same. 114 2. Conformance Requirements 116 Everything in this specification except for sections explicitly 117 marked non-normative is normative. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. General Per-frame Compression Scheme 125 This section describes a general scheme to apply a compression 126 algorithm to the contents of WebSocket frames. Any other compression 127 extension specifications MAY apply their compression algorithm to 128 this scheme to define extensions. 130 This scheme allocates one bit field called "Per-frame compressed" at 131 the RSV1 bit. This bit indicates whether any kind of per-frame 132 compression is applied to the frame or not. 134 This scheme operates only on data frames, and only on the 135 "Application data" therein (it does not affect the "Extension data" 136 portion of the "Payload data"). 138 3.1. Sending 140 To send a frame with the compression applied, an endpoint MUST use 141 the following algorithm. 143 1. Apply the compression to the "Application data" portion of the 144 frame. 146 2. Build a frame by putting the resulting octets in the "Application 147 data" portion instead of the original octets. The payload length 148 field of the frame MUST be the sum of the size of the "Extension 149 data" portion and one of these resulting octets. "Per-frame 150 compressed" bit MUST be set to 1. 152 To send a frame with the compression not applied, an endpoint MUST 153 set "Per-frame compressed" bit of the frame to 0. 155 3.2. Receiving 157 To receive a frame with "Per-frame compressed" bit set to 1, an 158 endpoint MUST decompress the octets in the "Application data" portion 159 based on the compression algorithm. 161 An endpoint MUST receive a frame with "Per-frame compressed" bit set 162 to 0 as-is without any compression processing. 164 4. Per-frame DEFLATE Extension 166 4.1. Extension Negotiation 168 The registered extension token for this extension is "deflate-frame". 170 To request use of per-frame DEFLATE extension, a client MUST include 171 the "deflate-frame" extension token in the "Sec-WebSocket-Extensions" 172 header in its opening handshake. 174 To accept use of per-frame DEFLATE extension requested by the client, 175 a server MUST include the "deflate-frame" extension token in the 176 "Sec-WebSocket-Extensions" header in its opening handshake. 178 An endpoint MAY attach one or more extension parameters as defined 179 below to the extension token. 181 Maximum LZ77 sliding window size 182 An endpoint MAY attach "max_window_bits" extension parameter to 183 limit the LZ77 sliding window size that the other peer uses to 184 build frames. This parameter MUST have an integer value in the 185 range between 8 to 15 indicating the base-2 logarithm of the LZ77 186 sliding window size. An endpoint that received this parameter 187 MUST NOT use LZ77 sliding window size greater than this value to 188 build frames. 190 Disallow compression context takeover 191 An endpoint MAY attach "no_context_takeover" extension parameter 192 to disallow the other peer to take over the LZ77 sliding window 193 used to build previous frames. This parameter has no value. An 194 endpoint that received this parameter MUST use an empty LZ77 195 sliding window to build every frame. 197 A server MUST ignore any unknown extension parameter attached to 198 "deflate-frame" extension token in the client's opening handshake. 200 A client MUST _Fail the WebSocket Connection_ if any unknown 201 extension parameter is attached to "deflate-frame" extension token in 202 the server's opening handshake. 204 Once per-frame DEFLATE extension is accepted, both endpoints MUST use 205 the algorithm described in Section 4.2 to exchange frames. 207 4.2. Application Data Transformation 209 This extension transforms the "Application data" portion by using the 210 scheme described in Section 3 with DEFLATE as follows. 212 4.2.1. Compression 214 An endpoint MUST use the following algorithm to compress the 215 "Application data" portion. 217 1. Apply DEFLATE [RFC1951] to all the octets. Multiple blocks MAY 218 be used. Any type of block MAY be used. Both block with 219 "BFINAL" set to 0 and 1 MAY be used. 221 2. If the resulting data does not end with an empty block with no 222 compression ("BTYPE" set to 0), append an empty block with no 223 compression to the tail. 225 3. Remove 4 octets (that are 0x00 0x00 0xff 0xff) from the tail. 227 An endpoint MUST NOT use LZ77 sliding window size greater than 32,768 228 to build frames. 230 If an endpoint received the "max_window_bits" extension parameter on 231 opening handshake, it MUST NOT use LZ77 sliding window size greater 232 than the "max_window_bits"-th power of 2 to build frames. 234 Unless it's prohibited by the other peer by the "no_context_takeover" 235 extension parameter on opening handshake, an endpoint MAY take over 236 the LZ77 sliding window used to build the last frame with DEFLATE 237 applied. 239 4.2.2. Decompression 241 An endpoint MUST use the following algorithm to decompress the 242 "Application data" portion. 244 1. Append 4 octets of 0x00 0x00 0xff 0xff to the tail. 246 2. Decompress the resulting octets using DEFLATE. 248 Unless an endpoint sent the "max_window_bits" extension parameter on 249 opening handshake, the endpoint MUST use 32,768 byte LZ77 sliding 250 window to decode frames. 252 If an endpoint sent the "max_window_bits" extension parameter on 253 opening handshake, it MAY reduce LZ77 sliding window size down to the 254 "max_window_bits"-th power of 2 to decode frames. 256 Unless the endpoint sent the "no_context_takeover" extension 257 parameter on opening handshake, an endpoint MUST take over the LZ77 258 sliding window used to decode the last frame with DEFLATE applied. 260 4.2.3. Examples 262 _This section is non-normative._ 264 These are examples of resulting data after applying the algorithm 265 above. 267 o "Hello" in one compressed block 269 * 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 271 "Hello" in one compressed block in the next frame 273 * 0xf2 0x00 0x11 0x00 0x00 275 o "Hello" in one block with no compression 277 * 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 279 o "Hello" in one block with "BFINAL" set to 1 281 * 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 283 o "He" and "llo" in separate blocks 285 * 0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 286 0x00 288 4.3. Implementation Note 290 _This section is non-normative._ 292 On common software development platforms, the operation of aligning 293 compressed data to octet boundary using an empty block with no 294 compression is available as library. For example, Zlib [Zlib] does 295 this when "Z_SYNC_FLUSH" is passed to deflate function. 297 To get sufficient compression ratio, LZ77 sliding window size of 298 1,024 or more is recommended. 300 5. Security Considerations 302 There's no security concern for now. 304 6. IANA Considerations 306 6.1. Registration of the "deflate-frame" WebSocket Extension Name 308 This section describes a WebSocket extension name registration in the 309 WebSocket Extension Name Registry. [RFC6455]. 311 Extension Identifier 312 deflate-frame 314 Extension Common Name 315 WebSocket Per-frame DEFLATE 317 Extension Definition 318 Section 4.1 and Section 4.2 of this document. 320 Known Incompatible Extensions 321 None 323 The "deflate-frame" token is used in the "Sec-WebSocket-Extensions" 324 header in the WebSocket opening handshake to negotiate use of per- 325 frame DEFLATE compression extension. 327 6.2. Registration of the "Per-frame compressed" WebSocket Framing 328 Header Bit 330 This section describes a WebSocket framing header bit registration in 331 the WebSocket Framing Header Bits Registry. [RFC6455] 333 Header Bit 334 RSV1 336 Common Name 337 Per-frame compressed 339 Meaning 340 Compression is applied to the frame or not. 342 Reference 343 Section 3 of this document. 345 The "Per-frame compressed" framing header bit is used to indicate 346 whether any negotiated per-frame compression extension applied 347 compression to the "Application data" portion of the frame or not. 349 7. Acknowledgements 351 Special thanks to Patrick McManus who wrote up the initial 352 specification of DEFLATE based compression extension for the 353 WebSocket Protocol which I referred to write this specification. 355 8. References 357 8.1. Normative References 359 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 360 RFC 6455, December 2011. 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for 366 Sequential Data Compression", IEEE Transactions on 367 Information Theory, Vol. 23, No. 3, pp. 337-343. 369 8.2. Informative References 371 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 372 version 1.3", RFC 1951, May 1996. 374 [RFC1979] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996. 376 [Zlib] Gailly, J. and M. Adler, "Zlib", . 378 Author's Address 380 Takeshi Yoshino 381 Google, Inc. 383 Email: tyoshino@google.com