draft-ietf-hybi-permessage-compression-22.txt   draft-ietf-hybi-permessage-compression-23.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track June 11, 2015 Intended status: Standards Track June 24, 2015
Expires: December 13, 2015 Expires: December 26, 2015
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-22 draft-ietf-hybi-permessage-compression-23
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 1, line 42 skipping to change at page 1, line 42
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 December 13, 2015. This Internet-Draft will expire on December 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 6, line 25 skipping to change at page 6, line 25
o The extension name of the PMCE and any applicable extension o The extension name of the PMCE and any applicable extension
parameters that MUST be included in the "Sec-WebSocket-Extensions" parameters that MUST be included in the "Sec-WebSocket-Extensions"
header during the extension negotiation offer/response. header during the extension negotiation offer/response.
o How to interpret the extension parameters exchanged during the o How to interpret the extension parameters exchanged during the
opening handshake. opening handshake.
o How to transform the payload of a message. o How to transform the payload of a message.
One PMCE extension is defined in Section 8 of this document and is One PMCE is defined in Section 8 of this document and is registered
registered in Section 10. Other PMCEs may be defined in the future in Section 10. Other PMCEs may be defined in the future in other
in other documents. documents.
Section 5 describes the basic extension negotiation process. Section 5 describes the basic extension negotiation process.
Section 6 describes how to apply the compression algorithm with Section 6 describes how to apply the compression algorithm with
negotiated parameters to the contents of WebSocket messages. negotiated parameters to the contents of WebSocket messages.
5. Extension Negotiation 5. Extension Negotiation
To offer use of a PMCE, a client MUST include the extension name of To offer use of a PMCE, a client MUST include the extension name of
the PMCE in the "Sec-WebSocket-Extensions" header field of its the PMCE in the "Sec-WebSocket-Extensions" header field of its
opening handshake of the WebSocket connection. Extension parameters opening handshake of the WebSocket connection. Extension parameters
skipping to change at page 7, line 50 skipping to change at page 7, line 50
A hint in a PMCE negotiation offer provides information about the A hint in a PMCE negotiation offer provides information about the
client's behavior that the server may either safely ignore or refer client's behavior that the server may either safely ignore or refer
to when the server decides its behavior. For example, suppose that a to when the server decides its behavior. For example, suppose that a
client sends data compressed with the DEFLATE algorithm to a server. client sends data compressed with the DEFLATE algorithm to a server.
The client must keep the original bytes of data that it recently The client must keep the original bytes of data that it recently
compressed and sent to the server. The server must keep the result compressed and sent to the server. The server must keep the result
of decompressing the bytes of data that it recently received from the of decompressing the bytes of data that it recently received from the
client. The LZ77 window size of the server must not be less than the client. The LZ77 window size of the server must not be less than the
LZ77 window size of the client. In a PMCE negotiation offer, the LZ77 window size of the client. In a PMCE negotiation offer, the
client may inform the maximum LZ77 window size the client can afford client MAY inform the maximum LZ77 window size the client can afford
so that the server can choose to use an LZ77 window size that is not so that the server can choose to use an LZ77 window size that is not
greater than the maximum size of the client. This information is an greater than the maximum size of the client. This information is an
example of a hint in a PMCE negotiation offer. It's waste of memory example of a hint in a PMCE negotiation offer. It's waste of memory
to use an LZ77 window size greater than the LZ77 window size the to use an LZ77 window size greater than the LZ77 window size the
client actually uses. Using the hint, the server can avoid the waste client actually uses. Using the hint, the server can avoid the waste
of memory. Since the hint itself doesn't specify the constraints on of memory. Since the hint itself doesn't specify the constraints on
the endpoints, the server must use the "agreed parameters" (defined the endpoints, the server must use the "agreed parameters" (defined
below) to explicitly ask the client not to use an LZ77 window size below) to explicitly ask the client not to use an LZ77 window size
greater than the LZ77 window size of the server. greater than the LZ77 window size of the server.
skipping to change at page 12, line 43 skipping to change at page 12, line 43
An endpoint MUST use the following algorithm to send a message in the An endpoint MUST use the following algorithm to send a message in the
form of a compressed message. form of a compressed message.
1. Compress the message payload of the original message by following 1. Compress the message payload of the original message by following
the compression procedure of the PMCE. The original message may the compression procedure of the PMCE. The original message may
be input from the application layer or output of another be input from the application layer or output of another
WebSocket extension depending on which extensions were WebSocket extension depending on which extensions were
negotiated. negotiated.
2. If this PMCE is the last extension to process of outgoing 2. Process the compressed data as follows:
messages, build frame(s) by using the compressed data instead of
the original data for the message payload, and set the * If this PMCE is the last extension to process of outgoing
"Per-message Compressed" bit of the first frame, then send the messages, build frame(s) by using the compressed data instead
frame(s) as described in Section 6.1 of RFC6455. Otherwise, pass of the original data for the message payload, and set the
the transformed message payload and modified header values "Per-message Compressed" bit of the first frame, then send the
including the "Per-message Compressed" bit value set to 1 to the frame(s) as described in Section 6.1 of RFC6455.
extension next to the PMCE. If the extension expects frames for
input, build a frame for the message and pass it. * Otherwise, pass the transformed message payload and modified
header values including the "Per-message Compressed" bit value
set to 1 to the extension next to the PMCE. If the extension
expects frames for input, build a frame for the message and
pass it.
An endpoint MUST use the following algorithm to send a message in the An endpoint MUST use the following algorithm to send a message in the
form of an uncompressed message. form of an uncompressed message.
1. If this PMCE is the last extension to process of outgoing 1. Process the original data as follows:
messages, build frame(s) by using the original data for the
payload data portion as-is and unset the "Per-message Compressed" * If this PMCE is the last extension to process of outgoing
bit of the first frame, then send the frame(s) as described in messages, build frame(s) by using the original data for the
Section 6.1 of RFC6455. Otherwise, pass the message payload and payload data portion as-is and unset the "Per-message
header values to the extension next to the PMCE as-is. If the Compressed" bit of the first frame, then send the frame(s) as
extension expects frames for input, build a frame for the message described in Section 6.1 of RFC6455.
and pass it.
* Otherwise, pass the message payload and header values to the
extension next to the PMCE as-is. If the extension expects
frames for input, build a frame for the message and pass it.
An endpoint MUST NOT set the "Per-message Compressed" bit of control An endpoint MUST NOT set the "Per-message Compressed" bit of control
frames and non-first fragments of a data message. An endpoint frames and non-first fragments of a data message. An endpoint
receiving such a frame MUST _Fail the WebSocket Connection_. receiving such a frame MUST _Fail the WebSocket Connection_.
PMCEs do not change the opcode field. The opcode of the first frame PMCEs do not change the opcode field. The opcode of the first frame
of a compressed message indicates the opcode of the original message. of a compressed message indicates the opcode of the original message.
The payload data portion in frames generated by a PMCE is not subject The payload data portion in frames generated by a PMCE is not subject
to the constraints for the original data type. For example, the to the constraints for the original data type. For example, the
skipping to change at page 13, line 45 skipping to change at page 14, line 5
the form of a compressed message. the form of a compressed message.
1. Concatenate the payload data portion of the received frames of 1. Concatenate the payload data portion of the received frames of
the compressed message. The received frames may be direct input the compressed message. The received frames may be direct input
from the underlying transport or output of another WebSocket from the underlying transport or output of another WebSocket
extension depending on which extensions were negotiated. extension depending on which extensions were negotiated.
2. Decompress the concatenation by following the decompression 2. Decompress the concatenation by following the decompression
procedure of the PMCE. procedure of the PMCE.
3. If this is the last extension to process incoming messages, 3. Process the decompressed message as follows:
deliver the _A WebSocket Message Has Been Received_ event to the
application layer with the decompressed message payload and * If this is the last extension to process incoming messages,
header values including the "Per-message Compressed" bit unset to deliver the _A WebSocket Message Has Been Received_ event to
0. Otherwise, pass the decompressed message payload and header the application layer with the decompressed message payload
values including the "Per-message Compressed" bit unset to 0 to and header values including the "Per-message Compressed" bit
the extension preceding the PMCE. If the extension expects unset to 0.
frames for input, build a frame for the message and pass it.
* Otherwise, pass the decompressed message payload and header
values including the "Per-message Compressed" bit unset to 0
to the extension preceding the PMCE. If the extension expects
frames for input, build a frame for the message and pass it.
An endpoint MUST use the following algorithm to receive a message in An endpoint MUST use the following algorithm to receive a message in
the form of an uncompressed message. the form of an uncompressed message.
1. If this PMCE is the last extension to process incoming messages, 1. Process the received message as follows:
deliver the _A WebSocket Message Has Been Received_ event to the
application layer with the received message payload and header * If this PMCE is the last extension to process incoming
values as-is. Otherwise, pass the message payload and header messages, deliver the _A WebSocket Message Has Been Received_
values to the extension preceding the PMCE as-is. If the event to the application layer with the received message
extension expects frames for input, build a frame for the message payload and header values as-is.
and pass it.
* Otherwise, pass the message payload and header values to the
extension preceding the PMCE as-is. If the extension expects
frames for input, build a frame for the message and pass it.
7. Intermediaries 7. Intermediaries
When an intermediary proxies a WebSocket connection, the intermediary When an intermediary proxies a WebSocket connection, the intermediary
MAY add, change or remove Per-message Compression of proxied messages MAY add, change or remove Per-message Compression of proxied messages
if the intermediary meets all of the following requirements: if the intermediary meets all of the following requirements:
o The intermediary understands the PMCE. o The intermediary understands the PMCE.
o The intermediary can read all data of the proxied WebSocket o The intermediary can read all data of the proxied WebSocket
skipping to change at page 22, line 51 skipping to change at page 22, line 51
o When any DEFLATE block with the "BFINAL" bit set to 1 doesn't end o When any DEFLATE block with the "BFINAL" bit set to 1 doesn't end
at a byte boundary, an endpoint MUST add minimal padding bits of 0 at a byte boundary, an endpoint MUST add minimal padding bits of 0
to make it end at a byte boundary. The next DEFLATE block follows to make it end at a byte boundary. The next DEFLATE block follows
the padded data if any. the padded data if any.
An endpoint fragments a compressed message by splitting the result of An endpoint fragments a compressed message by splitting the result of
running this algorithm. Even when only part of the payload is running this algorithm. Even when only part of the payload is
available, a fragment can be built by compressing the available data available, a fragment can be built by compressing the available data
and choosing the block type appropriately so that the end of the and choosing the block type appropriately so that the end of the
resulting compressed data is aligned at a byte boundary. Note that resulting compressed data is aligned at a byte boundary. Note that
for non-final fragments, the removal of 0x00 0x00 0xff 0xff must not for non-final fragments, the removal of 0x00 0x00 0xff 0xff MUST NOT
be done. be done.
An endpoint MUST NOT use an LZ77 sliding window longer than 32,768 An endpoint MUST NOT use an LZ77 sliding window longer than 32,768
bytes to compress messages to send. bytes to compress messages to send.
If the "agreed parameters" contain the "client_no_context_takeover" If the "agreed parameters" contain the "client_no_context_takeover"
extension parameter, the client MUST start compressing each new extension parameter, the client MUST start compressing each new
message with an empty LZ77 sliding window. Otherwise, the client MAY message with an empty LZ77 sliding window. Otherwise, the client MAY
take over the LZ77 sliding window used to build the last compressed take over the LZ77 sliding window used to build the last compressed
message. Note that even if the client has included the message. Note that even if the client has included the
skipping to change at page 30, line 41 skipping to change at page 30, line 41
This section describes a WebSocket framing header bit registration in This section describes a WebSocket framing header bit registration in
the WebSocket Framing Header Bits Registry [RFC6455]. the WebSocket Framing Header Bits Registry [RFC6455].
Header Bit Header Bit
RSV1 RSV1
Common Name Common Name
Per-message Compressed Per-message Compressed
Meaning Meaning
The message is compressed or not. The message is compressed or not. RSV1 is set for compressed
messages and unset for uncompressed messages.
Reference Reference
Section 6 of this document. Section 6 of this document.
The "Per-message Compressed" framing header bit is used on the first The "Per-message Compressed" framing header bit is used on the first
fragment of data messages to indicate whether the payload of the fragment of data messages to indicate whether the payload of the
message is compressed by the PMCE or not. message is compressed by the PMCE or not.
11. Acknowledgements 11. Acknowledgements
Special thanks to Patrick McManus who wrote up the initial Special thanks to Patrick McManus who wrote up the initial
specification of a DEFLATE-based compression extension for the specification of a DEFLATE-based compression extension for the
WebSocket Protocol to which I referred to write this specification. WebSocket Protocol to which I referred to write this specification.
Thank you to the following people who participated in discussions on Thanks to the following people who participated in discussions on the
the HyBi WG and contributed ideas and/or provided detailed reviews HyBi WG and contributed ideas and/or provided detailed reviews (the
(the list is likely to be incomplete): Adam Rice, Alexander list is likely to be incomplete): Adam Rice, Alexander Philippou,
Philippou, Alexey Melnikov, Arman Djusupov, Bjoern Hoehrmann, Brian Alexey Melnikov, Arman Djusupov, Bjoern Hoehrmann, Brian McKelvey,
McKelvey, Dario Crivelli, Greg Wilkins, Inaki Baz Castillo, Jamie Dario Crivelli, Greg Wilkins, Inaki Baz Castillo, Jamie Lokier,
Lokier, Joakim Erdfelt, John A. Tamplin, Julian Reschke, Kenichi Joakim Erdfelt, John A. Tamplin, Julian Reschke, Kenichi Ishibashi,
Ishibashi, Mark Nottingham, Peter Thorson, Roberto Peon, Salvatore Mark Nottingham, Peter Thorson, Roberto Peon, Salvatore Loreto,
Loreto, Simone Bordet, Tobias Oberstein and Yutaka Hirano. Note that Simone Bordet, Tobias Oberstein and Yutaka Hirano. Note that people
people listed above didn't necessarily endorse the end result of this 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 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. 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.
 End of changes. 12 change blocks. 
52 lines changed or deleted 66 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/