draft-ietf-hybi-permessage-compression-02.txt   draft-ietf-hybi-permessage-compression-03.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track October 15, 2012 Intended status: Standards Track October 16, 2012
Expires: April 18, 2013 Expires: April 19, 2013
WebSocket Per-message Compression WebSocket Per-message Compression
draft-ietf-hybi-permessage-compression-02 draft-ietf-hybi-permessage-compression-03
Abstract Abstract
This specification defines a WebSocket extension that adds This specification defines a WebSocket extension that adds
compression functionality to the WebSocket Protocol. It compresses compression functionality to the WebSocket Protocol. It compresses
the payload of non-control WebSocket messages using specified the payload of non-control WebSocket messages using specified
compression algorithm. One reserved bit RSV1 in the WebSocket frame compression algorithm. One reserved bit RSV1 in the WebSocket frame
header is allocated to control application of compression for each header is allocated to control application of compression for each
message. This specification provides one compression method message. This specification provides one compression method
available for the extension using DEFLATE. available for the extension using DEFLATE.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 18, 2013. This Internet-Draft will expire on April 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 4 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 4
3. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 5 3. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 5
3.1. Negotiation Example . . . . . . . . . . . . . . . . . . . 6 3.1. Negotiation Example . . . . . . . . . . . . . . . . . . . 6
4. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 7
5. DEFLATE method . . . . . . . . . . . . . . . . . . . . . . . . 8 5. DEFLATE method . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 8 5.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Disallow compression context takeover . . . . . . . . 8
5.1.2. Limit maximum LZ77 sliding window size . . . . . . . . 9
5.2. Application Data Transformation . . . . . . . . . . . . . 9 5.2. Application Data Transformation . . . . . . . . . . . . . 9
5.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 11
5.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Implementation Notes . . . . . . . . . . . . . . . . . . . 13 5.4. Implementation Notes . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. Registration of the "permessage-compress" WebSocket 7.1. Registration of the "permessage-compress" WebSocket
Extension Name . . . . . . . . . . . . . . . . . . . . . . 15 Extension Name . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Registration of the "Per-message Compressed" WebSocket 7.2. Registration of the "Per-message Compressed" WebSocket
Framing Header Bit . . . . . . . . . . . . . . . . . . . . 15 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 16
7.3. WebSocket Per-message Compression Method Name Registry . . 16 7.3. WebSocket Per-message Compression Method Name Registry . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
_This section is non-normative._ _This section is non-normative._
As well as other communication protocols, the WebSocket Protocol As well as other communication protocols, the WebSocket Protocol
[RFC6455] can benefit from compression technology. This [RFC6455] can benefit from compression technology. This
specification defines a WebSocket extension that applies a specification defines a WebSocket extension that applies a
compression algorithm to octets exchanged over the WebSocket Protocol compression algorithm to octets exchanged over the WebSocket Protocol
using its extension framework. This extension negotiates what using its extension framework. This extension negotiates what
skipping to change at page 5, line 33 skipping to change at page 5, line 33
method-param = token ["=" (token | quoted-string)] method-param = token ["=" (token | quoted-string)]
The list MAY contain multiple method descriptions with the same The list MAY contain multiple method descriptions with the same
method name. method name.
To accept use of the Per-message Compression Extension, a server MUST To accept use of the Per-message Compression Extension, a server MUST
choose one compression method description to accept from ones listed choose one compression method description to accept from ones listed
by the client, and include an element with the "permessage-compress" by the client, and include an element with the "permessage-compress"
extension token in the "Sec-WebSocket-Extensions" header in its extension token in the "Sec-WebSocket-Extensions" header in its
opening handshake. The chosen description is called "accepted opening handshake. The chosen description is called "accepted
request". The element MUST contain exactly one extension parameter request". The element in the server's "Sec-WebSocket-Extensions"
named "method". The value of the "method" extension parameter MUST MUST contain exactly one extension parameter named "method". The
be a compression method description. This description is called value of the "method" extension parameter MUST be a compression
"method agreement". The method name in the "method agreement" MUST method description. This description is called "method agreement".
be one of the accepted request. The "method agreement" MUST conform The method name in the "method agreement" MUST be one of the accepted
the "accepted request". Its grammar is "method-agreement" defined in request. The "method agreement" MUST be derived from the "accepted
the following ABNF. request" and the server's capability. If the server doesn't support
any of the descriptions listed by the client, the server MUST reject
use of the Per-message Compression Extension. Its grammar is
"method-agreement" defined in the following ABNF.
method-agreement = method-desc method-agreement = method-desc
The value of the "method" parameter MUST be quoted by using The value of the "method" parameter MUST be quoted by using
"quoted-string" syntax if it doesn't conform to token syntax. "quoted-string" syntax if it doesn't conform to token syntax.
If a client doesn't support the method and its configuration If a client doesn't support the method and its configuration
specified by the "method agreement", the client MUST _Fail the specified by the "method agreement", the client MUST _Fail the
WebSocket Connection_. Otherwise, both endpoints MUST use the WebSocket Connection_. Otherwise, both endpoints MUST use the
algorithm described in Section 4 to exchange messages. algorithm described in Section 4 to exchange messages.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
token syntax. Quotation is needed. token syntax. Quotation is needed.
permessage-compress; method="foo; x=10" permessage-compress; method="foo; x=10"
o Request foo method and bar method. Since the method parameter o Request foo method and bar method. Since the method parameter
value contains a comma, it doesn't match token syntax. Quotation value contains a comma, it doesn't match token syntax. Quotation
is needed. is needed.
permessage-compress; method="foo, bar" permessage-compress; method="foo, bar"
o Request foo method with a feature x but also allowing fallback to
one without the feature.
permessage-compress; method="foo; use_x, foo"
o Request foo method with parameter x with "Hello World" (quotation o Request foo method with parameter x with "Hello World" (quotation
for clarification) as its value and bar method. Since "Hello for clarification) as its value and bar method. Since "Hello
World" contains a space, it needs to be quoted. Since quoted World" contains a space, it needs to be quoted. Since quoted
"Hello World" contains double quotations and a space, it needs to "Hello World" contains double quotations and a space, it needs to
be quoted again. be quoted again.
permessage-compress; method="foo; x=\"Hello World\", bar" permessage-compress; method="foo; x=\"Hello World\", bar"
4. Framing 4. Framing
skipping to change at page 8, line 13 skipping to change at page 8, line 13
decompression. decompression.
5. DEFLATE method 5. DEFLATE method
This section defines a method named "deflate" for this extension that This section defines a method named "deflate" for this extension that
compresses the payload of messages using DEFLATE [RFC1951] and byte compresses the payload of messages using DEFLATE [RFC1951] and byte
boundary alignment method introduced in [RFC1979]. boundary alignment method introduced in [RFC1979].
5.1. Method Parameters 5.1. Method Parameters
An endpoint MAY include one or more method parameters in the method The following 4 method parameters are defined for "deflate" method in
description as defined below. the following subsections.
Maximum LZ77 sliding window size o "s2c_no_context_takeover"
A client MAY attach the "s2c_max_window_bits" method parameter to o "c2s_no_context_takeover"
limit the LZ77 sliding window size that the server uses to build
messages. If the "accepted request" has this method parameter,
the server MUST NOT use LZ77 sliding window size greater than the
size specified by this parameter to build messages. If the
"accepted request" has this method parameter, the server MUST
attach this method parameter with the same value as one of the
"accepted request".
A server MAY attach the "c2s_max_window_bits" method parameter to o "s2c_max_window_bits"
limit the LZ77 sliding window size that the client uses to build
messages. A client that received this parameter MUST NOT use LZ77
sliding window size greater than the size specified by this
parameter to build messages.
These parameters MUST have an integer value in the range between 8 o "c2s_max_window_bits"
to 15 indicating the base-2 logarithm of the LZ77 sliding window
size.
Disallow compression context takeover A server MUST ignore "deflate" method descriptions that:
A client MAY attach the "s2c_no_context_takeover" method parameter o have any method parameter unknown to the server
to disallow the server to take over the LZ77 sliding window used
to build previous messages. If the "accepted request" has this
method parameter, the server MUST reset its LZ77 sliding window
for sending to empty for each message. If the "accepted request"
has this method parameter, the server MUST attach this method
parameter.
A server MAY attach the "c2s_no_context_takeover" method parameter o have any method parameter with an invalid value
to disallow the client to take over the LZ77 sliding window used
to build previous messages. A client that received this parameter
MUST reset its LZ77 sliding window for sending to empty for each
message.
These parameters have no value. o is not supported by the server
A server MUST ignore any method parameter other than A client MUST _Fail the WebSocket Connection_ if the "method
"s2c_max_window_bits" and "s2c_no_context_takeover" in the received agreement":
"deflate" method description.
A client MUST _Fail the WebSocket Connection_ if there is any method o has any method parameter unknown to the client
parameter other than the "s2c_max_window_bits",
"c2s_max_window_bits", "s2c_no_context_takeover" and o has any method parameter with an invalid value
"c2s_no_context_takeover" in the received "deflate" method
description. A client MUST _Fail the WebSocket Connection_ if it o is not supported by the client
doesn't support the method and its configuration specified by the
received "deflate" method description. 5.1.1. Disallow compression context takeover
A client MAY attach the "s2c_no_context_takeover" method parameter to
disallow the server to take over the LZ77 sliding window used to
build previous messages. Servers SHOULD be able to accept the
"s2c_no_context_takeover" method parameter. If the "accepted
request" has this method parameter, the server:
o MUST reset its LZ77 sliding window for sending to empty for each
message
o MUST attach this method parameter to its "method agreement"
A server MAY attach the "c2s_no_context_takeover" method parameter to
disallow the client to take over the LZ77 sliding window used to
build previous messages. Clients SHOULD be able to accept the
"c2s_no_context_takeover" method parameter. A client that received
this parameter MUST reset its LZ77 sliding window for sending to
empty for each message.
These parameters have no value.
5.1.2. Limit maximum LZ77 sliding window size
A client MAY attach the "s2c_max_window_bits" method parameter to
limit the LZ77 sliding window size that the server uses to build
messages. This parameter MUST have an integer value in the range
between 8 to 15 indicating the base-2 logarithm of the LZ77 sliding
window size. Servers MAY be able to accept the "s2c_max_window_bits"
method parameter. If the "accepted request" has this method
parameter, the server:
o MUST attach this method parameter with the same value as one of
the "accepted request" to its "method agreement"
o MUST NOT use LZ77 sliding window size greater than the size
specified by this parameter to build messages
A client MAY attach the "c2s_max_window_bits" method parameter if the
client can adjust LZ77 sliding window size based on the
"c2s_max_window_bits" sent by the server. This parameter has no
value.
If the "accepted request" has the "c2s_max_window_bits" method
parameter, the server MAY attach the "c2s_max_window_bits" method
parameter to limit the LZ77 sliding window size that the client uses
to build messages. Otherwise, the server MUST NOT attach the
parameter. This parameter sent by the server MUST have an integer
value in the range between 8 to 15 indicating the base-2 logarithm of
the LZ77 sliding window size. A client that received this parameter
MUST NOT use LZ77 sliding window size greater than the size specified
by this parameter to build messages.
5.2. Application Data Transformation 5.2. Application Data Transformation
5.2.1. Compression 5.2.1. Compression
An endpoint MUST use the following algorithm to compress a message. An endpoint MUST use the following algorithm to compress a message.
1. Compress all the octets of the payload of the message using 1. Compress all the octets of the payload of the message using
DEFLATE. DEFLATE.
skipping to change at page 9, line 52 skipping to change at page 10, line 32
o Both block with "BFINAL" set to 0 and 1 MAY be used. o Both block with "BFINAL" set to 0 and 1 MAY be used.
o When any block with "BFINAL" set to 1 doesn't end at byte o When any block with "BFINAL" set to 1 doesn't end at byte
boundary, minimal padding bits of 0 MUST be added to make it end boundary, minimal padding bits of 0 MUST be added to make it end
at byte boundary, and then the next block MUST start at the byte at byte boundary, and then the next block MUST start at the byte
boundary if any. boundary if any.
An endpoint MUST NOT use an LZ77 sliding window greater than 32,768 An endpoint MUST NOT use an LZ77 sliding window greater than 32,768
bytes to build messages to send. bytes to build messages to send.
If the "method agreement" has the "s2c_max_window_bits" method
parameter and its value is w, the server MUST NOT use an LZ77 sliding
window greater than w-th power of 2 bytes to build messages to send.
If the "method agreement" has the "c2s_max_window_bits" method
parameter and its value is w, the client MUST NOT use an LZ77 sliding
window greater than w-th power of 2 bytes to build messages to send.
If the "method agreement" has the "s2c_no_context_takeover" method If the "method agreement" has the "s2c_no_context_takeover" method
parameter, the server MUST reset its LZ77 sliding window for sending parameter, the server MUST reset its LZ77 sliding window for sending
to empty for each message. Otherwise, the server MAY take over the to empty for each message. Otherwise, the server MAY take over the
LZ77 sliding window used to build the last compressed message. If LZ77 sliding window used to build the last compressed message.
the "method agreement" has the "c2s_no_context_takeover" method
If the "method agreement" has the "c2s_no_context_takeover" method
parameter, the client MUST reset its LZ77 sliding window for sending parameter, the client MUST reset its LZ77 sliding window for sending
to empty for each message. Otherwise, the client MAY take over the to empty for each message. Otherwise, the client MAY take over the
LZ77 sliding window used to build the last compressed message. LZ77 sliding window used to build the last compressed message.
If the "method agreement" has the "s2c_max_window_bits" method
parameter and its value is w, the server MUST NOT use an LZ77 sliding
window greater than w-th power of 2 bytes to build messages to send.
If the "method agreement" has the "c2s_max_window_bits" method
parameter and its value is w, the client MUST NOT use an LZ77 sliding
window greater than w-th power of 2 bytes to build messages to send.
5.2.2. Decompression 5.2.2. Decompression
An endpoint MUST use the following algorithm to decompress a message. An endpoint MUST use the following algorithm to decompress a message.
1. Append 4 octets of 0x00 0x00 0xff 0xff to the tail of the payload 1. Append 4 octets of 0x00 0x00 0xff 0xff to the tail of the payload
of the message. of the message.
2. Decompress the resulting octets using DEFLATE. 2. Decompress the resulting octets using DEFLATE.
If the "method agreement" has the "s2c_max_window_bits" method
parameter and its value is w, the client MAY reduce the size of the
LZ77 sliding window to decompress received messages down to the w-th
power of 2 bytes. Otherwise, the client MUST use a 32,768 byte LZ77
sliding window to decompress received messages. If the "method
agreement" has the "c2s_max_window_bits" method parameter and its
value is w, the server MAY reduce the size of the LZ77 sliding window
to decompress received messages down to the w-th power of 2 bytes.
Otherwise, the server MUST use a 32,768 byte LZ77 sliding window to
decompress received messages.
If the "method agreement" has the "s2c_no_context_takeover" method If the "method agreement" has the "s2c_no_context_takeover" method
parameter, the client MAY reset its LZ77 sliding window for receiving parameter, the client MAY reset its LZ77 sliding window for receiving
to empty for each message. Otherwise, the client MUST take over the to empty for each message. Otherwise, the client MUST take over the
LZ77 sliding window used to parse the last compressed message. If LZ77 sliding window used to parse the last compressed message.
the "method agreement" has the "c2s_no_context_takeover" method
If the "method agreement" has the "c2s_no_context_takeover" method
parameter, the server MAY reset its LZ77 sliding window for receiving parameter, the server MAY reset its LZ77 sliding window for receiving
to empty for each message. Otherwise, the server MUST take over the to empty for each message. Otherwise, the server MUST take over the
LZ77 sliding window used to parse the last compressed message. LZ77 sliding window used to parse the last compressed message.
If the "method agreement" has the "s2c_max_window_bits" method
parameter and its value is w, the client MAY reduce the size of the
LZ77 sliding window to decompress received messages down to the w-th
power of 2 bytes. Otherwise, the client MUST use a 32,768 byte LZ77
sliding window to decompress received messages.
If the "method agreement" has the "c2s_max_window_bits" method
parameter and its value is w, the server MAY reduce the size of the
LZ77 sliding window to decompress received messages down to the w-th
power of 2 bytes. Otherwise, the server MUST use a 32,768 byte LZ77
sliding window to decompress received messages.
5.2.3. Examples 5.2.3. Examples
_This section is non-normative._ _This section is non-normative._
This section introduces examples of how the DEFLATE method transforms This section introduces examples of how the DEFLATE method transforms
messages. messages.
5.2.3.1. A message compressed using 1 compressed block 5.2.3.1. A message compressed using 1 compressed block
Suppose that a text message "Hello" is sent using the DEFLATE method. Suppose that a text message "Hello" is sent using the DEFLATE method.
When 1 compressed block (compressed with fixed Huffman code, "BFINAL" When 1 compressed block (compressed with fixed Huffman code, "BFINAL"
is not set) is used, compressed data to be sent in payload is is not set) is used, compressed data to be sent in payload is
obtained as follows. obtained as follows.
 End of changes. 27 change blocks. 
90 lines changed or deleted 132 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/