draft-ietf-hybi-permessage-compression-01.txt   draft-ietf-hybi-permessage-compression-02.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track October 1, 2012 Intended status: Standards Track October 15, 2012
Expires: April 4, 2013 Expires: April 18, 2013
WebSocket Per-message Compression WebSocket Per-message Compression
draft-ietf-hybi-permessage-compression-01 draft-ietf-hybi-permessage-compression-02
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 4, 2013. This Internet-Draft will expire on April 18, 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 24 skipping to change at page 2, line 24
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.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 . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Implementation Notes . . . . . . . . . . . . . . . . . . . 12 5.4. Implementation Notes . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Registration of the "permessage-compress" WebSocket 7.1. Registration of the "permessage-compress" WebSocket
Extension Name . . . . . . . . . . . . . . . . . . . . . . 14 Extension Name . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Registration of the "Per-message Compressed" WebSocket 7.2. Registration of the "Per-message Compressed" WebSocket
Framing Header Bit . . . . . . . . . . . . . . . . . . . . 14 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 15
7.3. WebSocket Per-message Compression Method Name Registry . . 15 7.3. WebSocket Per-message Compression Method Name Registry . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
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 11, line 4 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 This section introduces examples of how the DEFLATE method transforms
above. messages.
o "Hello" in one compressed block 5.2.3.1. A message compressed using 1 compressed block
* 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 Suppose that a text message "Hello" is sent using the DEFLATE method.
When 1 compressed block (compressed with fixed Huffman code, "BFINAL"
is not set) is used, compressed data to be sent in payload is
obtained as follows.
If not disallowed by any method parameter, "Hello" in the next Compress "Hello" into 1 compressed block and flush it into a byte
message can be compressed to smaller size like this by taking over array using an empty block with no compression:
the LZ77 sliding window used for the last message.
* 0xf2 0x00 0x11 0x00 0x00 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 0x00 0xff 0xff
o "Hello" in one block with no compression Strip 0x00 0x00 0xff 0xff from the tail:
* 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
o "Hello" in one block with "BFINAL" set to 1 To send it without fragmentation, just build a frame putting the
whole data in payload data:
* 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 0xc1 0x07 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
The first 7 octets consist one block with "BFINAL" set to 1 and The first 2 octets are the WebSocket protocol's overhead (FIN=1,
"BTYPE" set to 1 containing "Hello". The last 1 octet contains RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7).
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 To send it after fragmentation, split the compressed payload and
build frames for each of split data as well as fragmentation process
done when the compression extension is not used. For example, the
first fragment may contain 3 octets of the payload:
* 0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 0x41 0x03 0xf2 0x48 0xcd
0x00
The first 3 octets and the least significant two bits of the 4th and the second (last) fragment contain 4 octets of the payload:
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 0x80 0x04 0xc9 0xc9 0x07 0x00
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 Note that RSV1 is set only on the first fragment.
0x00 0xff 0xff), it consists an empty block with no compression.
Then, a block containing "llo" follows. 5.2.3.2. Sharing LZ77 Sliding Window
Suppose that the next message to send is also "Hello". If it's
disallowed by the other peer (using some extension parameter) to take
over the LZ77 sliding window used for the last message, the next
message is compressed into the same byte array (if the same "BTYPE"
and "BFINAL" value are used). If it's allowed, the next message can
be compressed into shorter payload:
0xf2 0x00 0x11 0x00 0x00
instead of:
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
Note that even if any uncompressed message is inserted between the
two "Hello" messages, it doesn't affect context sharing between the
two "Hello" messages.
5.2.3.3. Using a Block with No Compression
Blocks with no compression can be also used. A block with no
compression containing "Hello" flushed into a byte array using an
empty block with no compression is:
0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
0x00 0x00 0xff 0xff
So, payload of a message containing "Hello" converted into a DEFLATE
block with no compression is:
0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
If it's not fragmented, the frame for this message is:
0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
The first 2 octets are the WebSocket protocol's overhead (FIN=1,
RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7). Note
that RSV1 must be set for this message (only on the first fragment of
it) because RSV1 indicates whether DEFLATE is applied to the message
including use of blocks with no compression or not.
5.2.3.4. Using a Block with BFINAL Set to 1
On platform where the flush method based on an empty block with no
compression is not avaiable, implementors can choose to flush data
using blocks with "BFINAL" set to 1. Using a block with "BFINAL" set
to 1 and "BTYPE" set to 1, "Hello" is compressed into:
0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00
So, payload of a message containing "Hello" compressed using this
parameter setting is:
0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00
The last 1 octet contains the header bits with "BFINAL" set to 0 and
"BTYPE" set to 0, and 7 padding bits of 0. It's necessary to make
the payload able to be processed by the same manner as messages
flushed using blocks with BFINAL unset.
5.2.3.5. Two Blocks in 1 Message
Two or more blocks may be used in 1 message.
0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 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),
the header bits consist 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. 19 change blocks. 
42 lines changed or deleted 119 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/