Skip to main content

Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-28

Revision differences

Document history

Date Rev. By Action
2015-12-03
28 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-12-02
28 (System) RFC Editor state changed to AUTH48 from AUTH48-DONE
2015-11-24
28 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-11-12
28 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-10-27
28 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-10-14
28 (System) Notify list changed from hybi-chairs@ietf.org, draft-ietf-hybi-permessage-compression@ietf.org, "Salvatore Loreto"  to (None)
2015-09-04
28 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-09-04
28 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2015-09-04
28 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-09-03
28 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-09-02
28 (System) RFC Editor state changed to EDIT
2015-09-02
28 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-09-02
28 (System) Announcement was received by RFC Editor
2015-09-01
28 (System) IANA Action state changed to In Progress
2015-09-01
28 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-09-01
28 Amy Vezza IESG has approved the document
2015-09-01
28 Amy Vezza Closed "Approve" ballot
2015-09-01
28 Amy Vezza Ballot approval text was generated
2015-09-01
28 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-08-24
28 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-28.txt
2015-08-13
27 Stephen Farrell
[Ballot comment]

I had a discuss that said:

"The secdir reviewer's comment about modifying the signalling
seems to me to be something that the hybi …
[Ballot comment]

I had a discuss that said:

"The secdir reviewer's comment about modifying the signalling
seems to me to be something that the hybi WG needs to have
debated. Did that happen?"

I'm told by the secdir reviewer that that discussion has now
happened and indeed the text on intermediaries has been
removed which resolves the issue, so I've cleared.
2015-08-13
27 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2015-08-06
27 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-27.txt
2015-08-06
26 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-26.txt
2015-08-06
25 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-08-06
25 Takeshi Yoshino IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-08-06
25 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-25.txt
2015-07-09
24 Amy Vezza IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2015-07-09
24 Stephen Farrell
[Ballot discuss]

The secdir reviewer's comment about modifying the signalling
seems to me to be something that the hybi WG needs to have
debated. Did …
[Ballot discuss]

The secdir reviewer's comment about modifying the signalling
seems to me to be something that the hybi WG needs to have
debated. Did that happen?
2015-07-09
24 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2015-07-09
24 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-07-08
24 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-07-08
24 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-07-08
24 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-07-08
24 Spencer Dawkins [Ballot comment]
I support both of Ben's comments that mention intermediaries.
2015-07-08
24 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-07-07
24 Joel Jaeggli
[Ballot comment]
warren kumari's opsdir review (no further action required)



Be ye not afraid.

I have reviewed this document as part of the Operational directorate's …
[Ballot comment]
warren kumari's opsdir review (no further action required)



Be ye not afraid.

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Document reviewed:  draft-ietf-hybi-permessage-compression-22

Summary: Ready, no nits, no comments.


Details:
Well, this is a first -- I have never before performed a review
without finding at least some nits (typos, grammar, etc).

Because I feel bad about not having *any* comments I'll scrape the
bottom of the barrel -- I find the use of underscores jarring in e.g:
'This document references the procedure to _Fail the WebSocket
Connection_. ' and think these could be replaced with quotes instead.
I'll fully admit this is bikeshedding.

Oh, the title on Section 8 also looks a little odd, was the 'p'
intended to be uppercase? Could go either way...

There are no operational impacts that I can see, other than less
traffic on the wire, and more code in network devices if any of them
are websocket servers or clients (e.g for management).


W


--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
  ---maf

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
2015-07-07
24 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-07-07
24 Ben Campbell
[Ballot comment]
*** Substantive Comments: ***

-- I think Robert Spark's secdir comments concerning an intermediary changing the signaling of extensions deserves some thought.

-- …
[Ballot comment]
*** Substantive Comments: ***

-- I think Robert Spark's secdir comments concerning an intermediary changing the signaling of extensions deserves some thought.

-- section 5, several example paragraphs:

It's odd to find normative language in example. I _think_ the actual normative text is all covered elsewhere--if so, it should be written descriptively here. 

-- section 5, paragraph 6: ""Agreed parameters" MUST represent..."

That seems more a statement of fact than a normative statement.  If it's intentionally normative, the required condition is vague for a MUST.

-- 6.1, Numbered list entry "2", third bullet (and several similar assertions)

Do I understand correctly that the PMCE needs to know if the next extension wants frames, in order to determine whether to build them? How would it know that?

-- 9:

I’m surprised that there’s nothing here about intermediaries. For example, if an endpoint chooses not to compress because of the mentioned issue with encrypting compressed data, does it have to worry that some intermediary might choose to compress it anyway?

-- 12.2, [CRIME]

Seems like this may need to be normative. I’m not sure the reader can fully understand the security considerations without reading it.

***Editorial Comments:***

-- Section 3, first paragraph, last sentence:

That seems true anytime a draft or RFC defines terms--what is special about these?

-- 3, third paragraph: "An extension in use next to extension"

The construction "next to" usually connotes adjacency, not order. I suggest "The next extension in use" (without the "to").

-- 8, 2nd to last paragraph:

While you cited the LZ77 bits earlier, it would be useful to repeat that citation here. This is where the information actually gets used.

-- 8.2.3.6:

It's odd to refer to anything done by a computer as "manual".
2015-07-07
24 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2015-07-07
24 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2015-07-07
24 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-07-07
24 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-07-06
24 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-07-06
24 Dan Romascanu Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu.
2015-07-06
24 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-07-02
24 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2015-07-02
24 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2015-06-25
24 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Robert Sparks.
2015-06-24
24 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-06-24
24 Barry Leiba Ballot has been issued
2015-06-24
24 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2015-06-24
24 Barry Leiba Created "Approve" ballot
2015-06-24
24 Barry Leiba Changed consensus to Yes from Unknown
2015-06-24
24 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-06-24
24 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-06-23
24 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-24.txt
2015-06-23
23 Takeshi Yoshino IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-06-23
23 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-23.txt
2015-06-23
22 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2015-06-23
22 Pearl Liang
(Via drafts-lastcall@iana.org): IESG/Author/WG Chairs:

IANA has reviewed draft-ietf-hybi-permessage-compression-22.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any …
(Via drafts-lastcall@iana.org): IESG/Author/WG Chairs:

IANA has reviewed draft-ietf-hybi-permessage-compression-22.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are two actions which must be completed.

First, in the WebSocket Extension Name subregistry of the WebSocket Protocol Registries located at:

http://www.iana.org/assignments/websocket/

a new extension name will be registered as follows:

Extension Identifier: permessage-deflate
Extension Common Name: WebSocket Per-message Deflate
Extension Definition: [ RFC-to-be ]
Known Incompatible Extensions: none
Reference: [ RFC-to-be ]

Second, in the WebSocket Framing Header Bits Registry also in the WebSocket Protocol Registries located at:

http://www.iana.org/assignments/websocket/

a new framing header bit will be registered as follows:

Value: RSV1
Description: The message is compressed or not.
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2015-06-23
22 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Warren Kumari.
2015-06-11
22 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2015-06-11
22 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2015-06-11
22 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Warren Kumari
2015-06-11
22 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Warren Kumari
2015-06-10
22 Tero Kivinen Request for Last Call review by SECDIR is assigned to Robert Sparks
2015-06-10
22 Tero Kivinen Request for Last Call review by SECDIR is assigned to Robert Sparks
2015-06-10
22 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-22.txt
2015-06-10
21 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-06-10
21 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Compression Extensions for WebSocket) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Compression Extensions for WebSocket) to Proposed Standard


The IESG has received a request from the BiDirectional or
Server-Initiated HTTP WG (hybi) to consider the following document:
- 'Compression Extensions for WebSocket'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a framework for creating WebSocket extensions
  that add compression functionality to the WebSocket Protocol.  An
  extension based on this framework compresses the payload data portion
  of WebSocket data messages on a per-message basis using parameters
  negotiated during the opening handshake.  This framework provides a
  general method for applying a compression algorithm to the contents
  of WebSocket messages.  Each compression algorithm has to be defined
  in a document defining the extension by specifying parameter
  negotiation and payload transformation algorithm in detail.  This
  document also specifies one specific compression extension using the
  DEFLATE algorithm.

  Please send feedback to the hybi@ietf.org mailing list.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression/ballot/


No IPR declarations have been submitted directly on this I-D.


2015-06-10
21 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-06-10
21 Barry Leiba Placed on agenda for telechat - 2015-07-09
2015-06-10
21 Barry Leiba Last call announcement was generated
2015-06-10
21 Barry Leiba Last call was requested
2015-06-10
21 Barry Leiba Last call announcement was generated
2015-06-10
21 Barry Leiba Ballot approval text was generated
2015-06-10
21 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2015-06-03
21 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2015-05-22
21 Barry Leiba IESG state changed to Publication Requested from AD is watching
2015-05-02
21 Salvatore Loreto IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2015-05-02
21 Salvatore Loreto
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 …
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_.

2015-04-28
21 Salvatore Loreto
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 …
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.
The last version is now meet the standard requested to become an RFC.

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_.

2015-04-28
21 Salvatore Loreto Notification list changed to hybi-chairs@ietf.org, draft-ietf-hybi-permessage-compression@ietf.org, "Salvatore Loreto" <Salvatore.Loreto@ericsson.com> from hybi-chairs@ietf.org, draft-ietf-hybi-permessage-compression@ietf.org
2015-04-28
21 Salvatore Loreto Document shepherd changed to Salvatore Loreto
2015-04-28
21 Salvatore Loreto IETF WG state changed to WG Consensus: Waiting for Write-Up from Submitted to IESG for Publication
2015-04-15
21 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-21.txt
2015-03-24
20 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-20.txt
2014-11-11
19 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-19.txt
2014-05-12
18 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-18.txt
2014-01-21
17 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-17.txt
2014-01-13
16 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-16.txt
2013-10-16
15 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-15.txt
2013-10-15
14 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-14.txt
2013-10-07
13 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-13.txt
2013-07-29
12 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-12.txt
2013-07-01
11 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-11.txt
2013-06-19
10 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-10.txt
2013-04-25
09 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-09.txt
2013-04-01
08 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-08.txt
2013-03-19
07 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-07.txt
2013-03-12
06 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-06.txt
2013-02-21
05 Barry Leiba
I'm afraid that I'm sending this back to the WG: I think it's not in
appropriate shape to ask the community and the IESG to …
I'm afraid that I'm sending this back to the WG: I think it's not in
appropriate shape to ask the community and the IESG to review and
accept it.  What I've read has been unclear, and I'm very much
concerned that implementors won't be able to follow it well enough to
implement it correctly.  See my (partial) review below; I stopped
after Section 3.

I'm asking the working group to do some careful review to make sure
that it's clear, understandable, and ready for people outside the
working group to implement.  Make sure everything holds together and
that someone who is NOT already familiar with how this works can still
understand and correctly implement it.  If the working group needs
more help with this, it can ask for it on apps-discuss.


-- General --

  [in various places...}
  _This section is non-normative._

  2. Conformance Requirements
  Everything in this specification except for sections explicitly
  marked non-normative is normative.

I understand that all of this corresponds to the same text in the
WebSockets document.  I can't tell you how much I dislike this style,
and I ask (but not demand) that you please consider removing it.  I'm
happy to discuss this.

I believe you need to be clear from the language you use (and I don't
just mean MUST and SHOULD) when something is not normative.  Calling
things "examples" already conveys this.  Section titles such as
"Introduction" conveys this.  Most documents manage without this sort
of thing.  Why does WebSockets (and its successor documents, such as
this one) need it?

-- Introduction --

  The simplest "Sec-WebSocket-Extensions" header in the client's
  opening handshake to request permessage-deflate is the following:

      Sec-WebSocket-Extensions: permessage-deflate

  The simplest header from the server to accept this extension is the
  same.

Why is this in the Introduction?  It seems seriously out of place there.

-- Section 3 --

I find the organization of this to be awkward.  The first paragraph
doesn't make much sense to me, for one thing.  I suggest two things to
start with:

1. Change the overall document title:

OLD
WebSocket Per-message Compression

NEW
WebSocket Per-message Compression Extension Framework

That better explains what the document is specifying (the abbreviated
title can remain "WebSocket Per-message Compression"), and means that
the last sentence of the first paragraph of Section 3 can be removed.
For the rest of the paragraph, how about this (I'm also pulling up
something from the paragraphs below)?:

NEW
  Per-Message Compression Extensions (PMCEs) are individually
  defined, and are registered in the WebSocket Extension Name
  Registry.  One such extension is defined in Section 5 of this
  document and is registered in Section 7.1.  Other PMCEs may
  be defined in other documents.  Each PMCE defines the content
  of its extension token, including any applicable extension
  parameters.
END

Note that you now have an abbreviation (PMCE) that you can use freely.

Second paragraph:

  To request use of a Per-message Compression Extension, a client MUST
  include an element with its extension token in the
  "Sec-WebSocket-Extensions" header in its opening handshake.

You should avoid a lot of "it"s, unless the antecedent is quite clear.
Here, the antecedents are not clear.  It looks like "its extension
token" means "the client's extension token," and it looks like "its
opening handshake" means "the S-WS-E header's opening handshake," or
perhaps "the token's opening handshake."

Also, is the client "requesting" use of one particular PMCE, or
"offering" a list of PMCEs?  It seems to me that it's the latter: the
client offers a list, and the server selects zero or one from the list
and sends it in the response.  Yes?

  The
  element contains extension parameters as specified by the
  specification of the extension.

This loops around in a circle, and is hard to make sense of.

  A client MAY list multiple Per-
  message Compression Extensions with the same name to offer use of the
  same algorithm with different configurations.

May a client also list multiple extensions with *different* names?

How about this for the whole paragraph?:

NEW
  To offer use of a PMCE, a client MUST include an element with the
  offered extension's token in the "Sec-WebSocket-Extensions" header
  in the opening handshake of the WebSocket connection.  A client
  offers multiple PMCE choices to the server by including multiple
  tokens, one for each PMCE offered.  The set of tokens MAY include
  multiple PMCEs with the same name to offer use of the same
  algorithm with different configurations.
END

Please look for other "it" occurrences, and make sure they're similarly clear.

Similarly, for the third paragraph, maybe this?:

NEW
  To accept use of a PMCE, a server MUST include an element with the
  accepted extension token in the "Sec-WebSocket-Extensions" header in
  the opening handshake of the WebSocket connection.  The accepted
  token MUST be one of those offered by the client during the opening
  handshake, and MUST represent a PMCE that is fully supported by the
  server.  The server rejects all offered PMCEs by not including any
  PMCE tokens, in which case the connection proceeds without
  per-message compression.
END

Fourth paragraph:

  If a client doesn't support the extension and its parameters replied
  from the server, the client MUST _Fail the WebSocket Connection_.
  Otherwise, once _the WebSocket Connection is established_, both
  endpoints MUST use the algorithm described in Section 4 to exchange
  messages.

Why would a server respond with an extension/parameters that the
client doesn't support?  The client already sent a list of what it's
willing to use.  In the re-writes I've done above, that's made clear,
and this paragraph is, if anything, just specifying how to handle a
server response that's in violation of the protocol.  You also refer
to the Section 4 algorithm, but say nothing about what compression
mechanism will be used.  So maybe this?:

NEW
  * If the server responds with no PMCE tokens, once _the WebSocket
  Connection is established_ it proceeds without per-message
  compression.

  * If the server gives an invalid response, such as accepting a
  PMCE that the client did not offer, the client MUST _Fail the
  WebSocket Connection_.

  * Otherwise, once _the WebSocket Connection is established_, both
  endpoints MUST use the algorithm described in Section 4 to exchange
  messages, using the PMCE returned by the server.
OLD

By my reckoning, this has just re-written the entire Section 3.  This
bothers me, because it makes me question the level of review and
editing that the document has gone through.  As I look at Section 3.1,
I see that it appears to be inadequate: it is *not* a "negotiation
example"; it is a series of out-of-context examples of isolated header
field values.  This actually *would* benefit from a full example of an
opening handshake that uses this, where a client offers a few PMCEs
(perhaps two with the same name and a third with another name), and
showing how the server responds.
2013-02-21
05 Barry Leiba State changed to AD is watching from AD Evaluation
2013-02-21
05 Cindy Morgan
Alternate Document Writeup
1. Summary

Salvatore Loreto is the document shepherd

Barry Leiba is the responsible Area Director

Abstract
This document specifies a framework for …
Alternate Document Writeup
1. Summary

Salvatore Loreto is the document shepherd

Barry Leiba is the responsible Area Director

Abstract
This document specifies a framework for creating WebSocket extensions
that add compression functionality to the WebSocket Protocol.
Extensions based on this framework compress the payload of non-control
WebSocket messages using a specified compression algorithm.
One reserved bit RSV1 in the WebSocket frame header is allocated to
control application of compression for each message. This document
also specifies one specific compression extension using DEFLATE.


2. Review and Consensus


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.

Chrome supports the old perframe deflate draft. However they are going
to update it to the latest one soon.
pywebsocket (http://code.google.com/p/pywebsocket/ ) supports
permessage-compression-04 but needs some changes
on extension parameters parsing to be 05 compliant.

Jetty webserver has supports the permessage-compression draft but an
older version of the draft.



3. Intellectual Property

The author has confirmed conformance with BCPs 78 and 79.


4. Other Points


The draft reference as Informative: RFC1951 "DEFLATE Compressed Data
Format Specification version 1.3"
that appear in the DOWNREF registry.

There is no new IANA registry created by this document.
2013-02-21
05 Cindy Morgan Note added 'Salvatore Loreto (salvatore.loreto@ericsson.com) is the document shepherd.'
2013-02-20
05 Barry Leiba State changed to AD Evaluation from Publication Requested
2013-02-20
05 Barry Leiba Ballot writeup was changed
2013-02-20
05 Barry Leiba Ballot writeup was generated
2013-02-20
05 Barry Leiba Find the shepherd writeup here:
https://datatracker.ietf.org/wg/hybi/management/shepherds/draft-ietf-hybi-permessage-compression/writeup/
2013-02-20
05 Barry Leiba Changed protocol writeup
2013-02-20
05 Barry Leiba Intended Status changed to Proposed Standard
2013-02-20
05 Barry Leiba IESG process started in state Publication Requested
2013-02-20
05 Salvatore Loreto IETF state changed to Submitted to IESG for Publication from WG Document
2013-01-23
05 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-05.txt
2012-10-19
04 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-04.txt
2012-10-15
03 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-03.txt
2012-10-15
02 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-02.txt
2012-10-01
01 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-01.txt
2012-08-21
00 Takeshi Yoshino New version available: draft-ietf-hybi-permessage-compression-00.txt