- From: Roman Danyliw via Datatracker <noreply@ietf.org>
- Date: Tue, 20 Aug 2024 17:29:18 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-compression-dictionary@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, mnot@mnot.net
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-compression-dictionary-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** How to best cite living specifications? [FETCH] WHATWG, "Fetch - Living Standard", June 2024, <https://fetch.spec.whatwg.org>. [URLPattern] WHATWG, "URL Pattern - Living Standard", March 2024, <https://urlpattern.spec.whatwg.org/>. Realizing that these are living specifications, I don’t understand how the above citations are providing stable references. How does one get the “March 2024 version” of “URL Pattern”? Is there a specific GitHub commit reference that can be used instead? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Reese Enghardt for the GENART review. ** Section 4. This section provides normative guidance that relies on [SHARED-BROTLI]. -- As such, [SHARED-BROTLI] needs to be a normative reference. -- Is the WG confident that this reference has sufficient stability/review for use? I ask because [SHARED-BROTLI] appears to be an expired, individual I-D. ** Section 4 and 5. Both of these sections specify a fixed size header (36-bytes and 40 bytes) that includes a SHA-256 hash. Is this document the authoritative source for defining these headers? If so, is it expected that this SHA-256 hash would provide imbue any security properties? I ask because the use of SHA-256 is hard coded and there is no means for algorithm agility.
Received on Wednesday, 21 August 2024 00:29:23 UTC