draft-ietf-hybi-permessage-compression-12.txt   draft-ietf-hybi-permessage-compression-13.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track July 29, 2013 Intended status: Standards Track October 8, 2013
Expires: January 30, 2014 Expires: April 11, 2014
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-12 draft-ietf-hybi-permessage-compression-13
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 January 30, 2014. This Internet-Draft will expire on April 11, 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 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . 8
6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 11
7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 13
8. permessage-deflate extension . . . . . . . . . . . . . . . . . 13 8. permessage-deflate extension . . . . . . . . . . . . . . . . . 14
8.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 14 8.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 15
8.1.1. Context Takeover Control . . . . . . . . . . . . . . . 14 8.1.1. Context Takeover Control . . . . . . . . . . . . . . . 15
8.1.2. Limiting the LZ77 sliding window size . . . . . . . . 15 8.1.2. Limiting the LZ77 sliding window size . . . . . . . . 16
8.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17 8.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Message Payload Transformation . . . . . . . . . . . . . . 18 8.2. Message Payload Transformation . . . . . . . . . . . . . . 19
8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 18 8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 19
8.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 19 8.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 20
8.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 20 8.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 23 8.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 24
8.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 23 8.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Registration of the "permessage-deflate" WebSocket 10.1. Registration of the "permessage-deflate" WebSocket
Extension Name . . . . . . . . . . . . . . . . . . . . . . 25 Extension Name . . . . . . . . . . . . . . . . . . . . . . 26
10.2. Registration of the "Per-message Compressed" WebSocket 10.2. Registration of the "Per-message Compressed" WebSocket
Framing Header Bit . . . . . . . . . . . . . . . . . . . . 25 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
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 3, line 34 skipping to change at page 3, line 34
preferred one or decline all of them. PMCEs use the RSV1 bit of the preferred one or decline all of them. PMCEs use the RSV1 bit of the
WebSocket frame header to indicate whether a message is compressed or WebSocket frame header to indicate whether a message is compressed or
not, so that an endpoint can choose not to compress messages with not, so that an endpoint can choose not to compress messages with
incompressible contents. incompressible contents.
This document also specifies one specific PMCE based on the DEFLATE This document also specifies one specific PMCE based on the DEFLATE
[RFC1951] algorithm. The extension name of the PMCE is "permessage- [RFC1951] algorithm. The extension name of the PMCE is "permessage-
deflate". We chose DEFLATE since it's widely available as a library deflate". We chose DEFLATE since it's widely available as a library
on various platforms and the overhead is small. To align the end of on various platforms and the overhead is small. To align the end of
compressed data to an octet boundary, this extension uses the compressed data to an octet boundary, this extension uses the
algorithm described in Section 2.1 of the PPP Deflate Protocol algorithm described in Section 2.1 of [RFC1979]. Endpoints can take
[RFC1979]. Endpoints can take over the LZ77 sliding window [LZ77] over the LZ77 sliding window [LZ77] used to build frames for previous
used to build frames for previous messages to get better compression messages to get better compression ratio. For resource-limited
ratio. For resource-limited devices, this extension provides devices, this extension provides parameters to limit memory usage for
parameters to limit memory usage for compression context. compression context.
2. Conformance Requirements and Terminology 2. Conformance Requirements and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Requirements phrased in the imperative as part of algorithms (such as Requirements phrased in the imperative as part of algorithms (such as
"strip any leading space characters" or "return false and abort these "strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word steps") are to be interpreted with the meaning of the key word
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
behavior of both the server and the client so that it's unnecessary
to identify which offer has been accepted. For example, if a client
sends an offer with a parameter "enable_compression" and another
without the parameter, the server 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.
There can be compression features that can be applied separately for
each direction. For such features, the acknowledging parameter and
the parameter for the reverse direction must be chosen to be
distinguishable from each other. For example, we can add "s2c_"
prefix to parameters affecting data sent from a server and "c2s_"
prefix to ones affecting data sent form a client to make them
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:
o The extension requires boundary of fragments to be preserved o The extension requires boundary of fragments to be preserved
skipping to change at page 23, line 22 skipping to change at page 24, line 22
containing "llo" follows the empty DEFLATE block. containing "llo" follows the empty DEFLATE block.
8.3. Implementation Notes 8.3. Implementation Notes
On most common software development platforms, their DEFLATE On most common software development platforms, their DEFLATE
compression library provides a method to align compressed data to compression library provides a method to align 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
compressed data with ZLIB header and Adler-32 checksum. On such
platforms, developers need to write stub code to remove and
complement them manually.
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.
On the direction where context takeover is disallowed, an endpoint On the direction where context takeover is disallowed, an endpoint
can easily figure out whether a certain message will be shorter if can easily figure out whether a certain message will be shorter if
compressed or not.. Otherwise, it's not easy to know whether future compressed or not.. Otherwise, it's not easy to know whether future
messages will benefit from having a certain message compressed. messages will benefit from having a certain message compressed.
Implementor may employ some heuristics to determine this. Implementor may employ some heuristics to determine this.
8.4. Intermediaries 8.4. Intermediaries
 End of changes. 9 change blocks. 
33 lines changed or deleted 55 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/