Roman Danyliw's Discuss on draft-ietf-httpbis-compression-dictionary-13: (with DISCUSS and COMMENT)

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