LGTM1. Congrats, all. This is a big deal! On Tuesday, August 27, 2024 at 10:06:16 AM UTC-7 Patrick Meenan wrote:
> 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/893b961c-c763-44a0-abe4-361ba276ab1en%40chromium.org.
