draft-ietf-hybi-permessage-compression-13.txt   draft-ietf-hybi-permessage-compression-14.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track October 8, 2013 Intended status: Standards Track October 15, 2013
Expires: April 11, 2014 Expires: April 18, 2014
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-13 draft-ietf-hybi-permessage-compression-14
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 April 11, 2014. This Internet-Draft will expire on April 18, 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 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conformance Requirements and Terminology . . . . . . . . . . . 4 2. Conformance Requirements and Terminology . . . . . . . . . . . 4
3. Complementary Terminology . . . . . . . . . . . . . . . . . . 5 3. Complementary Terminology . . . . . . . . . . . . . . . . . . 5
4. WebSocket Per-message Compression Extension . . . . . . . . . 6 4. WebSocket Per-message Compression Extension . . . . . . . . . 6
5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7 5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7
5.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . 8 5.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . 9
6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 11
7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 13
8. permessage-deflate extension . . . . . . . . . . . . . . . . . 14 8. permessage-deflate extension . . . . . . . . . . . . . . . . . 14
8.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 15 8.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 15
8.1.1. Context Takeover Control . . . . . . . . . . . . . . . 15 8.1.1. Context Takeover Control . . . . . . . . . . . . . . . 15
8.1.2. Limiting the LZ77 sliding window size . . . . . . . . 16 8.1.2. Limiting the LZ77 sliding window size . . . . . . . . 16
8.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18 8.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Message Payload Transformation . . . . . . . . . . . . . . 19 8.2. Message Payload Transformation . . . . . . . . . . . . . . 19
8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 19 8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 19
8.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 20 8.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 20
8.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 21 8.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 24 8.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 24
8.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 24 8.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. Registration of the "permessage-deflate" WebSocket 10.1. Registration of the "permessage-deflate" WebSocket
Extension Name . . . . . . . . . . . . . . . . . . . . . . 26 Extension Name . . . . . . . . . . . . . . . . . . . . . . 27
10.2. Registration of the "Per-message Compressed" WebSocket 10.2. Registration of the "Per-message Compressed" WebSocket
Framing Header Bit . . . . . . . . . . . . . . . . . . . . 26 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
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 5, line 9 skipping to change at page 5, line 9
respectively, of [RFC6455]. respectively, of [RFC6455].
This document uses the Argumented Backus-Naur Form (ABNF) notation of This document uses the Argumented Backus-Naur Form (ABNF) notation of
[RFC5234]. The DIGIT (decimal 0-9) rule is included by reference, as [RFC5234]. The DIGIT (decimal 0-9) rule is included by reference, as
defined in the Appendix B.1 of [RFC5234]. defined in the Appendix B.1 of [RFC5234].
3. Complementary Terminology 3. Complementary Terminology
This document defines some terms about WebSocket and WebSocket This document defines some terms about WebSocket and WebSocket
Extension mechanism that are underspecified or not defined at all in Extension mechanism that are underspecified or not defined at all in
RFC6455. This terminology is effective only in this document and any [RFC6455]. This terminology is effective only in this document and
other documents that refer to this section. any other documents that refer to this section.
Non-control message means a message consists of non-control frames. Non-control message means a message that consists of non-control
frames as defined in Section 5.6 of [RFC6455].
Message payload (or payload of a message) means concatenation of the Message payload (or payload of a message) means concatenation of the
payload data portion of all frames consisting the message. payload data portion of all frames representing a single message, as
well as how /data/ is formed from in Section 6.2 of [RFC6455].
Extension in use next to extension X means the extension listed next Extension in use next to extension X means the extension listed next
to X in the "Sec-WebSocket-Extensions" header in the server's opening to X in the "Sec-WebSocket-Extensions" header in the server's opening
handshake. Such an extension is applied to outgoing data from the handshake as defined in Section 9.1 of [RFC6455]. Such an extension
application right after X on sender side but applied right before X is applied to outgoing data from the application right after X on
to incoming data from the underlying transport. sender side but applied right before X to incoming data from the
underlying transport.
Accept an extension offer means including a corresponding response in Accept an extension offer means including a corresponding response in
the "Sec-WebSocket-Extensions" header in the server's opening the "Sec-WebSocket-Extensions" header in the server's opening
handshake. handshake.
Decline an extension offer means not including a corresponding Decline an extension offer means not including a corresponding
response in the "Sec-WebSocket-Extensions" header in the server's response in the "Sec-WebSocket-Extensions" header in the server's
opening handshake. opening handshake.
4. WebSocket Per-message Compression Extension 4. WebSocket Per-message Compression Extension
skipping to change at page 7, line 36 skipping to change at page 7, line 36
opening handshake of the WebSocket connection. Extension parameters opening handshake of the WebSocket connection. Extension parameters
in the element represent the configuration parameters of the PMCE to in the element represent the configuration parameters of the PMCE to
use in detail. We call these extension parameters and their values use in detail. We call these extension parameters and their values
"agreed parameters". The element MUST represent a PMCE that is fully "agreed parameters". The element MUST represent a PMCE that is fully
supported by the server. The contents of the element doesn't need to supported by the server. The contents of the element doesn't need to
be exactly the same as one of the received offers. For example, an be exactly the same as one of the received offers. For example, an
offer with an extension parameter "X" indicating availability of the offer with an extension parameter "X" indicating availability of the
feature X may be accepted with an element without the extension feature X may be accepted with an element without the extension
parameter meaning that the server declined use of the feature. parameter meaning that the server declined use of the feature.
"Agreed parameters" MUST represent all parameters that can determine "Agreed parameters" MUST represent how the requests and hints in the
behavior of both the server and the client so that it's unnecessary client's offer have been handled in addition to the server's requests
to identify which offer has been accepted. For example, if a client and hints on the client's behavior, so that the client can configure
sends an offer with a parameter "enable_compression" and another its behavior without identifying which PMCE offer has been accepted.
without the parameter, the server accepts the former by sending back
an element including a parameter that acknowledges For example, if a client sends an offer with a parameter
"enable_compression". The name of the acknowledging parameter "enable_compression" and another without the parameter, the server
doesn't need to be the same as the offer. accepts the former by sending back an element including a parameter
that acknowledges "enable_compression". The name of the
acknowledging parameter doesn't need to be the same as the offer.
General negotiation flow will be like the followings. How to handle
parameters in detail will be specified in the specifications for each
PMCEs.
A client makes an offer including parameters identifying the
followings:
o Hints about how the client is planning to compress data
o Requests about how the server compresses data
o Limitation of the client's compression functionality
The peer server uses these parameters, makes a determination of its
behavior based on them if it can and wants to proceed with this PMCE
enabled, and responds to the client with parameters identifying the
followings:
o Requests about how the client compresses data
o How the server will compress data
The client uses these parameters from the server make a determination
of its behavior based on them if it can and wants to proceed.
Otherwise, the client starts closing handshake with close code 1010.
There can be compression features that can be applied separately for There can be compression features that can be applied separately for
each direction. For such features, the acknowledging parameter and each direction. For such features, the acknowledging parameter and
the parameter for the reverse direction must be chosen to be the parameter for the reverse direction must be chosen to be
distinguishable from each other. For example, we can add "s2c_" distinguishable from each other. For example, we can add "s2c_"
prefix to parameters affecting data sent from a server and "c2s_" prefix to parameters affecting data sent from a server and "c2s_"
prefix to ones affecting data sent form a client to make them prefix to ones affecting data sent from a client to make them
distinguishable. distinguishable.
A server MUST NOT accept a PMCE offer together with another extension A server MUST NOT accept a PMCE offer together with another extension
if the PMCE will conflict with the extension on use of the RSV1 bit. if the PMCE will conflict with the extension on use of the RSV1 bit.
A client that receives a response accepting a PMCE offer together A client that receives a response accepting a PMCE offer together
with such an extension MUST _Fail the WebSocket Connection_. with such an extension MUST _Fail the WebSocket Connection_.
A server MUST NOT accept a PMCE offer together with another extension A server MUST NOT accept a PMCE offer together with another extension
if the PMCE will be applied to output of the extension and any of the if the PMCE will be applied to output of the extension and any of the
following conditions applies to the extension: following conditions applies to the extension:
skipping to change at page 14, line 18 skipping to change at page 14, line 18
It compresses the payload of a message using the DEFLATE algorithm It compresses the payload of a message using the DEFLATE algorithm
[RFC1951] and the byte boundary aligning method introduced in [RFC1951] and the byte boundary aligning method introduced in
[RFC1979]. [RFC1979].
This section uses the term "byte" with the same meaning as RFC1951, This section uses the term "byte" with the same meaning as RFC1951,
i.e. 8 bits stored or transmitted as a unit (same as an octet). i.e. 8 bits stored or transmitted as a unit (same as an octet).
The registered extension name for this extension is The registered extension name for this extension is
"permessage-deflate". "permessage-deflate".
For an offer for this extension, the following 4 extension parameters Four extension parameters are defined for permessage-deflate to help
are defined. If needed to distinguish from ones for a response, endpoints manage per-connection resource usage.
these parameters are called with a prefix "client-to-server".
o "s2c_no_context_takeover" o "s2c_no_context_takeover"
o "c2s_no_context_takeover" o "c2s_no_context_takeover"
o "s2c_max_window_bits" o "s2c_max_window_bits"
o "c2s_max_window_bits" o "c2s_max_window_bits"
For a response for this extension, the following 4 extension These represent two methods of constraining memory usage that may be
parameters are defined. If needed to distinguish from ones for an applied independently to either direction of WebSocket traffic. The
offer, these parameters are called with a prefix "server-to-client". prefixes c2s and s2c are used to indicate the client-to-server
channel and the server-to-client channel respectively. All four
o "s2c_no_context_takeover" parameters are defined for both a client's offer and a server's
response.
o "c2s_no_context_takeover"
o "s2c_max_window_bits"
o "c2s_max_window_bits"
A server MUST decline an offer for this extension if any of the A server MUST decline an offer for this extension if any of the
following conditions is met: following conditions is met:
o The offer has any extension parameter not defined for use in an o The offer has any extension parameter not defined for use in an
offer. offer.
o The offer has any extension parameter with an invalid value. o The offer has any extension parameter with an invalid value.
o The offer has multiple extension parameters with the same name. o The offer has multiple extension parameters with the same name.
skipping to change at page 16, line 38 skipping to change at page 16, line 30
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.
8.1.2. Limiting the LZ77 sliding window size 8.1.2. Limiting the LZ77 sliding window size
8.1.2.1. s2c_max_window_bits 8.1.2.1. s2c_max_window_bits
A client MAY include the "s2c_max_window_bits" extension parameter in A client MAY include the "s2c_max_window_bits" extension parameter in
an offer. This parameter has a decimal integer value without leading an offer. This parameter has a decimal integer value without leading
zeroes between 8 to 15 inclusive indicating the base-2 logarithm of zeroes between 8 to 15 inclusive indicating the base-2 logarithm of
the LZ77 sliding window size. the LZ77 sliding window size. Absence of this parameter in an offer
indicates that the client is ready to receive messages compressed
using an LZ77 sliding window of up to 32,768 bytes.
s2c_max_window_bits = 1*DIGIT s2c_max_window_bits = 1*DIGIT
Using this parameter, a client limits the LZ77 sliding window size Using this parameter, a client limits the LZ77 sliding window size
that the server uses to compress messages. If the peer server uses that the server uses to compress messages. If the peer server uses
small LZ77 sliding window to compress messages, the client can reduce small LZ77 sliding window to compress messages, the client can reduce
the memory for the LZ77 sliding window. the memory for the LZ77 sliding window.
A server declines an offer with this parameter if the server doesn't A server declines an offer with this parameter if the server doesn't
support it. support it.
skipping to change at page 17, line 19 skipping to change at page 17, line 14
A server MAY include the "s2c_max_window_bits" extension parameter in A server MAY include the "s2c_max_window_bits" extension parameter in
a response even if the offer to accept by the response doesn't have a response even if the offer to accept by the response doesn't have
"s2c_max_window_bits" extension parameter. "s2c_max_window_bits" extension parameter.
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. If a value is
parameter, a client tells the peer server that the client supports specified for this parameter, the value MUST conform to the ABNF
the server-to-client "c2s_max_window_bits" extension parameter. If below.
c2s_max_window_bits = 1*DIGIT
Using this parameter, a client tells the peer server that the client
supports the server-to-client "c2s_max_window_bits" extension
parameter, and optionally a hint by including a parameter value. 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 even if the server sends the "c2s_max_window_bits" hint that even if the server sends the "c2s_max_window_bits"
extension parameter with a bigger value or doesn't send it at all, 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 client is not going to use LZ77 sliding window size greater than
the size specified by the value to compress messages. 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" extension parameter, the server MAY include the "c2s_max_window_bits" extension
parameter in the response to the offer. If the "c2s_max_window_bits" parameter in the response to the offer. If the "c2s_max_window_bits"
extension parameter in the received offer has a value, the server may extension parameter in the received offer has a value, the server may
skipping to change at page 18, line 5 skipping to change at page 18, line 5
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
parameter, the server MUST NOT include the "c2s_max_window_bits" parameter, the server MUST NOT include the "c2s_max_window_bits"
extension parameter in the response to the offer. extension parameter in the response to the offer.
Absence of this parameter in an response indicates that the server is
ready to receive messages compressed using an LZ77 sliding window of
up to 32,768 bytes.
8.1.3. Example 8.1.3. Example
The simplest "Sec-WebSocket-Extensions" header in a client's opening The simplest "Sec-WebSocket-Extensions" header in a client's opening
handshake to offer use of the permessage-deflate is the following: handshake to offer use of the permessage-deflate is the following:
Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Extensions: permessage-deflate
Since the "c2s_max_window_bits" extension parameter is not specified, Since the "c2s_max_window_bits" extension parameter is not specified,
the server may not accept the offer with the "c2s_max_window_bits" the server may not accept the offer with the "c2s_max_window_bits"
extension parameter. The simplest "Sec-WebSocket-Extensions" header extension parameter. The simplest "Sec-WebSocket-Extensions" header
skipping to change at page 22, line 50 skipping to change at page 23, line 5
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
This is the payload of the first message the client has sent. If the This is the payload of the first message the client has sent. If the
"agreed parameters" contain the "c2s_no_context_takeover" extension "agreed parameters" contain the "c2s_no_context_takeover" extension
parameter, the client compresses the payload of the next message into parameter, the client compresses the payload of the next message into
the same bytes (if the client uses the same "BTYPE" value and the same bytes (if the client uses the same "BTYPE" value and
"BFINAL" value). So, the payload of the second message will be: "BFINAL" value). So, the payload of the second message will be:
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
When concatenated with the first message:
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0xf2 0x48 0xcd 0xc9 0xc9
0x07 0x00
If the "agreed parameters" did not contain the If the "agreed parameters" did not contain the
"c2s_no_context_takeover" extension parameter, the client can "c2s_no_context_takeover" extension parameter, the client can
compress the payload of the next message into shorter bytes by compress the payload of the next message into shorter bytes by
referencing the history in the LZ77 sliding window. So, the payload referencing the history in the LZ77 sliding window. So, the payload
of the second message will be: of the second message will be:
0xf2 0x00 0x11 0x00 0x00 0xf2 0x00 0x11 0x00 0x00
When concatenated with the first message:
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0xf2 0x00 0x11 0x00 0x00
So, 2 bytes were saved in total.
Note that even if some uncompressed messages (with the RSV1 bit Note that even if some uncompressed messages (with the RSV1 bit
unset) are inserted between the two "Hello" messages, they will make unset) are inserted between the two "Hello" messages, they will make
no difference to the LZ77 sliding window. no difference to the LZ77 sliding window.
8.2.3.3. Using a DEFLATE Block with No Compression 8.2.3.3. Using a DEFLATE Block with No Compression
0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
This is a frame constituting a text message "Hello" compressed using This is a frame constituting a text message "Hello" compressed using
a DEFLATE block with no compression. The first 2 octets (0xc1 0x0b) a DEFLATE block with no compression. The first 2 octets (0xc1 0x0b)
skipping to change at page 28, line 9 skipping to change at page 29, line 9
Greg Wilkins, Inaki Baz Castillo, Jamie Lokier, Joakim Erdfelt, John Greg Wilkins, Inaki Baz Castillo, Jamie Lokier, Joakim Erdfelt, John
A. Tamplin, Julian Reschke, Kenichi Ishibashi, Mark Nottingham, Peter A. Tamplin, Julian Reschke, Kenichi Ishibashi, Mark Nottingham, Peter
Thorson, Roberto Peon, Simone Bordet and Tobias Oberstein. Note that Thorson, Roberto Peon, Simone Bordet and Tobias Oberstein. Note that
people listed above didn't necessarily endorse the end result of this people listed above didn't necessarily endorse the end result of this
work. work.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011. RFC 6455, December 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for [LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for
Sequential Data Compression", IEEE Transactions on Sequential Data Compression", IEEE Transactions on
Information Theory, Vol. 23, No. 3, pp. 337-343. Information Theory, Vol. 23, No. 3, pp. 337-343.
12.2. Informative References 12.2. Informative References
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[RFC1979] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996. [RFC1979] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
[Zlib] Gailly, J. and M. Adler, "Zlib", <http://zlib.net/>. [Zlib] Gailly, J. and M. Adler, "Zlib", <http://zlib.net/>.
[CRIME] Rizzo, J. and T. Duong, "The CRIME attack", Ekoparty 2012, [CRIME] Rizzo, J. and T. Duong, "The CRIME attack", Ekoparty 2012,
September 2012. September 2012.
Author's Address Author's Address
Takeshi Yoshino Takeshi Yoshino
 End of changes. 22 change blocks. 
52 lines changed or deleted 100 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/