Skip to main content

Shepherd writeup
draft-ietf-hybi-permessage-compression

Salvatore Loreto is the document shepherd
Barry Leiba is the responsible Area Director.

We intend to publish the draft-ietf-hybi-permessage-compression-21 as a
Proposed Standard as clearly indicate in the title page. This document
standardize a WebSocket Protocol extension.

This document does not change the status of any existing RFCs.
All references within this document have been identified as either normative or
informative.

The IANA considerations section has been reviewed by the Shepherd, all the
protocol protocol extensions are associated with the appropriate reservations
in IANA registries. Any referenced IANA registries have been clearly
identified. There are no  newly created IANA registries in this document.

The author has confirmed conformance with BCPs 78 and 79.

Technical Summary
   This document defines a framework for creating WebSocket extensions
   that adds compression functionality to the WebSocket Protocol allowing
  to compresses the payload data portion of WebSocket data messages
   on a per-message basis using parameters negotiated during the opening
   handshake. The document also defines one specific compression extension
   using the DEFLATE algorithm.

Working Group Summary

The Compression extension has been discussed extensively within
the HyBi almost since the beginning of the WebSocket
standardization process, however at the time the wg decided, in
order to speed up the process and not increase even more the
discussion, not to standardize any extension in the main
WebSocket spec but postpone all of them. The initial version of
the draft was based on per-frame compression, but then in IETF84
meeting, in Vancouver, the HyBi WG discussed the change from
per-frame to per-message compression
(http://www.ietf.org/mail-archive/web/hybi/current/msg09729.html).
The chairs sensed the WG’s consensus in the room to go ahead with
this change (http://www.ietf.org/mail-archive/web/hybi/current/msg09816.html)

The wg hasn't faced any significant point of difficulty or controversial and
the current version has received a solid consensus from the wg.

The permessage compression extension (as described in the
draft-ietf-hybi-permessage-compression-21) has been already implemented in
Chrome, Jetty and other running websocket stacks.

Document Quality
---------------------
The previous versions of the document was quite cryptic  in several part making
really difficult to be easily read and understood by people not completely
familiar with the WebSocket protocol and people who didn't follow the technical
discussion in the mailing list. There has been a large effort to improve the
document from editorial point of view helping the authors with people having
the English as native language.

While there has been quite a lot of energy during the technical discussion
in the last year the wg has lost energy and has been quite a challenge to find
people to commit on review the document and finalize it from and editorial
point of view. Mainly due to the fact people have been busy with the definition
of HTTP/2 standard and more interested to discuss how to define WebSocket over
HTTP/2 then to spend time on polishing the previous specifications. The
shepherd has worked with the authors and another couple of volunteers from the
working group
 to help the author to polish the draft.

The shepherd does not have any concerns about the depth of the reviews that
have been performed.

Other Points
--------------
The draft reference as Informative: RFC1951 "DEFLATE Compressed
Data Format Specification version 1.3" that appear in the DOWNREF
registry.
The NIT check also list the following warning:

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).

     Found 'MUST not' in this paragraph:

     A server declining all offered PMCEs MUST not include any element
     with PMCE names.  If a server responds with no PMCE element in the
     "Sec-WebSocket-Extensions" header, both endpoints proceed without
     Per-message Compression once _the WebSocket Connection is established_.

Back