draft-ietf-hybi-permessage-compression-26.txt   draft-ietf-hybi-permessage-compression-27.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track August 6, 2015 Intended status: Standards Track August 6, 2015
Expires: February 7, 2016 Expires: February 7, 2016
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-26 draft-ietf-hybi-permessage-compression-27
Abstract Abstract
This document defines a framework for creating WebSocket extensions This document defines 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 WebSocket data messages on a per-message basis using parameters of WebSocket data messages on a per-message basis using parameters
negotiated during the opening handshake. This framework provides a negotiated during the opening handshake. This framework provides a
general method for applying a compression algorithm to the contents general method for applying a compression algorithm to the contents
of WebSocket messages. Each compression algorithm has to be defined of WebSocket messages. Each compression algorithm has to be defined
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 Augmented Backus-Naur Form (ABNF) notation of This document uses the Augmented 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 mechanisms that are underspecified or not defined at all in Extension mechanisms that are underspecified or not defined at all in
[RFC6455]. This terminology is effective only in this document and [RFC6455].
any other documents explicitly referring to this section.
"A data message" means a message consisting of Data Frames as defined "A data message" means a message consisting of Data Frames as defined
in Section 5.6 of [RFC6455]. in Section 5.6 of [RFC6455].
"A message payload (or payload of a message)" means the concatenation "A message payload (or payload of a message)" means the concatenation
of the payload data portion of all Data Frames (see Section 6.2 of of the payload data portion of all Data Frames (see Section 6.2 of
[RFC6455]) representing a single message. [RFC6455]) representing a single message.
"An extension in use next to extension X" means the extension listed "An extension in use next to extension X" means the extension listed
next to X in the "Sec-WebSocket-Extensions" header in the server's next to X in the "Sec-WebSocket-Extensions" header in the server's
skipping to change at page 8, line 29 skipping to change at page 8, line 29
need to be exactly the same as those of the received extension need to be exactly the same as those of the received extension
negotiation offers. For example, suppose that a server received a negotiation offers. For example, suppose that a server received a
PMCE extension negotiation offer with an extension parameter "X" PMCE extension negotiation offer with an extension parameter "X"
indicating that the client can enable an optional feature named X. indicating that the client can enable an optional feature named X.
The server may accept the PMCE offer with an element without the The server may accept the PMCE offer with an element without the
extension parameter "X" meaning that the server chose not to enable extension parameter "X" meaning that the server chose not to enable
the feature X. In this case, the offer contains the extension the feature X. In this case, the offer contains the extension
parameter "X" but the "agreed parameters" don't contain the extension parameter "X" but the "agreed parameters" don't contain the extension
parameter "X". parameter "X".
"Agreed parameters" MUST represent how the requests and hints in the "Agreed parameters" must represent how the requests and hints in the
client's extension negotiation offer have been handled in addition to client's extension negotiation offer have been handled in addition to
the server's requests and hints on the client's behavior, so that the the server's requests and hints on the client's behavior, so that the
client can configure its behavior without identifying exactly which client can configure its behavior without identifying exactly which
PMCE extension negotiation offer has been accepted. PMCE extension negotiation offer has been accepted.
For example, if a client sends an extension negotiation offer that For example, if a client sends an extension negotiation offer that
includes a parameter "enable_compression" and another without this includes a parameter "enable_compression" and another without this
parameter, the server accepts the former and informs the client by parameter, the server accepts the former and informs the client by
sending back an element that includes parameter(s) acknowledging sending back an element that includes parameter(s) acknowledging
"enable_compression". The name of the acknowledging parameter "enable_compression". The name of the acknowledging parameter
skipping to change at page 10, line 40 skipping to change at page 10, line 40
algorithm foo and bar. algorithm foo and bar.
o Offer the permessage-foo. o Offer the permessage-foo.
permessage-foo permessage-foo
o Offer the permessage-foo with a parameter x with a value of 10. o Offer the permessage-foo with a parameter x with a value of 10.
permessage-foo; x=10 permessage-foo; x=10
The value MAY be quoted. The value may be quoted.
permessage-foo; x="10" permessage-foo; x="10"
o Offer the permessage-foo as first choice and the permessage-bar as o Offer the permessage-foo as first choice and the permessage-bar as
a fallback plan. a fallback plan.
permessage-foo, permessage-bar permessage-foo, permessage-bar
o Offer the permessage-foo with a parameter use_y which enables a o Offer the permessage-foo with a parameter use_y which enables a
feature y as first choice, and the permessage-foo without the feature y as first choice, and the permessage-foo without the
skipping to change at page 16, line 24 skipping to change at page 16, line 24
o The negotiation response contains an extension parameter with an o The negotiation response contains an extension parameter with an
invalid value. invalid value.
o The negotiation response contains multiple extension parameters o The negotiation response contains multiple extension parameters
with the same name. with the same name.
o The client does not support the configuration that the response o The client does not support the configuration that the response
represents. represents.
The term "LZ77 sliding window" used in this section means the buffer The term "LZ77 sliding window" [LZ77] used in this section means the
used by the DEFLATE algorithm to store recently processed input. The buffer used by the DEFLATE algorithm to store recently processed
DEFLATE compression algorithm searches the buffer for a match with input. The DEFLATE compression algorithm searches the buffer for a
the following input. match with the following input.
The term "use context take over" used in this section means that the The term "use context take over" used in this section means that the
same LZ77 sliding window used by the endpoint to build frames of the same LZ77 sliding window used by the endpoint to build frames of the
previous sent message is reused to build frames of the next message previous sent message is reused to build frames of the next message
to be sent. to be sent.
7.1. Extension Parameters 7.1. Extension Parameters
7.1.1. Context Takeover Control 7.1.1. Context Takeover Control
skipping to change at page 26, line 37 skipping to change at page 26, line 37
The first 3 octets (0xf2 0x48 0x05) and the least significant two The first 3 octets (0xf2 0x48 0x05) and the least significant two
bits of the 4th octet (0x00) constitute one DEFLATE block with bits of the 4th octet (0x00) constitute one DEFLATE block with
"BFINAL" set to 0 and "BTYPE" set to 01 containing "He". The rest of "BFINAL" set to 0 and "BTYPE" set to 01 containing "He". The rest of
the 4th octet contains the header bits with "BFINAL" set to 0 and the 4th octet contains the header bits with "BFINAL" set to 0 and
"BTYPE" set to 00, and the 3 padding bits of 0. Together with the "BTYPE" set to 00, and the 3 padding bits of 0. Together with the
following 4 octets (0x00 0x00 0xff 0xff), the header bits constitute following 4 octets (0x00 0x00 0xff 0xff), the header bits constitute
an empty DEFLATE block with no compression. A DEFLATE block an empty DEFLATE block with no compression. A DEFLATE block
containing "llo" follows the empty DEFLATE block. containing "llo" follows the empty DEFLATE block.
7.2.3.6. Generating an Empty Fragment Manually 7.2.3.6. Generating an Empty Fragment
Suppose that an endpoint is sending data of unknown size. The Suppose that an endpoint is sending data of unknown size. The
endpoint may encounter the end of data signal from the data source endpoint may encounter the end of data signal from the data source
when its buffer for uncompressed data is empty. In such a case, the when its buffer for uncompressed data is empty. In such a case, the
endpoint just needs to send the last fragment with FIN bit set to 1 endpoint just needs to send the last fragment with FIN bit set to 1
and payload set to DEFLATE block(s) which contains 0 bytes of data. and payload set to DEFLATE block(s) which contains 0 bytes of data.
If the compression library being used doesn't generate any data when If the compression library being used doesn't generate any data when
its buffer is empty, an empty uncompressed DEFLATE block can be built its buffer is empty, an empty uncompressed DEFLATE block can be built
manually and used for this purpose as follows: and used for this purpose as follows:
0x00 0x00
The only octet 0x00 contains the header bits with "BFINAL" set to 0 The only octet 0x00 contains the header bits with "BFINAL" set to 0
and "BTYPE" set to 00, and 5 padding bits of 0. and "BTYPE" set to 00, and 5 padding bits of 0.
7.3. Implementation Notes 7.3. Implementation Notes
On most common software development platforms, the DEFLATE On most common software development platforms, the DEFLATE
compression library provides a method for aligning compressed data to compression library provides a method for aligning compressed data to
byte boundaries using an empty DEFLATE block with no compression. byte boundaries using an empty DEFLATE block with no compression.
For example, Zlib [Zlib] does this when "Z_SYNC_FLUSH" is passed to For example, Zlib [Zlib] does this when "Z_SYNC_FLUSH" is passed to
the deflate function. the deflate function.
Some platforms may provide only methods to output and process Some platforms may provide only methods to output and process
compressed data with a ZLIB header and an Adler-32 checksum. On such compressed data with a ZLIB header and an Adler-32 checksum. On such
platforms, developers need to write stub code to remove and platforms, developers need to write stub code to remove and
complement them manually. complement them by themselves.
To obtain a useful compression ratio, an LZ77 sliding window size of To obtain a useful compression ratio, an LZ77 sliding window size of
1,024 or more is RECOMMENDED. 1,024 or more is RECOMMENDED.
If a side disallows context takeover, its endpoint can easily figure If a side disallows context takeover, its endpoint can easily figure
out whether a certain message will be shorter if compressed or not. out whether a certain message will be shorter if compressed or not.
Otherwise, it's not easy to know whether future messages will benefit Otherwise, it's not easy to know whether future messages will benefit
from having a certain message compressed. Implementors may employ from having a certain message compressed. Implementors may employ
some heuristics to determine this. some heuristics to determine this.
skipping to change at page 31, line 25 skipping to change at page 31, line 25
[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.
[CRIME] Rizzo, J. and T. Duong, "The CRIME attack", Ekoparty 2012,
September 2012.
11.2. Informative References 11.2. Informative References
[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,
September 2012.
Author's Address Author's Address
Takeshi Yoshino Takeshi Yoshino
Google, Inc. Google, Inc.
Email: tyoshino@google.com Email: tyoshino@google.com
 End of changes. 10 change blocks. 
15 lines changed or deleted 14 lines changed or added

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