It's probably worth mentioning that, even though the spec is in the IETF process, there was heavy involvement with w3c and whatwg as well. The w3c TAG performed several reviews, there are several discussions in the whatwg HTML <https://github.com/whatwg/html/issues/10162> and Fetch <https://github.com/whatwg/fetch/issues/1739> issue trackers and discussion/review by the w3c web performance working group (where it originated). The linked HTML and Fetch issues are the tracking issues for adding the processing language to the relevant specs (or make sure the existing language covers the expanded use cases from the IETF draft).
On Tue, Aug 27, 2024 at 12:47 PM Patrick Meenan <pmee...@chromium.org> wrote: > I just pushed the update to the explainer to redirect it to the IETF spec > (will update it again when we have an RFC number). > > I kept the changelog in the WICG explainer just so existing users of the > earlier OT's will know what changes they need to make for the release. OT > v3 had the changes and most of the users that were actively testing already > picked up the changes but this makes it clearer. > > On Tue, Aug 27, 2024 at 12:31 PM Patrick Meenan <pmee...@chromium.org> > wrote: > >> >> >> On Tue, Aug 27, 2024 at 12:21 PM Jeffrey Yasskin <jyass...@chromium.org> >> wrote: >> >>> Congratulations on getting compression dictionaries through the >>> standards gauntlet! >>> >>> On Tue, Aug 27, 2024 at 2:36 AM Tsuyoshi Horo <h...@chromium.org> wrote: >>> >>>> >>>> Explainerhttps://github.com/WICG/compression-dictionary-transport >>>> >>> >>> The explainer still has "All actual header values and names still TBD". >>> I assume that's not the case anymore? >>> >> >> Thanks. The explainer is actually going away and deferring to the RFC as >> the authoritative source. I'll go through and make a pass now to at least >> remove the redundant bits and point to the draft. >> >> >>> >>> >>>> Specification >>>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary >>>> >>> >>> Is there a specification for the browser side of this? I'd expect to >>> find something in Fetch that describes, for example, the CORS, same-origin, >>> and partitioning behavior. >>> >> >> There will be a few updates to the fetch spec to include the content >> encoding processing but the core parts of the CORS logic are in the IETF >> draft in section 9.3 >> <https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-17.html#name-security-mitigations>, >> including the CORS checks. The partitioning behaviour is described in section >> 10 >> <https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-17.html#name-privacy-considerations> >> : >> >> >>> >>> >>>> >>>> Interoperability and Compatibility >>>> >>>> Interoperability and Compatibility risk are low. This feature >>>> introduces a new compression method for transporting resources over HTTP. >>>> Web sites can know the browser support for the new feature by checking >>>> `document.createElement('link').relList.supports('dictionary')`. >>>> >>> >>> >>> https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-17.html#name-the-compression-dictionary- >>> says the link relation is "compression-dictionary" instead of "dictionary". >>> Which is being shipped? >>> >> >> Sorry, missed that on the I2S draft from a previous I2E - the name >> changed and "compression-dictionary" is what is shipping. >> >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w6uFiBUC0fj%3DzcV8brL_4p1UMpDX2J4sx6Bnq%2BMVLXEhQ%40mail.gmail.com.
