draft-ietf-hybi-permessage-compression-11.txt   draft-ietf-hybi-permessage-compression-12.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track July 1, 2013 Intended status: Standards Track July 29, 2013
Expires: January 2, 2014 Expires: January 30, 2014
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-11 draft-ietf-hybi-permessage-compression-12
Abstract Abstract
This document specifies a framework for creating WebSocket extensions This document specifies a framework for creating WebSocket extensions
that add compression functionality to the WebSocket Protocol. An that add compression functionality to the WebSocket Protocol. An
extension based on this framework compresses the payload data portion extension based on this framework compresses the payload data portion
of non-control WebSocket messages on a per-message basis using of non-control WebSocket messages on a per-message basis using
parameters negotiated during the opening handshake. This framework parameters negotiated during the opening handshake. This framework
provides a general method to apply a compression algorithm to the provides a general method to apply a compression algorithm to the
contents of WebSocket messages. For each compression algorithm, an contents of WebSocket messages. For each compression algorithm, an
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current. Drafts is at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2014. This Internet-Draft will expire on January 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7 5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7
5.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . 8 5.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . 8
6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 10
7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 12
8. permessage-deflate extension . . . . . . . . . . . . . . . . . 13 8. permessage-deflate extension . . . . . . . . . . . . . . . . . 13
8.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 14 8.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 14
8.1.1. Context Takeover Control . . . . . . . . . . . . . . . 14 8.1.1. Context Takeover Control . . . . . . . . . . . . . . . 14
8.1.2. Limiting the LZ77 sliding window size . . . . . . . . 15 8.1.2. Limiting the LZ77 sliding window size . . . . . . . . 15
8.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16 8.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Message Payload Transformation . . . . . . . . . . . . . . 17 8.2. Message Payload Transformation . . . . . . . . . . . . . . 18
8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 17 8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 18
8.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 18 8.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 19
8.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 19 8.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 20
8.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 22 8.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 23
8.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 22 8.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Registration of the "permessage-deflate" WebSocket 10.1. Registration of the "permessage-deflate" WebSocket
Extension Name . . . . . . . . . . . . . . . . . . . . . . 24 Extension Name . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Registration of the "Per-message Compressed" WebSocket 10.2. Registration of the "Per-message Compressed" WebSocket
Framing Header Bit . . . . . . . . . . . . . . . . . . . . 24 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document specifies a framework to add compression functionality This document specifies a framework to add compression functionality
to the WebSocket Protocol [RFC6455]. This framework specifies how to to the WebSocket Protocol [RFC6455]. This framework specifies how to
define WebSocket Per-message Compression Extensions (PMCEs) define WebSocket Per-message Compression Extensions (PMCEs)
individually for various compression algorithms based on the individually for various compression algorithms based on the
extension concept of the WebSocket Protocol specified in Section 9 of extension concept of the WebSocket Protocol specified in Section 9 of
[RFC6455]. A WebSocket client and a peer WebSocket server negotiate [RFC6455]. A WebSocket client and a peer WebSocket server negotiate
use of a PMCE and determine parameters to configure the compression use of a PMCE and determine parameters to configure the compression
skipping to change at page 15, line 9 skipping to change at page 15, line 9
"s2c_no_context_takeover" extension parameter. "s2c_no_context_takeover" extension parameter.
A server MAY include the "s2c_no_context_takeover" extension A server MAY include the "s2c_no_context_takeover" extension
parameter in a response even if the offer to accept by the response parameter in a response even if the offer to accept by the response
doesn't have "s2c_no_context_takeover" extension parameter. doesn't have "s2c_no_context_takeover" extension parameter.
8.1.1.2. c2s_no_context_takeover 8.1.1.2. c2s_no_context_takeover
A client MAY include the "c2s_no_context_takeover" extension A client MAY include the "c2s_no_context_takeover" extension
parameter in an offer. This parameter has no value. Using this parameter in an offer. This parameter has no value. Using this
parameter, a client tells the peer server a hint that the client is parameter, a client tells the peer server a hint that even if the
not likely to use the same LZ77 sliding window it used to build server doesn't send the "c2s_no_context_takeover" extension
frames of the last sent message to build frames of the next message. parameter, the client is not going to use the same LZ77 sliding
window it used to build frames of the last sent message to build
frames of the next message.
A server MAY include the "c2s_no_context_takeover" extension A server MAY include the "c2s_no_context_takeover" extension
parameter in a response. This parameter has no value. Using this parameter in a response. If the received offer has the
"c2s_no_context_takeover" extension parameter, the server may either
ignore it or use it to avoid taking over an LZ77 sliding window
unnecessarily by specifying "c2s_no_context_takeover" extension
parameter in the response. This parameter has no value. Using this
parameter, a server prevents the peer client from using the same LZ77 parameter, a server prevents the peer client from using the same LZ77
sliding window it used to build frames of the last sent message to sliding window it used to build frames of the last sent message to
build frames for the next message. This reduces the amount of memory build frames for the next message. This reduces the amount of memory
that the server has to reserve for the connection, in the same way that the server has to reserve for the connection, in the same way
the "s2c_no_context_takeover" extension parameter does for the the "s2c_no_context_takeover" extension parameter does for the
client. client.
A client MUST support server-to-client "c2s_no_context_takeover" A client MUST support server-to-client "c2s_no_context_takeover"
extension parameter. extension parameter.
skipping to change at page 16, line 18 skipping to change at page 16, line 23
8.1.2.2. c2s_max_window_bits 8.1.2.2. c2s_max_window_bits
A client MAY include the "c2s_max_window_bits" extension parameter in A client MAY include the "c2s_max_window_bits" extension parameter in
an offer. This parameter has no value or a decimal integer value an offer. This parameter has no value or a decimal integer value
without leading zeroes between 8 to 15 inclusive indicating the without leading zeroes between 8 to 15 inclusive indicating the
base-2 logarithm of the LZ77 sliding window size. Using this base-2 logarithm of the LZ77 sliding window size. Using this
parameter, a client tells the peer server that the client supports parameter, a client tells the peer server that the client supports
the server-to-client "c2s_max_window_bits" extension parameter. If the server-to-client "c2s_max_window_bits" extension parameter. If
the parameter has a value, the parameter also tells the peer server a the parameter has a value, the parameter also tells the peer server a
hint that the client is not likely to use LZ77 sliding window size hint that even if the server sends the "c2s_max_window_bits"
greater than the size specified by the value to compress messages. extension parameter with a bigger value or doesn't send it at all,
the client is not going to use LZ77 sliding window size greater than
the size specified by the value to compress messages.
If a received offer has the "c2s_max_window_bits" extension If a received offer has the "c2s_max_window_bits" extension
parameter, the server MAY include the "c2s_max_window_bits" parameter parameter, the server MAY include the "c2s_max_window_bits" extension
in the response to the offer. This server-to-client parameter has a parameter in the response to the offer. If the "c2s_max_window_bits"
decimal integer value without leading zeroes between 8 to 15 extension parameter in the received offer has a value, the server may
inclusive indicating the base-2 logarithm of the LZ77 sliding window either ignore this value or use this value to avoid allocating an
size. unnecessarily big LZ77 sliding window by specifying
"c2s_max_window_bits" extension parameter with a value equal to or
smaller than the received value in the response. This server-to-
client parameter has a decimal integer value without leading zeroes
between 8 to 15 inclusive indicating the base-2 logarithm of the LZ77
sliding window size.
c2s_max_window_bits = 1*DIGIT c2s_max_window_bits = 1*DIGIT
Using this server-to-client parameter, a server limits the LZ77 Using this server-to-client parameter, a server limits the LZ77
sliding window size that the client uses to compress messages. This sliding window size that the client uses to compress messages. This
reduces the amount of memory that the server has to reserve for the reduces the amount of memory that the server has to reserve for the
connection, in the same way the "s2c_max_window_bits" extension connection, in the same way the "s2c_max_window_bits" extension
parameter does for the client. parameter does for the client.
If a received offer doesn't have the "c2s_max_window_bits" extension If a received offer doesn't have the "c2s_max_window_bits" extension
skipping to change at page 18, line 29 skipping to change at page 18, line 45
make it end at byte boundary. The next DEFLATE block follows the make it end at byte boundary. The next DEFLATE block follows the
padded data if any. padded data if any.
An endpoint MUST NOT use an LZ77 sliding window longer than 32,768 An endpoint MUST NOT use an LZ77 sliding window longer than 32,768
bytes to compress messages to send. bytes to compress messages to send.
If the "agreed parameters" contain the "c2s_no_context_takeover" If the "agreed parameters" contain the "c2s_no_context_takeover"
extension parameter, the client MUST start compressing each new extension parameter, the client MUST start compressing each new
message with an empty LZ77 sliding window. Otherwise, the client MAY message with an empty LZ77 sliding window. Otherwise, the client MAY
take over the LZ77 sliding window used to build the last compressed take over the LZ77 sliding window used to build the last compressed
message. message. Note that even if the client has included the
"c2s_no_context_takeover" extension parameter in its offer, the
client MAY take over the LZ77 sliding window used to build the last
compressed message if the "agreed parameters" doesn't contain the
"c2s_no_context_takeover" extension parameter. The client-to-server
"c2s_no_context_takeover" extension parameter is just a hint for the
server to build a response.
If the "agreed parameters" contain the "s2c_no_context_takeover" If the "agreed parameters" contain the "s2c_no_context_takeover"
extension parameter, the server MUST start compressing each new extension parameter, the server MUST start compressing each new
message with an empty LZ77 sliding window. Otherwise, the server MAY message with an empty LZ77 sliding window. Otherwise, the server MAY
take over the LZ77 sliding window used to build the last compressed take over the LZ77 sliding window used to build the last compressed
message. message.
If the "agreed parameters" contain the "c2s_max_window_bits" If the "agreed parameters" contain the "c2s_max_window_bits"
extension parameter with a value of w, the client MUST NOT use an extension parameter with a value of w, the client MUST NOT use an
LZ77 sliding window longer than the w-th power of 2 bytes to compress LZ77 sliding window longer than the w-th power of 2 bytes to compress
messages to send. messages to send. Note that even if the client has included in its
offer the "c2s_max_window_bits" extension parameter with a value
smaller than one in the "agreed parameters", the client MAY use an
LZ77 sliding window with any size to compress messages to send as
long as the size conforms to the "agreed parameters". The client-to-
server "c2s_max_window_bits" extension parameter is just a hint for
the server to build a response.
If the "agreed parameters" contain the "s2c_max_window_bits" If the "agreed parameters" contain the "s2c_max_window_bits"
extension parameter with a value of w, the server MUST NOT use an extension parameter with a value of w, the server MUST NOT use an
LZ77 sliding window longer than the w-th power of 2 bytes to compress LZ77 sliding window longer than the w-th power of 2 bytes to compress
messages to send. messages to send.
8.2.2. Decompression 8.2.2. Decompression
An endpoint uses the following algorithm to decompress a message. An endpoint uses the following algorithm to decompress a message.
skipping to change at page 19, line 20 skipping to change at page 19, line 46
If the "agreed parameters" contain the "s2c_no_context_takeover" If the "agreed parameters" contain the "s2c_no_context_takeover"
extension parameter, the client MAY start decompressing each new extension parameter, the client MAY start decompressing each new
message with an empty LZ77 sliding window. Otherwise, the client message with an empty LZ77 sliding window. Otherwise, the client
MUST take over the LZ77 sliding window used to process the last MUST take over the LZ77 sliding window used to process the last
compressed message. compressed message.
If the "agreed parameters" contain the "c2s_no_context_takeover" If the "agreed parameters" contain the "c2s_no_context_takeover"
extension parameter, the server MAY start decompressing each new extension parameter, the server MAY start decompressing each new
message with an empty LZ77 sliding window. Otherwise, the server message with an empty LZ77 sliding window. Otherwise, the server
MUST take over the LZ77 sliding window used to process the last MUST take over the LZ77 sliding window used to process the last
compressed message. compressed message. Note that even if the client has included the
"c2s_no_context_takeover" extension parameter in its offer, the
server MUST take over the LZ77 sliding window used to process the
last compressed message if the "agreed parameters" doesn't contain
the "c2s_no_context_takeover" extension parameter. The client-to-
server "c2s_no_context_takeover" extension parameter is just a hint
for the server to build a response.
If the "agreed parameters" contain the "s2c_max_window_bits" If the "agreed parameters" contain the "s2c_max_window_bits"
extension parameter with a value of w, the client MAY reduce the size extension parameter with a value of w, the client MAY reduce the size
of its LZ77 sliding window to decompress received messages down to of its LZ77 sliding window to decompress received messages down to
the w-th power of 2 bytes. Otherwise, the client MUST use a 32,768 the w-th power of 2 bytes. Otherwise, the client MUST use a 32,768
byte LZ77 sliding window to decompress received messages. byte LZ77 sliding window to decompress received messages.
If the "agreed parameters" contain the "c2s_max_window_bits" If the "agreed parameters" contain the "c2s_max_window_bits"
extension parameter with a value of w, the server MAY reduce the size extension parameter with a value of w, the server MAY reduce the size
of its LZ77 sliding window to decompress received messages down to of its LZ77 sliding window to decompress received messages down to
the w-th power of 2 bytes. Otherwise, the server MUST use a 32,768 the w-th power of 2 bytes. Otherwise, the server MUST use a 32,768
byte LZ77 sliding window to decompress received messages. byte LZ77 sliding window to decompress received messages. Note that
even if the client has included in its offer the
"c2s_max_window_bits" extension parameter with a value smaller that
one in the "agreed parameters", the client MUST use an LZ77 sliding
window of a size that conforms the "agreed parameters" to compress
messages to send. The client-to-server "c2s_max_window_bits"
extension parameter is just a hint for the server to build a
response.
8.2.3. Examples 8.2.3. Examples
This section introduces examples of how the permessage-deflate This section introduces examples of how the permessage-deflate
transforms messages. transforms messages.
8.2.3.1. A message compressed using 1 compressed DEFLATE block 8.2.3.1. A message compressed using 1 compressed DEFLATE block
Suppose that an endpoint sends a text message "Hello". If the Suppose that an endpoint sends a text message "Hello". If the
endpoint uses 1 compressed DEFLATE block (compressed with fixed endpoint uses 1 compressed DEFLATE block (compressed with fixed
 End of changes. 14 change blocks. 
35 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/