draft-ietf-hybi-permessage-compression-27.txt   draft-ietf-hybi-permessage-compression-28.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 24, 2015
Expires: February 7, 2016 Expires: February 25, 2016
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-27 draft-ietf-hybi-permessage-compression-28
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 February 7, 2016. This Internet-Draft will expire on February 25, 2016.
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 5, line 18 skipping to change at page 5, line 18
Extension mechanisms that are underspecified or not defined at all in Extension mechanisms that are underspecified or not defined at all in
[RFC6455]. [RFC6455].
"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 "The next extension in use after extension X" means the next
next to X in the "Sec-WebSocket-Extensions" header in the server's extension listed after X in the "Sec-WebSocket-Extensions" header in
opening handshake as defined in Section 9.1 of [RFC6455]. Such an the server's opening handshake as defined in Section 9.1 of
extension is applied to outgoing data from the application right [RFC6455]. Such an extension is applied to outgoing data from the
after X on the sender side, but applied right before X to incoming application right after X on the sender side, but applied right
data from the underlying transport. before X to incoming data from the underlying transport.
"An extension in use preceding extension X" means the extension "An extension in use preceding extension X" means the extension
listed right before X in the "Sec-WebSocket-Extensions" header in the listed right before X in the "Sec-WebSocket-Extensions" header in the
server's opening handshake. Such an extension is applied to outgoing server's opening handshake. Such an extension is applied to outgoing
data from the application right before X on the sender side, but data from the application right before X on the sender side, but
applied right after X to incoming data from the underlying transport. applied right after X to incoming data from the underlying transport.
"An extension negotiation offer" means each element in the "An extension negotiation offer" means each element in the
"Sec-WebSocket-Extensions" header in the client's opening handshake. "Sec-WebSocket-Extensions" header in the client's opening handshake.
skipping to change at page 13, line 4 skipping to change at page 13, line 4
2. Process the compressed data as follows: 2. Process the compressed data as follows:
* If this PMCE is the last extension to process of outgoing * If this PMCE is the last extension to process of outgoing
messages, build frame(s) by using the compressed data instead messages, build frame(s) by using the compressed data instead
of the original data for the message payload, and set the of the original data for the message payload, and set the
"Per-message Compressed" bit of the first frame, then send the "Per-message Compressed" bit of the first frame, then send the
frame(s) as described in Section 6.1 of RFC6455. frame(s) as described in Section 6.1 of RFC6455.
* Otherwise, pass the transformed message payload and modified * Otherwise, pass the transformed message payload and modified
header values including the "Per-message Compressed" bit value header values including the "Per-message Compressed" bit value
set to 1 to the extension next to the PMCE. If the extension set to 1 to the next extension after the PMCE. If the
expects frames for input, build a frame for the message and extension expects frames for input, build a frame for the
pass it. 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. Process the original data as follows: 1. Process the original data as follows:
* If this PMCE is the last extension to process of outgoing * If this PMCE is the last extension to process of outgoing
messages, build frame(s) by using the original data for the messages, build frame(s) by using the original data for the
payload data portion as-is and unset the "Per-message payload data portion as-is and unset the "Per-message
Compressed" bit of the first frame, then send the frame(s) as Compressed" bit of the first frame, then send the frame(s) as
described in Section 6.1 of RFC6455. described in Section 6.1 of RFC6455.
* Otherwise, pass the message payload and header values to the * Otherwise, pass the message payload and header values to the
extension next to the PMCE as-is. If the extension expects next extension after the PMCE as-is. If the extension expects
frames for input, build a frame for the message and pass it. 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
 End of changes. 6 change blocks. 
14 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/