draft-ietf-hybi-permessage-compression-00.txt   draft-ietf-hybi-permessage-compression-01.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track August 21, 2012 Intended status: Standards Track October 1, 2012
Expires: February 22, 2013 Expires: April 4, 2013
WebSocket Per-message Compression WebSocket Per-message Compression
draft-ietf-hybi-permessage-compression-00 draft-ietf-hybi-permessage-compression-01
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 February 22, 2013. This Internet-Draft will expire on April 4, 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 25 skipping to change at page 2, line 25
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.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 . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Implementation Notes . . . . . . . . . . . . . . . . . . . 11 5.4. Implementation Notes . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Registration of the "permessage-compress" WebSocket 7.1. Registration of the "permessage-compress" WebSocket
Extension Name . . . . . . . . . . . . . . . . . . . . . . 13 Extension Name . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Registration of the "Per-message Compressed" WebSocket 7.2. Registration of the "Per-message Compressed" WebSocket
Framing Header Bit . . . . . . . . . . . . . . . . . . . . 13 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 14
7.3. WebSocket Per-message Compression Method Name Registry . . 14 7.3. WebSocket Per-message Compression Method Name Registry . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 9, line 26 skipping to change at page 9, line 26
doesn't support the method and its configuration specified by the doesn't support the method and its configuration specified by the
received "deflate" method description. received "deflate" method description.
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. Multiple blocks MAY be used. Any type of block MAY be DEFLATE.
used. Both block with "BFINAL" set to 0 and 1 MAY be used.
2. If the resulting data does not end with an empty block with no 2. If the resulting data does not end with an empty block with no
compression ("BTYPE" set to 0), append an empty block with no compression ("BTYPE" set to 0), append an empty block with no
compression to the tail. compression to the tail.
3. Remove 4 octets (that are 0x00 0x00 0xff 0xff) from the tail. 3. Remove 4 octets (that are 0x00 0x00 0xff 0xff) from the tail.
After this step, the last octet of the compressed data contains
the (part of) header bits with "BTYPE" set to 0.
In the first step:
o Multiple blocks MAY be used.
o Any type of block 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
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
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 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 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. 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 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 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. window greater than w-th power of 2 bytes to build messages to send.
skipping to change at page 10, line 37 skipping to change at page 11, line 4
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. If
the "method agreement" has the "c2s_no_context_takeover" method 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.
5.2.3. Examples 5.2.3. Examples
_This section is non-normative._ _This section is non-normative._
These are examples of resulting data after applying the algorithm These are examples of resulting data after applying the algorithm
above. above.
o "Hello" in one compressed block o "Hello" in one compressed block
* 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 * 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
"Hello" in one compressed block in the next frame If not disallowed by any method parameter, "Hello" in the next
message can be compressed to smaller size like this by taking over
the LZ77 sliding window used for the last message.
* 0xf2 0x00 0x11 0x00 0x00 * 0xf2 0x00 0x11 0x00 0x00
o "Hello" in one block with no compression o "Hello" in one block with no compression
* 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 * 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
o "Hello" in one block with "BFINAL" set to 1 o "Hello" in one block with "BFINAL" set to 1
* 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 * 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00
The first 7 octets consist one block with "BFINAL" set to 1 and
"BTYPE" set to 1 containing "Hello". The last 1 octet contains
the header bits with "BFINAL" set to 0 and "BTYPE" set to 0, and 7
padding bits of 0.
o "He" and "llo" in separate blocks o "He" and "llo" in separate blocks
* 0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 * 0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07
0x00 0x00
The first 3 octets and the least significant two bits of the 4th
octet consist one block with "BFINAL" set to 0 and "BTYPE" set to
1 containing "He". The rest of the 4th octet contains the header
bits with "BFINAL" set to 0 and "BTYPE" set to 0, and the 3
padding bits of 0. Together with the following 4 octets (0x00
0x00 0xff 0xff), it consists an empty block with no compression.
Then, a block containing "llo" follows.
5.3. Intermediaries 5.3. Intermediaries
When intermediaries forward messages, they MAY decompress and/or When intermediaries forward messages, they MAY decompress and/or
compress the messages according to the constraints negotiated during compress the messages according to the constraints negotiated during
the opening handshake of the connection(s). the opening handshake of the connection(s).
5.4. Implementation Notes 5.4. Implementation Notes
_This section is non-normative._ _This section is non-normative._
 End of changes. 12 change blocks. 
19 lines changed or deleted 47 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/