Compression Extensions for WebSocket
RFC 7692

Note: This ballot was opened for revision 24 and is now closed.

Barry Leiba Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-07-07 for -24)
No email
send info
*** 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.


It's odd to refer to anything done by a computer as "manual".

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

Comment (2015-07-08 for -24)
No email
send info
I support both of Ben's comments that mention intermediaries.

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-08-13 for -27)
No email
send info
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.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2015-07-07 for -24)
No email
send info
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

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

Summary: Ready, no nits, no comments.

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


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.

OPS-DIR mailing list

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection