< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/