idnits 2.17.1 draft-ietf-hybi-permessage-compression-04.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 (October 19, 2012) is 4206 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'LZ77' Summary: 1 error (**), 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 October 19, 2012 5 Expires: April 22, 2013 7 WebSocket Per-message Compression 8 draft-ietf-hybi-permessage-compression-04 10 Abstract 12 This specification defines a WebSocket extension that adds 13 compression functionality to the WebSocket Protocol. It compresses 14 the payload of non-control WebSocket messages using specified 15 compression algorithm. One reserved bit RSV1 in the WebSocket frame 16 header is allocated to control application of compression for each 17 message. This specification provides one compression method 18 available for the extension using DEFLATE. 20 Please send feedback to the hybi@ietf.org mailing list. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 22, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 4 58 3. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Negotiation Example . . . . . . . . . . . . . . . . . . . 6 60 4. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. DEFLATE method . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 8 65 5.1.1. Disallow compression context takeover . . . . . . . . 8 66 5.1.2. Limit maximum LZ77 sliding window size . . . . . . . . 9 67 5.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. Application Data Transformation . . . . . . . . . . . . . 10 69 5.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 10 70 5.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 11 71 5.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 14 73 5.4. Implementation Notes . . . . . . . . . . . . . . . . . . . 15 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 7.1. Registration of the "permessage-compress" WebSocket 77 Extension Name . . . . . . . . . . . . . . . . . . . . . . 17 78 7.2. Registration of the "Per-message Compressed" WebSocket 79 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 17 80 7.3. WebSocket Per-message Compression Method Name Registry . . 18 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 _This section is non-normative._ 91 As well as other communication protocols, the WebSocket Protocol 92 [RFC6455] can benefit from compression technology. This 93 specification defines a WebSocket extension that applies a 94 compression algorithm to octets exchanged over the WebSocket Protocol 95 using its extension framework. This extension negotiates what 96 compression method to use on opening handshake, and then compresses 97 the octets in non-control messages using the method. We can apply 98 this extension to various compression algorithms by specifying how to 99 negotiate parameters and transform payload. A client may offer 100 multiple compression methods on opening handshake, and then the 101 server chooses one from them. This extension uses the RSV1 bit of 102 the WebSocket frame header to indicate whether the message is 103 compressed or not, so that we can choose to skip messages with 104 incompressible contents without applying extra compression. 106 This specification provides one specific compression method "deflate" 107 which is based on DEFLATE [RFC1951] for this extension. We chose 108 DEFLATE since it's widely available as library on various platforms 109 and the overhead it adds for each chunk is small. To align the end 110 of compressed data to octet boundary, this method uses the algorithm 111 described in the Section 2.1 of the PPP Deflate Protocol [RFC1979]. 112 Endpoints can take over the LZ77 sliding window [LZ77] used to build 113 previous messages to get better compression ratio. For resource- 114 limited devices, method parameters to limit the usage of memory for 115 compression context are provided. 117 The simplest "Sec-WebSocket-Extensions" header in the client's 118 opening handshake to request DEFLATE based per-message compression is 119 the following: 121 Sec-WebSocket-Extensions: permessage-compress; method=deflate 123 The simplest header from the server to accept this extension is the 124 same. 126 2. Conformance Requirements 128 Everything in this specification except for sections explicitly 129 marked non-normative is normative. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Extension Negotiation 137 The registered extension token for this extension is 138 "permessage-compress". 140 To request use of the Per-message Compression Extension, a client 141 MUST include an element with the "permessage-compress" extension 142 token as its extension identifier in the "Sec-WebSocket-Extensions" 143 header in its opening handshake. The element MUST contain exactly 144 one extension parameter named "method". The value of the "method" 145 extension parameter is a list of compression method descriptions, 146 ordered by preference. Each compression method description has a 147 method name and optional method parameters. The grammar of the list 148 is "requested-method-list" defined in the following ABNFs. 150 requested-method-list = 1#method-desc 151 method-desc = method-name *(";" method-param) 152 method-name = token 153 method-param = token ["=" (token | quoted-string)] 155 The list MAY contain multiple method descriptions with the same 156 method name. 158 To accept use of the Per-message Compression Extension, a server MUST 159 choose one compression method description to accept from ones listed 160 by the client, and include an element with the "permessage-compress" 161 extension token in the "Sec-WebSocket-Extensions" header in its 162 opening handshake. The chosen description is called "accepted 163 request". The element in the server's "Sec-WebSocket-Extensions" 164 MUST contain exactly one extension parameter named "method". The 165 value of the "method" extension parameter MUST be a compression 166 method description. This description is called "method agreement". 167 The method name in the "method agreement" MUST be one of the accepted 168 request. The "method agreement" MUST be derived from the "accepted 169 request" and the server's capability. If the server doesn't support 170 any of the descriptions listed by the client, the server MUST reject 171 use of the Per-message Compression Extension. Its grammar is 172 "method-agreement" defined in the following ABNF. 174 method-agreement = method-desc 176 The value of the "method" parameter MUST be quoted by using 177 "quoted-string" syntax if it doesn't conform to token syntax. 179 If a client doesn't support the method and its configuration 180 specified by the "method agreement", the client MUST _Fail the 181 WebSocket Connection_. Otherwise, both endpoints MUST use the 182 algorithm described in Section 4 to exchange messages. 184 3.1. Negotiation Example 186 _This section is non-normative._ 188 These are "Sec-WebSocket-Extensions" header value examples that 189 negotiate the Per-message Compression Extension. 191 o Request foo method. Since foo matches token syntax, it doesn't 192 need to be quoted. 194 permessage-compress; method=foo 196 o Request foo method with a parameter x with 10 as its value. Since 197 the method parameter value contains a semicolon, it doesn't match 198 token syntax. Quotation is needed. 200 permessage-compress; method="foo; x=10" 202 o Request foo method and bar method. Since the method parameter 203 value contains a comma, it doesn't match token syntax. Quotation 204 is needed. 206 permessage-compress; method="foo, bar" 208 o Request foo method with a feature x but also allowing fallback to 209 one without the feature. 211 permessage-compress; method="foo; use_x, foo" 213 o Request foo method with parameter x with "Hello World" (quotation 214 for clarification) as its value and bar method. Since "Hello 215 World" contains a space, it needs to be quoted. Since quoted 216 "Hello World" contains double quotations and a space, it needs to 217 be quoted again. 219 permessage-compress; method="foo; x=\"Hello World\", bar" 221 4. Framing 223 This section describes how to apply the negotiated compression method 224 to the contents of WebSocket messages. 226 This extension allocates the RSV1 bit of the WebSocket header and 227 names it the "Per-message Compressed" bit. Any extension requiring 228 the use of the RSV1 bit is incompatible with this extension. This 229 bit MAY be set only on the first fragment of a message. This bit 230 indicates whether the compression method is applied to the message or 231 not. Messages with the "Per-message Compressed" bit set (on its 232 first fragment) are called "compressed messages". They have 233 compressed data in their payload. Messages with the bit unset are 234 called "uncompressed messages". They have uncompressed data in their 235 payload. 237 This extension MUST NOT be used after any extension for which frame 238 boundary needs to be preserved. This extension MUST NOT be used 239 after any extension that uses "Extension data" field or any of the 240 reserved bits on the WebSocket header as per-frame attribute. 242 This extension operates only on data frames. 244 4.1. Sending 246 To send a compressed message, an endpoint MUST use the following 247 algorithm. 249 1. Compress the payload of the message using the compression method. 251 2. Build frame(s) for the message by putting the resulting octets 252 instead of the original octets. 254 3. Set the "Per-message Compressed" bit of the first fragment to 1. 256 To send an uncompressed message, an endpoint MUST set the 257 "Per-message Compressed" bit of the first fragment of the message to 258 0. The payload of the message MUST be sent as-is without applying 259 the compression method. 261 4.2. Receiving 263 To receive a compressed message, an endpoint MUST decompress its 264 payload. 266 An endpoint MUST receive an uncompressed message as-is without 267 decompression. 269 5. DEFLATE method 271 This section defines a method named "deflate" for this extension that 272 compresses the payload of messages using DEFLATE [RFC1951] and byte 273 boundary alignment method introduced in [RFC1979]. 275 5.1. Method Parameters 277 The following 4 method parameters are defined for "deflate" method in 278 the following subsections. 280 o "s2c_no_context_takeover" 282 o "c2s_no_context_takeover" 284 o "s2c_max_window_bits" 286 o "c2s_max_window_bits" 288 A server MUST ignore "deflate" method descriptions that: 290 o have any method parameter unknown to the server 292 o have any method parameter with an invalid value 294 o is not supported by the server 296 A client MUST _Fail the WebSocket Connection_ if the "method 297 agreement": 299 o has any method parameter unknown to the client 301 o has any method parameter with an invalid value 303 o is not supported by the client 305 5.1.1. Disallow compression context takeover 307 A client MAY attach the "s2c_no_context_takeover" method parameter to 308 disallow the server to take over the LZ77 sliding window used to 309 build previous messages. Servers SHOULD be able to accept the 310 "s2c_no_context_takeover" method parameter. If the "accepted 311 request" has this method parameter, the server: 313 o MUST reset its LZ77 sliding window for sending to empty for each 314 message 316 o MUST attach this method parameter to its "method agreement" 318 A server MAY attach the "c2s_no_context_takeover" method parameter to 319 disallow the client to take over the LZ77 sliding window used to 320 build previous messages. Clients SHOULD be able to accept the 321 "c2s_no_context_takeover" method parameter. A client that received 322 this parameter MUST reset its LZ77 sliding window for sending to 323 empty for each message. 325 These parameters have no value. 327 5.1.2. Limit maximum LZ77 sliding window size 329 A client MAY attach the "s2c_max_window_bits" method parameter to 330 limit the LZ77 sliding window size that the server uses to build 331 messages. This parameter MUST have a decimal integer value in the 332 range between 8 to 15 indicating the base-2 logarithm of the LZ77 333 sliding window size. The ABNF [RFC5234] for the value of this 334 parameter is 1*DIGIT. Servers MAY be able to accept the 335 "s2c_max_window_bits" method parameter. If the "accepted request" 336 has this method parameter, the server: 338 o MUST attach this method parameter with the same value as one of 339 the "accepted request" to its "method agreement" 341 o MUST NOT use LZ77 sliding window size greater than the size 342 specified by this parameter to build messages 344 A client MAY attach the "c2s_max_window_bits" method parameter if the 345 client can adjust LZ77 sliding window size based on the 346 "c2s_max_window_bits" sent by the server. This parameter has no 347 value. 349 If the "accepted request" has the "c2s_max_window_bits" method 350 parameter, the server MAY attach the "c2s_max_window_bits" method 351 parameter to limit the LZ77 sliding window size that the client uses 352 to build messages. Otherwise, the server MUST NOT attach the 353 parameter. This parameter sent by the server MUST have a decimal 354 integer value in the range between 8 to 15 indicating the base-2 355 logarithm of the LZ77 sliding window size. The ABNF for the value of 356 this parameter is 1*DIGIT. A client that received this parameter 357 MUST NOT use LZ77 sliding window size greater than the size specified 358 by this parameter to build messages. 360 5.1.3. Example 362 _This section is non-normative._ 363 This example sent by a client is asking the server to use LZ77 364 sliding window size of 1,024 bytes or less and declaring that the 365 client can accept the "c2s_max_window_bits" parameter. 367 Sec-WebSocket-Extensions: permessage-compress; 368 method="deflate; c2s_max_window_bits; 369 s2c_max_window_bits=10" 371 This request might be rejected by the server because it doesn't 372 support the "s2c_max_window_bits" parameter. Since there's only one 373 method description listed in the header, the server need to give up 374 use of the Per-message Compression Extension entirely. If reduction 375 of LZ77 sliding window size by the server is mandatory for the 376 client, this is fine. 378 The next example lists two configurations so that the server can 379 accept permessage-compress by picking one of the configurations it 380 supports. 382 Sec-WebSocket-Extensions: permessage-compress; 383 method="deflate; s2c_max_window_bits=10, deflate" 385 The server can choose to accept the second description by sending 386 back this for example: 388 Sec-WebSocket-Extensions: permessage-compress; 389 method=deflate 391 Since the "c2s_max_window_bits" parameter was not specified for both 392 of the method descriptions, the server cannot use the 393 "c2s_max_window_bits" parameter. 395 5.2. Application Data Transformation 397 5.2.1. Compression 399 An endpoint MUST use the following algorithm to compress a message. 401 1. Compress all the octets of the payload of the message using 402 DEFLATE. 404 2. If the resulting data does not end with an empty block with no 405 compression ("BTYPE" set to 0), append an empty block with no 406 compression to the tail. 408 3. Remove 4 octets (that are 0x00 0x00 0xff 0xff) from the tail. 409 After this step, the last octet of the compressed data contains 410 the (part of) header bits with "BTYPE" set to 0. 412 In the first step: 414 o Multiple blocks MAY be used. 416 o Any type of block MAY be used. 418 o Both block with "BFINAL" set to 0 and 1 MAY be used. 420 o When any block with "BFINAL" set to 1 doesn't end at byte 421 boundary, minimal padding bits of 0 MUST be added to make it end 422 at byte boundary, and then the next block MUST start at the byte 423 boundary if any. 425 An endpoint MUST NOT use an LZ77 sliding window greater than 32,768 426 bytes to build messages to send. 428 If the "method agreement" has the "s2c_no_context_takeover" method 429 parameter, the server MUST reset its LZ77 sliding window for sending 430 to empty for each message. Otherwise, the server MAY take over the 431 LZ77 sliding window used to build the last compressed message. 433 If the "method agreement" has the "c2s_no_context_takeover" method 434 parameter, the client MUST reset its LZ77 sliding window for sending 435 to empty for each message. Otherwise, the client MAY take over the 436 LZ77 sliding window used to build the last compressed message. 438 If the "method agreement" has the "s2c_max_window_bits" method 439 parameter and its value is w, the server MUST NOT use an LZ77 sliding 440 window greater than w-th power of 2 bytes to build messages to send. 442 If the "method agreement" has the "c2s_max_window_bits" method 443 parameter and its value is w, the client MUST NOT use an LZ77 sliding 444 window greater than w-th power of 2 bytes to build messages to send. 446 5.2.2. Decompression 448 An endpoint MUST use the following algorithm to decompress a message. 450 1. Append 4 octets of 0x00 0x00 0xff 0xff to the tail of the payload 451 of the message. 453 2. Decompress the resulting octets using DEFLATE. 455 If the "method agreement" has the "s2c_no_context_takeover" method 456 parameter, the client MAY reset its LZ77 sliding window for receiving 457 to empty for each message. Otherwise, the client MUST take over the 458 LZ77 sliding window used to parse the last compressed message. 460 If the "method agreement" has the "c2s_no_context_takeover" method 461 parameter, the server MAY reset its LZ77 sliding window for receiving 462 to empty for each message. Otherwise, the server MUST take over the 463 LZ77 sliding window used to parse the last compressed message. 465 If the "method agreement" has the "s2c_max_window_bits" method 466 parameter and its value is w, the client MAY reduce the size of the 467 LZ77 sliding window to decompress received messages down to the w-th 468 power of 2 bytes. Otherwise, the client MUST use a 32,768 byte LZ77 469 sliding window to decompress received messages. 471 If the "method agreement" has the "c2s_max_window_bits" method 472 parameter and its value is w, the server MAY reduce the size of the 473 LZ77 sliding window to decompress received messages down to the w-th 474 power of 2 bytes. Otherwise, the server MUST use a 32,768 byte LZ77 475 sliding window to decompress received messages. 477 5.2.3. Examples 479 _This section is non-normative._ 481 This section introduces examples of how the DEFLATE method transforms 482 messages. 484 5.2.3.1. A message compressed using 1 compressed block 486 Suppose that a text message "Hello" is sent using the DEFLATE method. 487 When 1 compressed block (compressed with fixed Huffman code, "BFINAL" 488 is not set) is used, compressed data to be sent in payload is 489 obtained as follows. 491 Compress "Hello" into 1 compressed block and flush it into a byte 492 array using an empty block with no compression: 494 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 0x00 0xff 0xff 496 Strip 0x00 0x00 0xff 0xff from the tail: 498 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 500 To send it without fragmentation, just build a frame putting the 501 whole data in payload data: 503 0xc1 0x07 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 505 The first 2 octets are the WebSocket protocol's overhead (FIN=1, 506 RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7). 508 To send it after fragmentation, split the compressed payload and 509 build frames for each of split data as well as fragmentation process 510 done when the compression extension is not used. For example, the 511 first fragment may contain 3 octets of the payload: 513 0x41 0x03 0xf2 0x48 0xcd 515 and the second (last) fragment contain 4 octets of the payload: 517 0x80 0x04 0xc9 0xc9 0x07 0x00 519 Note that RSV1 is set only on the first fragment. 521 5.2.3.2. Sharing LZ77 Sliding Window 523 Suppose that the next message to send is also "Hello". If it's 524 disallowed by the other peer (using some extension parameter) to take 525 over the LZ77 sliding window used for the last message, the next 526 message is compressed into the same byte array (if the same "BTYPE" 527 and "BFINAL" value are used). If it's allowed, the next message can 528 be compressed into shorter payload: 530 0xf2 0x00 0x11 0x00 0x00 532 instead of: 534 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 536 Note that even if any uncompressed message is inserted between the 537 two "Hello" messages, it doesn't affect context sharing between the 538 two "Hello" messages. 540 5.2.3.3. Using a Block with No Compression 542 Blocks with no compression can be also used. A block with no 543 compression containing "Hello" flushed into a byte array using an 544 empty block with no compression is: 546 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 547 0x00 0x00 0xff 0xff 549 So, payload of a message containing "Hello" converted into a DEFLATE 550 block with no compression is: 552 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 554 If it's not fragmented, the frame for this message is: 556 0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 558 The first 2 octets are the WebSocket protocol's overhead (FIN=1, 559 RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7). Note 560 that RSV1 must be set for this message (only on the first fragment of 561 it) because RSV1 indicates whether DEFLATE is applied to the message 562 including use of blocks with no compression or not. 564 5.2.3.4. Using a Block with BFINAL Set to 1 566 On platform where the flush method based on an empty block with no 567 compression is not avaiable, implementors can choose to flush data 568 using blocks with "BFINAL" set to 1. Using a block with "BFINAL" set 569 to 1 and "BTYPE" set to 1, "Hello" is compressed into: 571 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 573 So, payload of a message containing "Hello" compressed using this 574 parameter setting is: 576 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 578 The last 1 octet contains the header bits with "BFINAL" set to 0 and 579 "BTYPE" set to 0, and 7 padding bits of 0. It's necessary to make 580 the payload able to be processed by the same manner as messages 581 flushed using blocks with BFINAL unset. 583 5.2.3.5. Two Blocks in 1 Message 585 Two or more blocks may be used in 1 message. 587 0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 0x00 589 The first 3 octets and the least significant two bits of the 4th 590 octet consist one block with "BFINAL" set to 0 and "BTYPE" set to 1 591 containing "He". The rest of the 4th octet contains the header bits 592 with "BFINAL" set to 0 and "BTYPE" set to 0, and the 3 padding bits 593 of 0. Together with the following 4 octets (0x00 0x00 0xff 0xff), 594 the header bits consist an empty block with no compression. Then, a 595 block containing "llo" follows. 597 5.3. Intermediaries 599 When intermediaries forward messages, they MAY decompress and/or 600 compress the messages according to the constraints negotiated during 601 the opening handshake of the connection(s). 603 5.4. Implementation Notes 605 _This section is non-normative._ 607 On most common software development platforms, the operation of 608 aligning compressed data to byte boundaries using an empty block with 609 no compression is available as a library. For example, Zlib [Zlib] 610 does this when "Z_SYNC_FLUSH" is passed to deflate function. 612 To get sufficient compression ratio, LZ77 sliding window size of 613 1,024 or more is recommended. 615 6. Security Considerations 617 There are no security concerns for now. 619 7. IANA Considerations 621 7.1. Registration of the "permessage-compress" WebSocket Extension Name 623 This section describes a WebSocket extension name registration in the 624 WebSocket Extension Name Registry [RFC6455]. 626 Extension Identifier 627 permessage-compress 629 Extension Common Name 630 WebSocket Per-message Compression 632 Extension Definition 633 This document. 635 Known Incompatible Extensions 636 None 638 The "permessage-compress" token is used in the 639 "Sec-WebSocket-Extensions" header in the WebSocket opening handshake 640 to negotiate use of the Per-message Compression Extension. 642 7.2. Registration of the "Per-message Compressed" WebSocket Framing 643 Header Bit 645 This section describes a WebSocket framing header bit registration in 646 the WebSocket Framing Header Bits Registry [RFC6455]. 648 Header Bit 649 RSV1 651 Common Name 652 Per-message Compressed 654 Meaning 655 The message is compressed or not. 657 Reference 658 Section 4 of this document. 660 The "Per-message Compressed" framing header bit is used on the first 661 fragment of non-control messages to indicate whether the payload of 662 the message is compressed by the Per-message Compression Extension or 663 not. 665 7.3. WebSocket Per-message Compression Method Name Registry 667 This specification creates a new IANA registry for names of 668 compression methods to be used with the WebSocket Per-message 669 Compression Extension in accordance with the principles set out in 670 [RFC5226]. 672 As part of this registry, IANA maintains the following information: 674 Method Identifier 675 The identifier of the method, as will be used in the method 676 description as defined Section 3 of this specification. The value 677 must conform to the method-name ABNF as defined in Section 3 of 678 this specification. 680 Method Common Name 681 The name of the method, as the method is generally referred to. 683 Method Definition 684 A reference to the document in which the method being used with 685 this extension is defined. 687 WebSocket Per-message Compression method names are to be subject to 688 the "First Come First Served" IANA registration policy [RFC5226]. 690 IANA has added initial values to the registry as follows. 692 +------------+-------------+---------------+ 693 | Identifier | Common Name | Definition | 694 +------------+-------------+---------------+ 695 | deflate | DEFLATE | This document | 696 +------------+-------------+---------------+ 698 8. Acknowledgements 700 Special thanks to Patrick McManus who wrote up the initial 701 specification of DEFLATE based compression extension for the 702 WebSocket Protocol to which I referred to write this specification. 704 9. References 706 9.1. Normative References 708 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 709 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 710 May 2008. 712 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 713 Specifications: ABNF", STD 68, RFC 5234, January 2008. 715 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 716 RFC 6455, December 2011. 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for 722 Sequential Data Compression", IEEE Transactions on 723 Information Theory, Vol. 23, No. 3, pp. 337-343. 725 9.2. Informative References 727 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 728 version 1.3", RFC 1951, May 1996. 730 [RFC1979] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996. 732 [Zlib] Gailly, J. and M. Adler, "Zlib", . 734 Author's Address 736 Takeshi Yoshino 737 Google, Inc. 739 Email: tyoshino@google.com