draft-ietf-hybi-permessage-compression-20.txt   draft-ietf-hybi-permessage-compression-21.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track March 24, 2015 Intended status: Standards Track April 15, 2015
Expires: September 25, 2015 Expires: October 17, 2015
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-20 draft-ietf-hybi-permessage-compression-21
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 September 25, 2015. This Internet-Draft will expire on October 17, 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 7, line 35 skipping to change at page 7, line 35
A request in a PMCE negotiation offer indicates constraints on the A request in a PMCE negotiation offer indicates constraints on the
server's behavior that must be satisfied if the server accepts the server's behavior that must be satisfied if the server accepts the
offer. For example, suppose that a server sends data compressed with offer. For example, suppose that a server sends data compressed with
the DEFLATE algorithm to a client. The server must keep the original the DEFLATE algorithm to a client. The server must keep the original
bytes of data that it recently compressed and sent to the client. bytes of data that it recently compressed and sent to the client.
The client must keep the result of decompressing the bytes of data The client must keep the result of decompressing the bytes of data
that it recently received from the server. The amount of bytes of that it recently received from the server. The amount of bytes of
data kept is called the LZ77 window size. The LZ77 window size of data kept is called the LZ77 window size. The LZ77 window size of
the client must not be less than the LZ77 window size of the server. the client must not be less than the LZ77 window size of the server.
In a PMCE negotiation offer, the client must inform the server of its In a PMCE negotiation offer, the client MUST inform the server of its
LZ77 window size so that the server uses an LZ77 window size that is LZ77 window size so that the server uses an LZ77 window size that is
not greater than the LZ77 window size of the client. This not greater than the LZ77 window size of the client. This
restriction on the LZ77 window size is an example of a request in a restriction on the LZ77 window size is an example of a request in a
PMCE negotiation offer. PMCE negotiation offer.
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 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.
To accept the use of an offered PMCE, a server MUST include the To accept the use of an offered PMCE, a server MUST include the
 End of changes. 5 change blocks. 
6 lines changed or deleted 6 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/