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 |